应用提审前权限问题很少表现为“完全没配”。更常见的是一次功能合并顺手增加了两项requestPermissions相机权限有理由和使用场景麦克风权限只有名称隐私声明仍沿用上个版本代码评审又只看到业务文件。构建可以通过真正的问题被推迟到发布检查甚至用户授权界面。本文把这件事收敛成一个可执行门禁。演示项目名为PermissionDelta诊断页为PermissionAuditPage任务编号PERM-AUDIT-0059。基线版本2.7.0声明6项权限候选版本2.8.0声明8项新增CAMERA与MICROPHONE。首轮发现2项未批准增量、1项缺少 reason、1项 usedScene 范围不合规、隐私声明缺少MICROPHONE门禁状态为BLOCKED。修复后移除麦克风权限并批准相机用途清单变为7项问题数归零状态为PASS。这些结果来自演示配置不宣称经历了真实应用市场审核。一、把“权限有没有”改成“这个版本为什么多了”只扫描候选包的权限总数无法区分历史债务与本次变化。一个长期存在且已经解释过的权限和本次无意加入的麦克风权限风险与处理人都不同。增量审计先回答三个问题新增了什么、删除了什么、已有项的使用场景是否改变。PermissionDelta保存一份随已发布版本归档的基线快照。它不从开发分支即时生成而是来自真正进入发布流程的2.7.0。候选2.8.0在构建前读取各模块module.json5把requestPermissions合并成应用级集合再与基线比较。多 HAP 场景不能只盯 entry 模块官方资料说明权限声明在应用范围生效审计器应保留来源模块便于定位重复与变化。门禁并不替代平台审核。它只把团队已经知道的约束变成稳定检查用户授权或手动设置类权限需要 reason 与 usedScenereason 应引用可本地化字符串usedScene 的 abilities 必须存在when只能落在团队允许的范围新增权限要出现在批准清单和隐私声明中。权限类别与规则来自项目维护的策略文件不在脚本里凭名字猜测。这一区分很重要。ohos.permission.CAMERA与ohos.permission.MICROPHONE在演示策略中都被标记为需要完整说明但文章不把脚本数据库描述成系统权威。SDK、设备与政策会变化策略文件需要根据当前官方文档维护。无法核验的权限应进入UNKNOWN_POLICY而不是默认放行。二、先把 JSON5 变成稳定快照module.json5允许注释与 JSON5 语法直接用JSON.parse()会在正常工程文件上失败。脚本使用json5解析再把权限对象规范化。规范化要去掉数组顺序差异保留 name、reason、usedScene 和来源模块最后按权限名排序输出。这段代码解决什么问题读取 module.json5提取并规范化权限声明为跨版本比较生成稳定快照。importfsfromnode:fsimportJSON5fromjson5interfaceUsedScene{abilities:string[]when:string}interfacePermissionItem{name:stringreason?:stringusedScene?:UsedScene sourceModule:string}functionreadPermissions(file:string,sourceModule:string):PermissionItem[]{constrootJSON5.parse(fs.readFileSync(file,utf8))as{module?:{requestPermissions?:ArrayRecordstring,unknown}}constsourceroot.module?.requestPermissions??[]returnsource.map((item)({name:String(item.name??),reason:typeofitem.reasonstring?item.reason:undefined,usedScene:item.usedSceneundefined?undefined:{abilities:Array.isArray((item.usedSceneasRecordstring,unknown).abilities)?((item.usedSceneasRecordstring,unknown).abilitiesasstring[]).slice().sort():[],when:String((item.usedSceneasRecordstring,unknown).when??)},sourceModule})).filter((item)item.name.length0).sort((a,b)a.name.localeCompare(b.name))}这里不修改工程文件只读取并生成审计模型。脚本保留sourceModule因为同一权限可能在多个模块重复声明最终应用级集合可以去重诊断仍要告诉开发者它来自哪里。abilities排序后单纯调整配置顺序不会制造无意义差异。易错点是把reason文字直接展开进快照。reason 通常引用$string:xxx快照保存引用和值的摘要更合适引用变化意味着资源键变化翻译内容变化则由本地化门禁负责。本文检查引用存在不重复此前已经交付的多语言占位符审计主题。另一个边界是配置合并。不同产品变体、设备类型或构建参数可能选择不同模块。门禁应针对“将要发布的那个构建变体”生成快照而不是扫描仓库里所有 module 文件后粗暴求并集。演示固定 entry 与 capture 两个模块生产项目应把变体参数写入报告。三、差异要同时比较新增、删除与场景变化权限名集合能找出新增和删除却看不到when: inuse变成always也看不到EntryAbility被替换为后台扩展。审计器给每个权限生成语义指纹指纹包含 reason 引用、abilities 有序列表与 when。相同权限名但指纹变化进入changed集合。这段代码解决什么问题比较基线与候选权限区分新增、删除和使用场景变化。interfacePermissionDiff{added:PermissionItem[]removed:PermissionItem[]changed:Array{before:PermissionItem,after:PermissionItem}}functionfingerprint(item:PermissionItem):string{returnJSON.stringify({reason:item.reason??,abilities:item.usedScene?.abilities??[],when:item.usedScene?.when??})}functiondiffPermissions(baseline:PermissionItem[],candidate:PermissionItem[]):PermissionDiff{constbeforenewMap(baseline.map((item)[item.name,item]))constafternewMap(candidate.map((item)[item.name,item]))constaddedcandidate.filter((item)!before.has(item.name))constremovedbaseline.filter((item)!after.has(item.name))constchanged:Array{before:PermissionItem,after:PermissionItem}[]for(const[name,current]ofafter){constpreviousbefore.get(name)if(previousfingerprint(previous)!fingerprint(current)){changed.push({before:previous,after:current})}}return{added,removed,changed}}首轮结果是added2、removed0、changed0。这并不代表已有权限绝对安全只表示本次没有改动它们。基线建立时仍要做一次全量审计之后每个版本以增量为主并定期在策略升级时重跑全量。删除权限也需要进入报告。它通常是好事但可能意味着功能已经移除、模块漏打包或配置分支选错。门禁可以把删除设为提醒而非阻断由业务负责人确认。不要因为“权限越少越好”就自动忽略删除变化。场景变化的风险常高于新增。把when从inuse扩成always用户感知和声明内容都可能变化即便权限名没有变化也应重新批准。脚本将它归入 changed后续规则与 added 一样检查批准记录。四、reason 和 usedScene 要按策略检查不靠正则猜权限官方权限声明资料说明user_grant 或 manual_settings 权限需要 reason 与 usedSceneusedScene.when使用固定值abilities 指向使用权限的 UIAbility 或 ExtensionAbility。项目策略文件把这些规则映射到具体权限并额外声明允许的 when 与 ability 范围。演示候选中相机权限配置为 reason$string:camera_permission_reason、abilities[EntryAbility]、wheninuse结构完整麦克风权限缺少 reasonusedScene 写成always而产品批准的录音场景只允许前台inuse。因此它产生MISSING_REASON与SCENE_SCOPE_MISMATCH。这段代码解决什么问题依据项目维护的权限策略检查 reason、usedScene 与 ability 范围未知权限不静默放行。interfacePermissionPolicy{name:stringrequiresReason:booleanrequiresUsedScene:booleanallowedWhen:string[]allowedAbilities:string[]}interfaceFinding{permission:stringcode:stringmessage:string}functionvalidatePermission(item:PermissionItem,policy?:PermissionPolicy):Finding[]{if(!policy){return[{permission:item.name,code:UNKNOWN_POLICY,message:权限未进入策略库}]}constfindings:Finding[][]if(policy.requiresReason!item.reason?.startsWith($string:)){findings.push({permission:item.name,code:MISSING_REASON,message:缺少可本地化 reason})}if(policy.requiresUsedScene!item.usedScene){findings.push({permission:item.name,code:MISSING_USED_SCENE,message:缺少 usedScene})returnfindings}if(item.usedScene!policy.allowedWhen.includes(item.usedScene.when)){findings.push({permission:item.name,code:SCENE_SCOPE_MISMATCH,message:when 超出批准范围})}constinvalidAbilityitem.usedScene?.abilities.find((ability)!policy.allowedAbilities.includes(ability))if(invalidAbility){findings.push({permission:item.name,code:ABILITY_NOT_APPROVED,message:invalidAbility})}returnfindings}脚本只对策略有依据的权限给出确定结论。遇到新权限时返回UNKNOWN_POLICY要求维护者先查官方文档并补充规则。这样做比按CAMERA、MICROPHONE字符串猜敏感等级更慢却能避免错误知识永久写入流水线。reason的存在也不代表文案合格。本文只检查它是资源引用具体措辞、语言覆盖和是否准确描述用途仍需要内容审核。门禁可以再读取资源值做非空检查但不应尝试用几个关键词替代人工判断。开发配图展示PermissionDelta工程树、中间的diffPermissions()与validatePermission()、右侧BLOCKED诊断页、底部PERM-AUDIT-0059 added2 findings5日志。模拟器统一在右侧。图片是演示界面不冒充实际 DevEco Studio 或真实提审证据。五、隐私声明一致性要比较“用途”不只比较名称很多团队把隐私声明维护成独立文档权限配置与文档靠人工同步。门禁至少可以把声明中的权限条目转成机器可读清单检查 manifest 新增项是否有对应用途。演示文件privacy-permissions.zh-CN.json在首轮包含相机不包含麦克风因此额外产生PRIVACY_DECLARATION_MISSING。这段代码解决什么问题校验新增权限是否经过批准并且在隐私声明中存在匹配用途最终生成可用于构建退出码的结果。interfaceApproval{permission:stringticket:stringpurposeId:string}interfacePrivacyPurpose{permission:stringpurposeId:stringtext:string}functionvalidateReleaseDelta(added:PermissionItem[],approvals:Approval[],purposes:PrivacyPurpose[]):Finding[]{constfindings:Finding[][]for(constitemofadded){constapprovalapprovals.find((entry)entry.permissionitem.name)if(!approval){findings.push({permission:item.name,code:UNAPPROVED_ADDITION,message:新增权限未批准})continue}constpurposepurposes.find((entry)entry.permissionitem.nameentry.purposeIdapproval.purposeId)if(!purpose||purpose.text.trim().length0){findings.push({permission:item.name,code:PRIVACY_DECLARATION_MISSING,message:隐私用途缺失})}}returnfindings}constblockedfindings.length0process.exitCodeblocked?2:0批准记录使用purposeId连接权限与文案而不是只比较权限名。相机可能有“扫描二维码”和“拍摄头像”两种用途权限相同用户说明却不同。若候选功能从二维码扩展到持续视频采集旧批准记录不应自动覆盖新用途。演示首轮为了让问题链更清楚把相机与麦克风都标记为未批准新增因此增量检查产生两项问题麦克风又缺 reason、场景过宽、隐私用途缺失总计五项 finding。修复不是把脚本改成放行而是删除并未使用的麦克风声明为相机补充批准记录与用途映射。第二轮候选权限数从 8 变为 7新增只剩相机finding 变为 0。退出码2是演示约定不是 Hvigor 平台标准。CI 或 Hvigor 任务只需要把非零码视为失败并保留 JSON 报告。不要只打印红字继续打包否则门禁会退化成没人看的提醒。手机运行页显示时间05:20、电量73%基线2.7.0 / 6 permissions候选2.8.0 / 8 permissions新增CAMERA与MICROPHONEfinding 为5状态BLOCKED。红色标注指向缺失 reason 和隐私声明缺口页面数据与正文一致。六、修复页要留下决策痕迹门禁的价值不只是阻断还要让下一次审计知道问题如何消失。若开发者直接删除麦克风权限报告应记录removedFromCandidateMICROPHONE相机被批准后记录批准单号、purposeId 和策略版本。否则一个月后看到候选从 8 项变成 7 项无法判断是正确收敛还是构建变体漏配。演示第二轮状态为FIXED → PASSmanifest 7 项、隐私清单 7 项、批准新增 1 项、finding 0。相机仍为wheninuseabilities 仍为EntryAbility。修复页不展示真实审批系统只使用演示批准号PRIV-0059-CAM避免虚构企业流程。详情图展示首轮与修复轮的差异8 → 7 permissions、5 → 0 findings、麦克风移除、相机批准、manifest 与 privacy7 7。红圈只标记PASS与两份清单一致承担“为何通过”的解释。七、接入 Hvigor 时保持任务职责单一审计脚本可以在构建前由 Hvigor 任务调用但不要让它顺便修改 module.json5、生成 reason 文案或删除权限。门禁应是只读的输入是候选配置、基线、策略、批准记录和隐私清单输出是 JSON 报告与退出码。修复仍由开发者在代码评审中完成。建议把执行拆成三步。第一步针对目标变体生成候选快照第二步计算差异并运行策略第三步输出人读摘要和机读报告。若解析失败、基线缺失或策略文件损坏状态应为ERROR而不是PASS。只有“检查完成且 finding 为零”才能通过。基线更新发生在版本真正进入发布流程之后而不是每次门禁失败时自动覆盖。若脚本允许开发者一键把当前候选设为新基线未批准权限会被洗成历史项。更新基线应是受保护动作并关联版本号、提交和报告摘要。多产品线还要避免共用一份宽泛批准清单。手机入口需要相机不代表穿戴设备或服务卡片也需要。批准记录至少包含产品变体、模块和用途审计时只选择当前目标。范围越清楚门禁越不容易因为“别的模块用过”而误放行。八、验收重点在失败路径脚本测试应覆盖 JSON5 注释、空权限数组、多模块重复、同名权限场景变化、unknown policy、reason 非资源引用、ability 不存在、when 非法、隐私用途为空、批准 purposeId 不匹配和基线缺失。每个失败要有稳定 code避免 CI 只能匹配易变的中文提示。对演示数据验收顺序是读取2.7.0基线 6 项读取2.8.0候选 8 项识别新增 2、删除 0、变化 0相机结构完整麦克风出现 reason 与场景问题批准清单缺两个新增隐私清单缺麦克风聚合为 5 项 finding退出码 2。修复轮重新从文件读取不能复用内存中的旧对象最终得到 7 项、finding 0、退出码 0。报告里不需要保存全部隐私文案可保存 purposeId、语言、摘要哈希与非空状态减少敏感内容和冗余。日志也不应输出开发者签名、证书路径或无关环境变量。权限门禁关注声明一致性不应扩大采集范围。还有一个容易忽略的边界权限声明与运行时请求是两层问题。manifest 合规不代表应用在正确时机向用户申请也不代表拒绝后有合理降级。本文只做静态发布门禁运行时授权流程仍需单独验证包括首次请求、拒绝、再次请求、设置页返回和页面销毁。1. 策略文件也要版本化和可回放同一份候选配置用不同日期的官方规则和团队策略检查结果可能不同。报告必须记录policyVersion、策略文件摘要与生成时间。出现争议时团队才能用当时策略重放而不是拿今天的规则解释三个月前的门禁结果。演示策略版本为perm-policy-2026.10它只是本项目标识不代表平台版本。策略升级后应对当前基线做一次全量回放。若新规则把历史权限标记为问题不能让所有功能分支突然因“新增”之外的问题失败可以单独生成基线迁移任务明确负责人和截止版本。门禁继续阻止新的违规扩大同时让历史问题以可追踪方式收敛。策略库的修改权限应比普通业务配置更严格。若开发者能在同一个提交中新增麦克风权限并把allowedWhen从inuse改成always门禁等于允许被检查对象修改检查规则。至少要求独立目录、指定评审人和变更说明CI 报告也应突出策略变化。2. 报告要同时服务开发者和流水线人读摘要需要告诉开发者去哪个模块、改哪个字段、为何阻断机读 JSON 则需要稳定结构。建议包含任务号、基线版本、候选版本、变体、权限统计、diff、findings、策略版本、最终状态和退出码。每个 finding 至少有 permission、sourceModule、code、field 与 message不能只有一段长文本。报告中的顺序也要确定。权限按 name 排序finding 按 permission 与 code 排序同一输入应产生字节稳定的 JSON。这样代码评审能看到真实变化不会被 Map 遍历顺序或文件扫描顺序干扰。摘要可加入颜色JSON 不依赖终端控制符。诊断页只展示最关键的五项问题并提供完整报告入口。问题过多时不要把手机页面无限拉长先按新增权限聚合再显示每项的 reason、usedScene、批准和隐私用途状态。PermissionAuditPage不是修改器所有“自动修复”按钮都应避免因为删除权限或改场景需要业务判断。3. 降低误报要靠更准确的输入不靠跳过规则门禁误报常来自扫描了不会参与发布的模块、基线版本选错、ability 清单未同步或隐私文件选择了错误语言。解决方式是把构建变体、模块图、ability 名单和目标语言作为显式输入并在报告顶部展示。不能遇到误报就给某个权限加永久 ignore。确实需要例外时例外记录应有权限名、适用变体、finding code、原因、批准人和到期版本。到期后自动失效且不能用一个例外覆盖所有检查。比如允许相机新增不等于允许它缺 reason也不等于允许 when 扩成 always。本地运行与 CI 应使用同一脚本和策略。开发者在提交前能看到与流水线一致的五项 finding修复成本最低若本地只是简化版、CI 才执行完整检查团队会把门禁视为远端障碍。Hvigor 任务只负责调用统一入口不再复制规则。4. 权限减少同样需要产品验收修复轮移除麦克风权限后静态门禁会通过但产品仍要确认相关入口不会在运行时调用录音能力。如果代码还保留请求逻辑运行时会失败如果功能已经下线页面提示与隐私声明也要同步删除。权限清单收敛只是配置结果不证明功能路径已经清理干净。可以在代码搜索或静态分析中建立“权限—能力调用”索引辅助确认声明与调用是否互相对应。不过系统能力调用与权限并非总能一一静态推断因此这类检查应作为证据不应在缺少官方映射时给出绝对结论。本文门禁选择可验证的配置与声明一致性把调用链验证留给独立任务。九、结语让权限变化成为一个需要解释的发布事件权限配置不是越多越保险。每增加一项都扩大用户授权面、隐私说明面和发布验证面。最有效的审计并非每次重新读一遍完整清单而是先看版本差异再用当前策略和用途记录解释变化。PermissionDelta的演示闭环很具体任务PERM-AUDIT-0059从基线 6 项看到候选 8 项发现两个新增和五项问题门禁进入BLOCKED删除未使用的麦克风声明并批准相机用途后候选收敛到 7 项manifest 与隐私清单一致finding 为零状态进入PASS。这是一套发布前自检方法不替代官方审核也不声称某个真实应用已经因此通过审核。参考资料HarmonyOS 权限声明参考https://github.com/openharmony/docs/blob/master/en/application-dev/security/AccessToken/declare-permissions.mdOpenHarmony module.json5 配置资料https://github.com/openharmony/docs/blob/master/zh-cn/application-dev/quick-start/module-configuration-file.mdHarmonyOS 上架审核主题资料https://developer.huawei.com/consumer/cn/forum/topic/0201218124295377819