开发机上一切正常提交审核直接被打回来权限声明和 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 ProfileRelease Profile权限基本都能用严格校验签名开发签名发布签名审核不需要要审核这就是为什么开发机正常发布包出问题。开发环境宽松发布环境严格。四、最小权限原则为什么重要很多人习惯把可能用到的权限都声明上以后要用就不用再加了。不对。最小权限原则只声明当前需要的权限。做法问题全部权限都声明审核不通过用户不信任不用的权限还留着增加合规风险一个功能一个权限合理五、几个容易踩的坑第一个坑一次性申请全部权限。用户一打开就弹一堆权限直接卸载。第二个坑已经不用的权限还留在配置。代码里删了配置里还留着。第三个坑开发 Profile 和 Release Profile 不一致。开发能跑发布出问题。第四个坑业务还没触发就提前申请。用户还没用到功能就弹权限。第五个坑权限拒绝以后没有降级。用户拒绝了功能直接崩。第六个坑隐私说明与实际用途不一致。写的是为了体验实际收集位置数据。这次做上架审核最大的体会是权限不是技术问题是合规问题。真正做的时候最容易忽略的不是怎么申请权限而是怎么管好权限清单。哪些要、哪些不要、什么时候要、要了干什么每一项都要对得上。