企业官网建设流程全解析

鸿蒙开发里，权限这块可能是不少人第一个被卡住的地方。明明在module.json5里写了权限声明，运行时却不弹窗；弹窗弹了，用户点了拒绝，后续功能直接瘫痪；还有的权限明明申请成功了，换个页面再调还是报错。这篇继续聊鸿蒙权限，重点放在申请授权这件事上。前面两篇把权限的基本概念和应用声明层的东西讲得差不多了，这篇就专门把运行时怎么请求权限、怎么处理回调、怎么做状态校验一次性说透。适合正在用 Stage 模型做鸿蒙应用开发的同学看，尤其是已经被权限弹窗和授权回调折磨过的。我自己在把工具类应用从 Android 往鸿蒙迁移的时候，感触最深的一点是：鸿蒙把“用户同意”这件事做得非常重，你写下的每一句权限代码，本质都是在跟用户对话。

1. 先理清思路：鸿蒙的权限机制到底在做什么

1.1 权限不是“越多越好”，而是“用户说了算”

做 Android 开发的时候，权限在我眼里更像一道闸门，清单文件里写上了，运行时申请一下，系统弹个窗，用户点了允许，后面的代码就一路畅通。但到了鸿蒙里，我的理解被强行纠正了：权限本质上是一段“受保护资源的访问资格”。相机、麦克风、定位、相册这些敏感数据，全部被系统锁在资源管理框架后面，应用每次想要触碰，都得证明自己有资格，而这个资格的来源只有一个——用户授权。

所以你在代码里做的所有事情，都不是“我声明了所以我可以用”，而是“我向用户出示了一张访问说明，用户画了勾，系统才把门打开”。这个机制决定了三件事：第一，权限声明只是报名，不代表入场；第二，user_grant 类型的权限必须运行时弹窗征求用户同意，没有绕过的方式；第三，用户后续可以到设置里反悔，随时把权限收回。

为什么偏偏是这种设计？因为隐私合规已经是一条硬杠杠。系统把权限关卡设计得越重，应用乱申请权限、偷偷采集信息的空间就越小。我见过不少开发者抱着“先把权限全声明了，以后用得着”的心态，结果上架审核被拒，理由就是“申请的权限与业务场景不匹配”。在鸿蒙上这条路是走不通的，你申请的每个权限，都要有说得过去的理由。

1.2 system_grant 与 user_grant：哪些需要弹窗，哪些不需要

很多人刚接触鸿蒙时会混淆一个概念：是不是所有权限都要动态申请？答案是否定的。鸿蒙把权限分成了两大类，一类是系统授权（system_grant），一类是用户授权（user_grant），两者差别非常大。

理解了这张表，很多“为什么不弹窗”的问题就解开了一半。你申请一个ohos.permission.INTERNET，系统在安装应用的时候就直接把权限给了，运行时自然不会有任何弹窗，也不需要你写任何动态申请的代码。但你要用定位或者相机，那就必须老老实实走“弹窗 → 用户同意 → 返回结果”这条路。

为什么系统要把这两类分开？核心考虑是“打扰成本”。网络这类权限给用户带来的感知很弱，应用装上就要联网，逐个弹窗反而烦人；而相机、相册这种涉及个人隐私的能力，用户有权在每次使用时知道并决定。这个设计逻辑理解透了，你去规划功能模块的时候，就清楚哪一步该写申请代码、哪一步只需要声明就够。

2. 权限的分类与等级：别等上线才发现权限申请不下来

2.1 权限等级与 APL：为什么有的权限你根本申请不到

比 system_grant 和 user_grant 更隐蔽的一个坑，是权限等级。鸿蒙里的权限本身分了三档：normal（普通）、system_basic（系统基础）、system_core（系统核心）。普通应用默认的应用权限等级（APL）是 normal，所以能申请的权限基本被限定在 normal 这一档里。system_basic 和 system_core 的权限，普通应用很多时候是碰不到的。

这个机制可以类比成小区门禁：普通住户的门禁卡只能刷开自己楼层和小区大门，物业人员的卡能刷开设备间，安保系统的卡能刷开核心机房。你拿着一张普通住户的卡，却去刷设备间的门，被拒不是因为密码不对，而是权限等级压根不匹配。

实操中的教训是：如果某个权限在文档里标注是 system_basic，而你的应用只是普通应用，那就别死磕代码了，该放弃就放弃，或者换一个普通权限能覆盖的替代方案。我遇到过有同学费了半天劲申请一个系统基础权限，反复确认代码没问题，最后查文档才发现普通应用根本没资格。这是设计层面的问题，不是代码层面的问题。

2.2 常用权限速查：按业务场景对照着选

为了方便日常开发，我把最常见的几个业务场景和对应权限整理成了一张速查表。这张表在立项排期的时候就能用上，提前对照一遍，能省掉很多后面改声明的麻烦。

这张表只是常用场景的参考，真正的权威来源永远是官方文档里的权限列表。我的习惯是：每个权限在集成前，都去文档里确认三件事——权限等级、授权类型、是否限制申请。文档没查清楚就动手写代码，是后面踩坑的最大根源。

3. 实操：一段完整的申请授权代码是怎么写出来的

3.1 在 module.json5 里先写对声明

动态申请权限之前，第一步永远是声明。鸿蒙应用清单文件module.json5里的requestPermissions字段，就是应用的“权限报名表”。很多开发者在这里写错了一个细节，导致后面运行时申请出了问题。我以一个定位场景为例，字段长这样：

{ "module": { "requestPermissions": [ { "name": "ohos.permission.APPROXIMATELY_LOCATION", "reason": "$string:location_reason", "usedScene": { "abilities": ["EntryAbility"], "when": "inuse" } }, { "name": "ohos.permission.LOCATION", "reason": "$string:location_reason", "usedScene": { "abilities": ["EntryAbility"], "when": "inuse" } } ] } }

这里有两个关键点。第一，user_grant 类型的权限必须写reason，也就是向用户解释“为什么需要这个权限”的文字说明，而且规范做法是写到字符串资源里，比如$string:location_reason，方便多语言适配和统一修改。第二，usedScene要写清楚在哪个 Ability 里用、是“仅使用期间”还是“后台也可用”。这一项不只是给系统看的，应用市场上架审核也会看。我遇到过声明没问题但上架被驳回的情况，原因就是用途描述太模糊，把理由写具体之后顺利通过。

还有一个很容易忽略的细节：精确位置权限和模糊位置权限，建议一起声明。它们对应的业务能力是一个连续的光谱，你只声明 LOCATION，用户可能无法选择仅返回模糊位置；只声明 APPROXIMATELY_LOCATION，业务又拿不到精确坐标。两个一起声明，把选择权交给用户，是体验最好的做法。

3.2 动态申请权限的正确打开方式

声明配好之后，真正的动态申请代码就来了。鸿蒙里没有像 Android 那么多 Activity Result API 的花样，核心就是通过abilityAccessCtrl里的requestPermissionsFromUser拉起系统弹窗。下面这段代码是常见的写法，适用于 API 10 及之后的版本。如果你的 SDK 版本老一些，导入路径可能是@ohos.abilityAccessCtrl，方法名基本一致，差别不大。

import { abilityAccessCtrl, Permissions, common } from '@kit.AbilityKit'; function requestLocationPermission(context: common.UIAbilityContext) { const atManager = abilityAccessCtrl.createAtManager(); const permissions: Permissions[] = [ 'ohos.permission.APPROXIMATELY_LOCATION', 'ohos.permission.LOCATION' ]; try { atManager.requestPermissionsFromUser(context, permissions) .then((result) => { // authResults 数组和请求的 permissions 数组顺序是一一对应的 const authResults: number[] = result.authResults; if (authResults.length > 0 && authResults[0] === 0) { // 用户授权了模糊定位，可以继续 console.info('APPROXIMATELY_LOCATION granted'); } else { // 用户拒绝了 console.warn('APPROXIMATELY_LOCATION denied'); } }) .catch((err) => { console.error('request permission error: ' + JSON.stringify(err)); }); } catch (e) { console.error('exception: ' + JSON.stringify(e)); } }

这段代码有几个地方需要特别注意。第一，authResults数组的顺序与传入的permissions数组顺序一致，所以判断结果时不能拿到第 0 个就当所有权限都过了，要按业务需要对每个权限分别判断。第二，authResults可能是空数组，说明系统没有返回任何授权结果，这种情况一定要做兜底处理，别直接下标越界。第三，整个调用要放在 try-catch 里，权限弹窗的拉起可能因为上下文问题抛出异常，不捕获的话很容易在线上出现未处理异常。

更关键的是申请时机。很多新手喜欢在页面加载时立刻申请权限，生怕之后没机会。但体验最好的方式，是等用户真正要触发功能时再申请。比如界面上有个“开始定位”按钮，用户点击后才调requestPermissionsFromUser。这样做的原因是，用户在当前上下文里能清晰理解为什么需要这个权限，拒绝率会明显降低。我自己测试过同样的应用，启动即弹窗的权限拒绝率比触发式申请高出一大截，这是实打实的用户心理差异。

3.3 权限拿回来之后还要做什么

权限申请成功，不代表一劳永逸。用户随时可以到系统设置里关掉某个权限，你再调用相关能力时就会直接失败。所以正确的使用姿势是：每次在真正使用受保护能力之前，先做一次权限校验。

import { abilityAccessCtrl, common } from '@kit.AbilityKit'; function checkLocationPermission(context: common.UIAbilityContext): boolean { const atManager = abilityAccessCtrl.createAtManager(); const tokenId = context.applicationInfo.accessTokenId; const result = atManager.checkAccessTokenSync(tokenId, 'ohos.permission.LOCATION'); return result === abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED; }

这也是为什么我前面强调要先拿 UIAbilityContext。校验权限的时候，需要应用的accessTokenId，这个值在 UIAbility 的applicationInfo里可以拿到。不同版本的 API 在获取方式上可能有微调，但思路是一致的：先拿 token 再检查权限。

如果校验不通过，别直接让功能报错，而是要引导用户去打开权限。比较规范的做法是弹一个自定义对话框，说明这个功能为什么需要权限，然后跳转到应用的权限设置页。跳转设置页的写法在不同 SDK 版本里略有差异，我建议封装成独立的工具函数，后续要调整只改一个地方。为什么非得跳设置页？因为如果系统已经判定用户“不再询问”，你再调requestPermissionsFromUser也不会弹窗了，只有设置页能救回来。

4. 常见问题与排查技巧实录

4.1 权限弹窗死活不弹

这是群里问得最多的问题。弹窗不弹，先别怀疑系统坏了，按顺序排查这四件事。第一，确认权限类型是不是system_grant，如果是，那本来就不弹，不用做动态申请。第二，检查module.json5的requestPermissions字段是否真的写上了，尤其是仔细看权限名拼写，鸿蒙权限名特别长，少个下划线就废了。第三，确认调用requestPermissionsFromUser时传的 context 是前台 UIAbility 的 context，如果上下文不对或者页面还没就绪，系统是无法拉起弹窗的。第四，也是容易被忽略的，用户之前拒绝过一次并勾了“不再询问”，之后系统就不再弹了，这时候只能通过设置页处理。

我见过一个典型场景：开发者把权限申请写在了启动时异步函数的回调里，结果 context 已经失效了，弹窗完全没反应。排查下来不是权限配置问题，而是生命周期问题。所以申请权限这件事，一定绑定在具体的用户操作上，而不是生命周期回调里。

4.2 用户拒绝了，后面还有救吗

有，但要讲究方法。首先要区分“首次拒绝”和“永久拒绝”。用户第一次点拒绝，系统还是允许你再次发起申请的；但如果弹窗里出现过类似“不再询问”的选项且被勾选，那requestPermissionsFromUser就基本失效了，只能引导用户去设置页手动打开。

这里要特别提醒一句：不要为了实现某个功能就在用户拒绝后反复弹窗，这种做法在鸿蒙上非常容易触发系统的频率限制，甚至让应用被判定为骚扰。更好的做法是，第一次拒绝后先用自定义对话框解释用途，给用户一个缓冲，如果用户仍然决定不授权，就优雅降级，比如隐藏相关功能或展示说明文案，而不是一进来就围追堵截。体验好的应用，授权流程一定是“讲道理”而不是“硬要”。

4.3 申请成功了，功能却还是不可用

权限申请成功但功能不可用，这个坑我也踩过。最常见的原因是权限链路上有遗漏。举个真实的例子：拍照功能，你只申请了相机权限CAMERA，拍完照要保存到相册，结果保存失败。原因就是写相册还需要WRITE_IMAGEVIDEO或对应的媒体权限，你没有申请。权限这块要看“完整链路”，从采集到落地，每个环节需要的权限都要覆盖到。

还有一种情况是权限顺序判断错了。动态申请的时候一次性传了多个权限，回调里的authResults是按请求顺序排列的，如果你只判断authResults[0]，而业务真正依赖的是第三个权限，那很可能误判了授权状态。我的习惯是把授权结果和权限名绑定在一起逐个判断，不要偷懒只看一个值。

4.4 定位权限的特殊处理

定位权限值得单独说，因为它在鸿蒙里被拆分成了模糊位置和精确位置两个权限。申请的时候建议把两个都传上，系统弹窗会让用户选择“模糊位置”或“精确位置”。如果你只申请了精确位置，用户可能被迫交出精确坐标，这会放大隐私顾虑；如果你只申请了模糊位置，那拿不到精确坐标就没法做地图级定位。

实操里有个小技巧：通过checkAccessTokenSync分别检查两个权限的授权状态。如果APPROXIMATELY_LOCATION是授权状态，而LOCATION是拒绝状态，说明用户选择了模糊定位；如果两个都授权，就是精确定位。业务代码可以根据这个状态做不同处理，比如地图类应用在模糊定位时提示用户“当前只能显示大致范围”。还有一个容易被忽略的场景：用户在设置里改了定位模式，从精确改成模糊，应用回到前台后，别假设权限状态没变，在页面onShow生命周期里重新校验一遍才是稳妥的做法。

5. 给刚开始做鸿蒙权限功能的小伙伴一点建议

做了几个项目的权限功能之后，我个人养成了三个习惯，对排查和提效都有很大帮助。第一，项目设计阶段就维护一张权限登记表，把功能模块、涉及权限、授权类型、使用场景全部列出来，后面所有开发都照着这张表走，既不遗漏也不乱申请。第二，把权限申请的逻辑统一封装成一个工具类，包括动态申请、结果回调、状态校验、跳转设置页，所有页面都调同一个入口，这样出问题时只需要查一个文件，而不是满工程搜索。第三，不要在测试时只点“始终允许”，要实打实把“拒绝一次”“永久拒绝”“设置页手动关闭”这些场景都跑一遍，只有把这些分支都处理好了，才敢说权限功能真正写完了。

鸿蒙权限这套机制，初看会觉得繁，尤其是经历过 Android 那种相对自由的环境。但真正用顺手之后，你会发现它反而帮助应用建立了更清晰的隐私边界：每个权限都有名目、有理由、有用户授权记录。你搭好这套流程之后，后续加新功能需要新权限时，照着同一套模板走，基本不会出岔子。这也是我为什么推荐大家在一开始就把基础打好，别等到应用上架被审核打回、或者用户反馈功能不可用的时候，才回头补功课。