先说我为什么要做这套自查做 HarmonyOS 应用时页面能跑起来只是第一步。真正临近上架时容易暴露出来的是另外一类问题release 包和调试包不一致隐私政策入口在代码里有但真机点不开权限说明写得太泛返回路径在某些页面上会断。中式美食这类内容型应用看起来不复杂但只要涉及首页、详情、收藏、设置、反馈和协议页面上架前就不能只看主流程。我现在会把上架前自查拆成四块构建包、合规入口、真机路径、证据记录。这样做不是为了把流程写复杂而是为了避免最后一天才发现问题只能一边改代码一边补截图。检查块我主要看什么为什么重要release 包是否能稳定构建、版本号是否正确提交包不是调试包不能只靠本地运行判断隐私入口用户协议、隐私政策能否从应用内打开审核会按用户路径点不只看代码里有没有权限说明申请权限是否和当前功能一致权限多写、乱写都会增加返工概率真机路径首页、详情、设置、反馈、返回是否走通模拟器正常不代表真机路径稳定release 包单独跑一遍我不会只用 DevEco Studio 的运行按钮判断应用状态。发布前要单独跑 release 构建并把构建日志和产物路径留下来。$DevEcoHomeDevEco Studio 安装目录$hvigorJoin-Path$DevEcoHometools\hvigor\bin\hvigorw.bat$env:DEVECO_SDK_HOME Join-Path$DevEcoHomesdk$env:JAVA_HOME Join-Path$DevEcoHomejbr$env:PATH $env:JAVA_HOME\bin;$env:PATH cmd/c$hvigor --no-daemon assembleHap --mode module -p productdefault -p buildModerelease 21|Tee-Object-FilePath.\release-check\build-release.log这里我主要看三件事是不是 release 构建版本号有没有跟本次提交一致日志里有没有资源缺失、签名、权限或 profile 相关异常。调试包跑通不能替代这一步。权限说明要和实际功能对齐权限不是越少写越好也不是提前把未来可能用到的都写进去。更稳的做法是当前功能确实用到了什么就声明什么没有入口、没有功能闭环的权限先不要写。{module:{requestPermissions:[{name:ohos.permission.INTERNET,reason:$string:permission_internet_reason,usedScene:{abilities:[EntryAbility],when:inuse}}]}}权限当前是否使用自查方式INTERNET如果有在线内容、反馈或帮助页就需要说明从页面入口触发一次真实网络能力CAMERA没有拍照能力就不要声明检查 module.json5 和实际页面LOCATION没有定位功能就不要声明检查权限弹窗是否会误触发通知/提醒只有提醒功能上线后再声明检查是否有用户可控开关隐私入口要从真机路径走通我以前容易犯的错是只确认项目里存在隐私政策页面却没有从真机首页一路点进去。审核看的是用户能不能找到、能不能打开、内容是否对应当前功能。interfaceLegalItem{title:stringroute:string}constLEGAL_ITEMS:LegalItem[][{title:用户协议,route:pages/legal/UserAgreementPage},{title:隐私政策,route:pages/legal/PrivacyPolicyPage},]设置页里不要只放一个很小的文字链接。至少要让用户能明确看到“用户协议”“隐私政策”“反馈与帮助”这些入口并且返回路径要正常。真机操作预期结果首页进入设置页设置页正常打开不丢失返回栈设置页点隐私政策内容能打开标题和正文匹配隐私页返回设置页返回后设置页状态不乱设置页点反馈入口反馈入口可用不出现空白页多次返回首页NavPathStack 或路由栈不残留错误页面为什么要留证据上架前自查不是做完就算。最好把证据留下来构建日志、版本截图、隐私入口截图、权限说明截图、真机主路径截图。原因很简单后面如果审核反馈某个点异常自己能快速对比是提交前就有问题还是提交包和本地包不一致。release-check/ build-release.log version-info.txt screenshots/ 01-home.png 02-settings.png 03-privacy.png 04-feedback.png这套目录不需要复杂但要能复现。个人开发者最怕的是“我记得我测过”但过两天完全找不到当时测的包、测的设备和测的截图。我以后会按这个顺序做顺序动作1先构建 release 包不用调试包冒充发布包2真机安装后从首页走主流程3检查设置、协议、隐私、反馈这些审核会点的入口4对照 module.json5 看权限是否合理5截图和日志归档发现问题再改下一轮这篇的重点不是把 AppGallery Connect 每一个表单都讲完而是把个人开发者最容易忽略的“提交前自查”讲清楚。只要 release 包、权限说明、隐私入口和真机路径先稳住后面再补截图、描述、分类和版本说明时返工概率会低很多。为什么这篇适合放到鸿蒙生态共创里鸿蒙生态里的经验文章如果只写“我做了一个页面”对后来的人帮助不大。更有价值的是把一个真实应用从开发走向提交时遇到的边界写清楚。中式美食这个案例不复杂但它覆盖了个人 HarmonyOS 应用常见的几类问题ArkUI 页面、Stage 路由、release 构建、权限说明、隐私入口和真机主路径。这些内容不是某一个项目独有换成工具类、内容类、学习类应用也能参考。可复用点对其他 HarmonyOS 应用的价值release 包自查避免只用调试包判断发布状态隐私入口路径帮助开发者提前补齐审核会点的入口权限说明对照减少“权限和功能不一致”的返工真机路径截图给后续审核反馈和版本回溯留证据我更愿意把这类文章写成“我怎么排查、为什么这么做、做完以后怎么验证”而不是把官方文档重新抄一遍。官方文档告诉我们规则项目实践负责把规则落到一个真实页面、真实包、真实设备上。一次自查里我会留下哪些结果结果文件作用build-release.log证明 release 构建流程可复现version-info.txt记录 versionCode、versionName 和提交批次privacy-path.png证明隐私入口可以从真机路径打开permission-check.md记录每个权限为什么存在route-check.md记录首页、详情、设置、协议、反馈的返回路径这些文件不一定都要放进公开文章但本地一定要有。因为审核返工时最怕不知道“当时测的是哪一个包”。有了这些证据才能快速判断是代码问题、构建问题、配置问题还是提交材料没对齐。我会怎么处理发现的问题发现的问题处理方式release 构建失败先修构建不继续补截图和描述隐私入口打不开先修路由和页面注册再重新走真机路径权限说明太泛回到具体功能入口重写 reason返回路径异常先检查 NavPathStack 或路由栈再补页面状态恢复截图和当前版本不一致重新安装 release 包后再截图这个顺序很重要。不要在构建包都不稳定时去补材料也不要在隐私入口打不开时去写一大段解释。上架前自查要解决的是实际可用性不是把问题包装得好看。给后续自己的提醒如果后面中式美食继续加更多能力比如 AI 菜谱推荐、图片识别食材、购物清单提醒或者多设备同步上架前自查还要继续扩展。新增能力越多权限、隐私说明、用户入口和真机路径越要同步更新。否则功能本身做出来了发布时还是会因为材料和入口不一致返工。所以这套检查不是一次性的。每次版本增加新能力都要问四个问题包能不能稳定产出用户能不能找到入口权限能不能解释清楚真机路径能不能走完。能回答清楚再进入提交流程。真机检查不要只点一次主流程我会把真机检查拆成“冷启动、连续返回、异常入口、二次进入”四轮。冷启动看首页和资源是否正常连续返回看路由栈有没有残留异常入口看网络失败、空数据、无权限时页面有没有兜底二次进入看应用从后台回来以后状态是否还稳定。检查轮次具体动作通过标准冷启动安装 release 包后第一次打开首页资源、底部导航、默认数据正常连续返回首页进详情、详情进设置、再逐级返回不黑屏、不回错页、不丢导航状态异常入口断网后点反馈、帮助、在线内容有提示不出现空白页二次进入退到后台再打开搜索词、收藏状态、最近浏览不乱跳这一步其实很朴素但能抓到很多“开发时没感觉、审核时很明显”的问题。特别是个人项目很多页面是边做边补路由和状态很容易留下旧写法。上架前多走几轮比提交后等审核反馈再改更省时间。版本记录也要写清楚我会在本地留一份很短的版本记录不需要写成长文档但要能回答三个问题这次提交的包是哪一个改了哪些和审核相关的点真机检查用的是什么设备。versionName: 1.0.3 versionCode: 103 device: HUAWEI nova 14 Pro system: HarmonyOS 6.1 check: - release build passed - privacy path passed - permission reason checked - main route return passed以后如果有人问“为什么这个版本能提交”这份记录就能直接说明不需要靠记忆回想。module.json5 我会重点看这几项上架前我会单独把module.json5拿出来看一遍。不是为了改成多漂亮而是确认发布包里声明的东西和真实应用能力一致。中式美食当前更像内容浏览和本地记录应用如果没有拍照、定位、录音就不要提前声明这些敏感权限。{module:{name:entry,type:entry,mainElement:EntryAbility,abilities:[{name:EntryAbility,srcEntry:./ets/entryability/EntryAbility.ets,exported:true}],requestPermissions:[{name:ohos.permission.INTERNET,reason:$string:permission_internet_reason,usedScene:{abilities:[EntryAbility],when:inuse}}]}}这段配置我会对照三件事EntryAbility是否真的是发布入口权限 reason 是否写进资源文件页面里是否真的有使用该能力的入口。如果只是未来可能会用就不放进当前版本。隐私和协议入口最好用统一配置设置页里如果到处手写跳转路径后面改页面名时很容易漏。我的做法是把协议入口收在一个配置里设置页只负责渲染和跳转。typeLegalRoute{title:stringrouteName:stringdescription:string}constLEGAL_ROUTES:LegalRoute[][{title:用户协议,routeName:UserAgreementPage,description:说明账号、内容使用和基础服务规则},{title:隐私政策,routeName:PrivacyPolicyPage,description:说明数据收集、使用、存储和撤回方式}]functionopenLegalPage(route:LegalRoute){this.pathStack.pushPathByName(route.routeName,null)}这样做的好处是审核前只要检查这份配置就能知道公开协议入口有没有漏真机上点不开时也能快速定位是路由名错、页面没注册还是设置页没有渲染入口。返回路径也要写验收用例上架审核不会只停在首页。设置页、协议页、反馈页、详情页都会被点到。中式美食里我会把返回路径按页面链路记录下来尤其是NavPathStack相关页面。constreleaseRouteCases[[HomePage,RecipeDetailPage,HomePage],[HomePage,SettingsPage,PrivacyPolicyPage,SettingsPage,HomePage],[HomePage,SettingsPage,FeedbackPage,SettingsPage,HomePage],[HomePage,SearchPage,RecipeDetailPage,SearchPage,HomePage]]这不是自动化测试的完整替代但它能提醒我发布前要按这些路径真机点一遍。尤其是搜索页和详情页最容易出现返回后列表状态丢失、关键词还在但结果被默认列表覆盖的问题。路径容易暴露的问题修正方向首页 - 详情 - 首页返回后滚动位置丢失保存列表现场和滚动位置首页 - 设置 - 隐私 - 设置协议页返回栈异常检查 routeName 和 NavPathStack首页 - 搜索 - 详情 - 搜索搜索结果被默认列表覆盖保留 committedKeyword 和结果态首页 - 设置 - 反馈反馈入口空白检查网络兜底和页面注册检查结果要能复盘我会把每次自查结论写成一份很短的 Markdown不需要复杂格式但要能看出检查日期、设备、系统版本、包版本和发现的问题。# release 自查记录 - 日期2026-07-17 - 设备HUAWEI nova 14 Pro - 系统HarmonyOS 6.1 - versionName1.0.3 - versionCode103 ## 结论 - release 构建通过 - 隐私入口通过 - 权限说明通过 - 主路径返回通过 ## 遗留问题 - 搜索页空结果文案还可以再自然一点 - 设置页反馈入口需要补一张正式截图这份记录以后也能反过来服务文章不是凭空写经验而是把真实检查过程、真实问题和真实修正沉淀出来。