开发机上一切正常，提交审核直接被打回来：权限声明和 Release Profile 对不上。

做了个生活记录 App，开发机上跑了三个月，功能都正常。提交应用市场审核，等了两天，收到驳回通知：“敏感隐私权限未提供用途说明”。

明明代码里都没怎么用这个权限，为什么会被打回来？

这时候才意识到：权限不是"代码里没调用就没事"。你声明了，系统就认为你要用，审核就要看你有没有合理用途。

一、先想清楚：权限到底有几道门

先把最基础的问题想明白。

一个权限从声明到能用，要过好几道：

门	做什么
代码声明	module.json5 里写权限名
系统授权	运行时申请，用户同意
Release Profile	打包时带上权限
审核检查	应用市场看你有没有合理用途

四道门，哪一道对不上，都可能出问题。

二、权限声明不是"写了就行"

很多人以为：在 module.json5 里声明权限，代码里调用，就完了。

不对。权限分普通权限和敏感权限。敏感权限要额外说明用途。

权限类型	要求
普通权限	声明就行
敏感权限	要说明用途
受限权限	要审核通过才能用

{
  "requestPermissions": [
    {
      "name": "ohos.permission.READ_MEDIA",
      "reason": "$string:reason_media",
      "usedScene": {
        "abilities": ["EntryAbility"],
        "when": "inuse"
      }
    }
  ]
}

reason 和 usedScene 就是用途说明。审核要看你为什么要用这个权限。

三、开发 Profile 和 Release Profile 为什么不一样

开发的时候用 Debug Profile，很多权限自动放通。打包发布用 Release Profile，权限要严格校验。

对比	Debug Profile	Release Profile
权限	基本都能用	严格校验
签名	开发签名	发布签名
审核	不需要	要审核

这就是为什么开发机正常，发布包出问题。开发环境宽松，发布环境严格。

四、最小权限原则为什么重要

很多人习惯：把可能用到的权限都声明上，以后要用就不用再加了。

不对。最小权限原则：只声明当前需要的权限。

做法	问题
全部权限都声明	审核不通过，用户不信任
不用的权限还留着	增加合规风险
一个功能一个权限	合理

五、几个容易踩的坑

第一个坑：一次性申请全部权限。用户一打开就弹一堆权限，直接卸载。

第二个坑：已经不用的权限还留在配置。代码里删了，配置里还留着。

第三个坑：开发 Profile 和 Release Profile 不一致。开发能跑，发布出问题。

第四个坑：业务还没触发就提前申请。用户还没用到功能，就弹权限。

第五个坑：权限拒绝以后没有降级。用户拒绝了，功能直接崩。

第六个坑：隐私说明与实际用途不一致。写的是"为了体验"，实际收集位置数据。

这次做上架审核最大的体会是：权限不是技术问题，是合规问题。

真正做的时候，最容易忽略的不是怎么申请权限，而是怎么管好权限清单。哪些要、哪些不要、什么时候要、要了干什么，每一项都要对得上。