健康菜谱助手过审上架那天，我以为最难的是开发；回头看才发现，上架本身是一本独立的账——开发能力决定应用好不好用，上架功课决定应用能不能被用户看到。这篇把个人开发者的上架流程完整复盘一遍，重点讲审核指南没写透、只能自己踩出来的部分。

一、备案：包名要在三处完全一致

个人开发者上架的第一道坎是备案。备案信息里填的包名，必须与工程 AppScope/app.json5 里的 bundleName、签名证书里的包名完全一致——大小写、下划线、层级，一位都不能差。我的教训是三处分开填的：备案平台填了一次，工程里早就有另一份，签名配置又生成一份，第一次提交前没有逐位核对，结果被打回重来。后来养成的习惯是：打包发布前，把三处包名复制到同一个文本里逐位比对一遍，一分钟的事，省一轮驳回。备案通过后拿到的备案号，要挂在隐私政策页面里可访问的位置——审核会查。

二、隐私合规：权限最小化，数据去向要说明白

隐私政策的常见写法是抄模板，但审核看的是"权限申请与功能是否一一对应"。我的原则：每个权限都能指出对应的功能点——网络权限对应菜谱数据拉取，存储权限对应本地收藏缓存。用不到的权限一个都别申请：多申请一个，隐私政策就多一段解释义务，审核就多一分质疑。隐私政策本身要写清数据类型、用途、是否上报、留存期限，链接必须是公网可直接访问的——放在需要登录才能看的页面里不行。

三、侵权自查：名称、图标、素材三维过一遍

侵权问题不限于应用名称——图标相似、素材版权、甚至简介里的表述都可能是雷。自查三步：名称先在应用市场搜一遍，确认没有高度相似的同类应用名；图标自己画或者用确认可商用的素材，别拿搜索引擎搜出来的图；简介与截图里的文案自己写。审核的侵权判定是"系统检测+人工复核"双重机制，先用、知名、商标权属都在判定维度里——个人开发者最稳的做法是让每一层素材都能说清来源。

四、审核等待期：安全评估报告的时点

涉及特定内容形态的应用，会涉及安全评估报告——这份材料的时点问题是我在审核等待期里最困惑的：材料应该在提交前备好，还是审核中按需补交？我的做法是把材料先备齐放在手边，审核一旦问起当天就能补——等待期里主动准备材料，比被动等通知快三天以上。审核被驳回不是终点：驳回意见会写明具体条目，逐条改完重提即可，态度上把它当成一次免费的合规体检。

五、元服务与卡片的补充检查

带服务卡片的元服务还有一道结构检查：卡片要放在独立的元服务模块里，主应用 entry 的代码不直接混入，两边共享数据模型但生命周期、入口、页面栈各自独立——这在应用的版本检查清单里是明确条目，发布前自查一遍工程结构，能省一次形式驳回。

收束

上架审核的本质是平台替用户预演风险。把合规当功能做：包名三处一致、权限逐个对应功能、素材层来源可说清、材料先于审核备好——驳回就追不上你，上架日就从"碰运气"变成"看日程"。