企业官网建设流程全解析

做鸿蒙应用开发这两年，我发现自己和周围朋友在权限这块翻车的次数，比在其他任何系统能力上都多。权限声明写了，弹窗就是不出现；用户明明点了允许，下一次打开还是提示没有权限；代码里已经过了权限校验，进到相机界面却黑屏——这些问题追到最后，几乎都指向同一个根源：对鸿蒙 HarmonyOS 6 的权限金字塔 ATM 模型理解得不够透。这篇文章就围绕权限金字塔 ATM 模型和动态申请权限，把整套体系从概念到代码拆开讲，顺便把我自己踩过的坑一并排掉。文章会从 APL 等级开始，接着拆 ATM 的令牌机制，然后给你完整的动态申请权限链路，最后用拍照场景做一次全流程演示，适合正在做应用开发、或者想系统理解鸿蒙权限体系的同学参考。

1. 权限金字塔到底在说什么：APL 等级、授权类型与 ACL

和很多系统把权限做成"权限清单"不同，鸿蒙把权限设计成了一个分层模型。每次有人问我"这个权限到底能不能动态申请""这个权限我能不能用",我基本都会先让他把权限金字塔的三层结构画一遍。画清楚了，一大半疑问就消失了。

1.1 从塔底到塔尖：normal、system_basic 与 system_core

鸿蒙里每个应用在安装时都会有一个"应用权限等级"，也就是 APL（Ability Privilege Level）。这个等级决定了应用能申请哪些权限，从低到高分三档：

• normal：普通应用默认等级，绝大多数第三方应用都属于这一档。日常用到的相机、麦克风、定位、媒体库读取等权限，都是这一档可以触达的。
• system_basic：需要系统签名或通过特殊渠道申请才能拿到，普通应用默认不在此列。涉及设备配置、系统设置类能力大多在这里。
• system_core：塔尖，只有系统核心进程或被明确允许的少数场景才能持有，普通应用基本不用考虑。

我习惯把这三档想象成一个小区的门禁系统：normal 是"业主卡"，能进出自己家和小区公共区域；system_basic 是"物业卡"，能打开水电井、电梯机房；system_core 是"总控卡"，整个小区的核心设备房都能进。开发者日常打交道的是最底下这一层，往上每一层都对应严格得多的管控。

注意：APL 是"应用等级"，不是"权限等级"。某个权限本身可能被标记为"normal 等级可申请"，但应用自己也得有对应的 APL 才能申。反过来，一个 system_basic 的应用去申请 normal 权限，完全没问题，只是没必要。

为了方便对照，我把三档等级放在一起看：

这个金字塔最直观的价值是：当你在文档里看到一个权限，第一反应应该是去查它所属的 APL 等级和授权方式，而不是先去看"这个功能能不能做"。

1.2 system_grant 与 user_grant：两种授权时机

APL 决定"你能不能申请某个权限"，而授权方式决定"系统什么时候把权限给你"。鸿蒙把权限分为两类：

• system_grant（系统授权）：应用安装时由系统自动授予，不需要用户参与弹窗。典型代表有ohos.permission.INTERNET（网络访问）、ohos.permission.GET_NETWORK_INFO（获取网络信息）等。这类权限用户甚至不会在任何权限页看到开关，因为安装阶段就直接下发了。
• user_grant（用户授权）：必须在运行时向用户发起动态申请，用户点击"允许"后系统才会真正下发。相机、麦克风、精确位置、媒体库读取都属于这一类。这也是"动态申请权限"这个词绝大多数时候所指的对象。

这里有一个常见误解：很多人以为"动态申请"是指"代码里调一次 API 就能拿到权限"。实际上代码只是触发了系统的授权弹窗，真正的授权动作发生在系统设置页里，最终决定权在用户手上。你在代码里能做的是：发起申请、拿到用户选择的回调结果、根据结果切换业务逻辑。

为了体现授权时机的差异，我把两类权限的几个常见例子放一起：

1.3 ACL：给普通应用打开一条向上申请的口子

APL 是金字塔，那普通应用是不是永远只能待在塔底？也不完全是。鸿蒙提供了一个名为 ACL（Access Control List，访问控制列表）的机制：某些原本属于 system_basic 等级的权限，如果业务确实需要，允许 normal 等级应用通过 ACL 方式申请。

ACL 申请有几个特点：第一，需要在上架或分发平台登记受限权限声明，说明申请原因和使用场景；第二，审核人员会核实你的应用是不是真的离不开这个权限；第三，通过后系统会以"受限使用"的方式下发能力，而不是像真正的 system_basic 应用那样放开所有同类权限。

我自己的一个教训是：刚开始做某个内部工具应用时，图省事直接申请了一个 system_basic 权限，结果被审核打回了一次，理由是"使用场景不明确"。后来把申请理由改成"仅在用户主动触发时读取设备标识用于故障诊断"，并附上了触发页面路径，才顺利通过。

提示：ACL 不是随便点了就能生效的。开发调试阶段可以在设备上做一些临时授权，但正式发布必须走完整的审核链路。审核不通过的话，即便代码里写了 AC 在部分系统版本上也不会真正获得能力，运行时会直接报"权限校验失败"。所以能不用 ACL 就不 ACL，业务设计时应优先考虑把功能落在 normal 权限能覆盖的范围内。

2. ATM 模型核心拆解：AccessToken 如何被创建、查询与校验

APL 和授权方式是权限的"规则面"，而 ATM（AccessToken Manager，访问令牌管理器）是权限的"执行面"。每次应用调用系统能力时，系统怎么知道这个应用有没有权限？答案就落在"令牌"这两个字上。

2.1 ATM 在整条系统链路里的位置

鸿蒙的权限体系可以抽象成三层：应用层、框架层、系统服务层。应用层就是你的 HAP/APP 代码；框架层负责把权限申请动作翻译成系统调用；系统服务层运行着一个常驻的权限管理服务，也就是 ATM 所在的位置。

应用安装时，包管理服务会把应用的签名信息、APL 等级、声明的权限列表打包发送给 ATM，ATM 校验通过后生成一个对应的"访问令牌"（AccessToken）。之后应用每次调用需要权限的接口，系统服务会先拿着应用的 AccessToken 去 ATM 查一次：这个应用什么等级、申请过哪些权限、目标权限当前状态如何。查完才决定放行还是拦下。

这个过程用生活类比就是：小区业主入住时先在物业登记了车牌和房间号，物业给了一张门禁卡。后面每次刷卡进楼，门禁系统都读一次卡，核对你是不是这栋楼的业主、你的门禁权限有没有被暂停。ATM 就是那个"物业系统"，AccessToken 就是那张门禁卡。

2.2 三个关键标识：UserID、TokenID 与 AppID

在 ATM 的视角里，光有"应用身份"还不够，因为同一个应用可能运行在不同用户空间下。真正参与权限校验的标识有三个：

• UserID：用户 ID，标记"是哪个用户在操作"。鸿蒙支持多用户空间，同一台设备上的不同用户，各自的权限状态是互相隔离的。
• TokenID：访问令牌 ID，ATM 在应用启动后分配，相当于"门禁卡编号"。权限校验时主要用这个 ID 去查权限状态。
• AppID：应用 ID，由包名和签名信息共同决定，同一个应用重装后签名变了 AppID 也会变。

实际开发中，绝大多数情况下你不需要主动构造这些 ID，而是从上下文对象里直接取。比如在 UIAbility 的页面里可以通过getContext(this).accessTokenId拿到当前应用的 TokenID，后面做显式权限校验时会用到。多用户切换导致的权限异常、权限状态"神秘失效"，很多时候就是 TokenID 和 UserID 的绑定关系变了。

2.3 权限校验的两条路径

系统服务在调用链路上对权限的校验是隐式完成的——你在代码里调用相机接口，如果没权限，框架层会直接给你抛异常。这对开发者来说是省事的，因为大部分权限问题会在运行时报错时暴露出来。

但如果你的业务需要在 UI 上提前展示"有权限/没权限"的状态，就需要在代码里做一次显式校验。鸿蒙提供了verifyAccessToken接口：

import { abilityAccessCtrl, common } from '@kit.AbilityKit'; import { hilog } from '@kit.PerformanceAnalysisKit'; // 获取当前应用的 accessTokenId const context = getContext(this) as common.UIAbilityContext; const tokenId = context.accessTokenId; // 创建 ATM 管理器 const atManager = abilityAccessCtrl.createAtManager(); // 显式校验相机权限 const grantStatus = atManager.verifyAccessToken( tokenId, 'ohos.permission.CAMERA' ); if (grantStatus === abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED) { hilog.info(0x0000, 'Demo', 'Camera permission granted'); } else { hilog.warn(0x0000, 'Demo', 'Camera permission denied'); }

这里要注意，verifyAccessToken返回的是当前权限状态的一次快照。如果用户刚在系统设置里把权限关掉，下一次校验结果会立刻反映出来；反过来，如果用户刚授予权限，但你的页面还保留着旧的校验结果，UI 展示就可能出现"已经授权了却还显示未授权"的现象。所以显式校验最好放在真正需要执行敏感操作的节点上，而不是在页面加载时查一次就缓存到底。

3. 动态申请权限完整实操：从声明到弹窗再到回调

理论说完，开始上手。动态申请权限的完整链路可以分成三步：先在配置文件里声明权限，然后调用申请 API，最后处理用户授权结果。每一步都有讲究，尤其是第一步，很多人都栽在"只写代码不写声明"上。

3.1 module.json5 里先把声明写对

先看一个典型的module.json5权限声明：

{ "module": { "name": "entry", "type": "entry", "requestPermissions": [ { "name": "ohos.permission.CAMERA", "reason": "$string:reason_camera", "usedScene": { "abilities": ["EntryAbility"], "when": "inuse" } }, { "name": "ohos.permission.ACCESS_FINE_LOCATION", "reason": "$string:reason_location", "usedScene": { "abilities": ["EntryAbility", "LocationAbility"], "when": "inuse" } } ] } }

三个关键字段必须搞清楚：

• name：权限名称，必须是系统定义好的ohos.permission.XXX形式，不能自定义，拼错任何一个字母都会导致运行时"权限不存在"。
• reason：申请理由，用于授权弹窗里向用户解释"为什么需要这个权限"。实际发布时，应用商店审核也会重点核对这个理由和业务场景是否匹配。
• usedScene：使用场景，需要声明在哪个 Ability 里使用，以及使用时机是inuse（使用时）还是always（后台持续）。always类的声明审核更严格，能不用就不用。

经验：reason不要写成"提升用户体验"这种空话。填"用于扫码识别二维码"就比"用于提升功能完整性"通过率高得多。这是审核的硬要求，也是用户是否愿意授权的关键影响因子。

还有一个容易忽略的点：requestPermissions里只声明还不够，运行时还需要真正调用申请接口。也就是说，声明和申请是两步，声明解决"这个应用请求哪些权限"，申请解决"用户现在同不同意"。

3.2 requestPermissionsFromUser 的调用细节

运行时发起动态申请，核心 API 是requestPermissionsFromUser。一个完整的调用长这样：

import { abilityAccessCtrl, common, Permissions } from '@kit.AbilityKit'; import { BusinessError } from '@kit.BasicServicesKit'; async function requestPermission() { const context = getContext(this) as common.UIAbilityContext; const atManager = abilityAccessCtrl.createAtManager(); const permissions: Array<Permissions> = [ 'ohos.permission.CAMERA', 'ohos.permission.ACCESS_FINE_LOCATION' ]; try { const result = await atManager.requestPermissionsFromUser( context, permissions ); // result.permissions 与 result.authResults 按顺序一一对应 result.authResults.forEach((grantStatus, index) => { if (grantStatus === abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED) { console.info(`Permission ${result.permissions[index]} granted`); } else { console.warn(`Permission ${result.permissions[index]} denied`); } }); } catch (err) { // 请求过程本身失败，比如上下文失效、服务异常 const error = err as BusinessError; console.error(`Request permission failed, code: ${error.code}, message: ${error.message}`); } }

几个容易踩的细节：

• authResults数组的顺序和传入的permissions数组顺序是严格对应的，不能只判断第 0 个元素，否则有多个权限时容易漏判。
• 建议一次申请属于同一类业务场景的权限，比如进贴纸拍照页时同时申请相机和相册。如果一次性申请五六个不相关权限，弹窗会被系统拆成几个页面逐组展示，体验很差，授权率也会直线下降。
• 如果用户之前已经拒绝过某个权限，再次调用这个 API 时系统不会依赖缓存自动通过，而是会结合实际状态返回结果。对于"拒绝且不再询问"的情况，弹窗甚至不会出现，回调里直接返回拒绝。

3.3 用户点"拒绝"之后怎么办

动态申请里最考验产品设计的就是拒绝分支。很多开发者在用户拒绝后只会弹一个 Toast，然后就没有然后了。但用户一旦误点拒绝，后续功能就永久不可用，除非用户自己找到系统设置页去手动打开。

正确的做法是：检测到拒绝后给出引导入口，带着用户跳转到系统设置的应用权限管理页。这里我给一段跳转代码：

import { Want, common } from '@kit.AbilityKit'; import { BusinessError } from '@kit.BasicServicesKit'; function openPermissionSettings(context: common.UIAbilityContext) { const want: Want = { action: 'action.settings.app.detail', parameters: { bundleName: 'com.example.myapplication' } }; context.startAbility(want) .then(() => { console.info('Open settings success'); }) .catch((err: BusinessError) => { console.error(`Open settings failed, code: ${err.code}, message: ${err.message}`); }); }

这里有一个我不止一次踩到的坑：action的取值在不同系统版本上有差别，而且部分定制系统的设置页路径不完全一致。我的建议是保留这段代码的同时，在页面里叠加一个明显的文字按钮"去授权"，告诉用户"请在设置-应用-权限管理中打开相机权限"，两条路都走，才不会把用户卡死。

4. 走一个完整 Demo：拍照功能的权限申请全链路

理论再完整，不落到代码里都记不牢。这一节我拿一个"随手拍"页面做例子，完整走一遍：进入页面先查权限 → 没有权限就动态申请 → 拿到权限后调用相机能力 → 如果遇到拒绝就引导去设置页。

4.1 场景设定与事前检查

这个单页应用的业务逻辑很简单：页面正中放一个按钮，点击后打开相机拍照。相机的ohos.permission.CAMERA是 user_grant 权限，所以必须走动态申请。

在点击事件里直接调申请接口是最直观的写法，但我更推荐在页面初次可见时先做一次静默检查。好处有两个：一是可以提前在界面上展示"拍照权限未开启"的提示条，让用户有心理预期；二是避免用户第一次点按钮时被突如其来的弹窗打断操作。

事前检查逻辑：

import { abilityAccessCtrl, common } from '@kit.AbilityKit'; function isPermissionGranted(permission: string): boolean { const context = getContext(this) as common.UIAbilityContext; const tokenId = context.accessTokenId; const atManager = abilityAccessCtrl.createAtManager(); const status = atManager.verifyAccessToken(tokenId, permission); return status === abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED; }

4.2 封装一个权限管理器

为了避免在页面代码里到处散落createAtManager和回调处理，我通常会封装一个小工具类。这对于多个页面共用权限场景尤其有用：

import { abilityAccessCtrl, common, Permissions } from '@kit.AbilityKit'; import { BusinessError } from '@kit.BasicServicesKit'; export class PermissionManager { private static instance: PermissionManager | null = null; static getInstance(): PermissionManager { if (!PermissionManager.instance) { PermissionManager.instance = new PermissionManager(); } return PermissionManager.instance; } async checkPermission(permission: string): Promise<boolean> { const context = getContext(this) as common.UIAbilityContext; const tokenId = context.accessTokenId; const atManager = abilityAccessCtrl.createAtManager(); const status = atManager.verifyAccessToken(tokenId, permission); return status === abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED; } async requestPermission( context: common.UIAbilityContext, permission: Permissions ): Promise<boolean> { const atManager = abilityAccessCtrl.createAtManager(); try { const result = await atManager.requestPermissionsFromUser( context, [permission] ); return result.authResults[0] === abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED; } catch (err) { const error = err as BusinessError; console.error(`Request permission failed: ${error.code}, ${error.message}`); return false; } } }

单例的好处是：无论页面跳转多少次，ATM 管理器只要创建一次，权限判断逻辑也收敛在一个文件里。后续如果权限多起来，还能在这个工具类里扩展"批量申请""被永久拒绝时自动弹引导"等能力。

4.3 页面里怎么用，以及运行观察点

页面代码用的是 ArkUI 的声明式写法。核心思路是：按钮点击时先检查权限，有就直接进入拍照流程，没有就先申请，申请成功继续，申请失败展示引导弹窗。

import { common, Permissions } from '@kit.AbilityKit'; import { promptAction } from '@kit.ArkUI'; import { PermissionManager } from './PermissionManager'; @Entry @Component struct Index { private permissionManager: PermissionManager = PermissionManager.getInstance(); async handleTakePhoto() { const context = getContext(this) as common.UIAbilityContext; const cameraPermission: Permissions = 'ohos.permission.CAMERA'; const granted = await this.permissionManager.checkPermission(cameraPermission); if (granted) { // 已授权，直接进入相机页面或调起系统相机能力 this.openCamera(); return; } // 未授权，发起动态申请 const result = await this.permissionManager.requestPermission( context, cameraPermission ); if (result) { this.openCamera(); } else { promptAction.showDialog({ title: '需要相机权限', message: '请在系统设置中开启相机权限，否则无法拍照', buttons: [ { text: '取消', color: '#666666' }, { text: '去设置', color: '#007DFF' } ] }).then((value) => { if (value.index === 1) { this.openPermissionSettings(); } }); } } openCamera() { // 调起相机能力，实际项目中可能是跳转到录入页或调用系统相机 console.info('Camera is ready'); } openPermissionSettings() { // 参考 3.3 的跳转代码 } build() { Column() { Text('随手拍') .fontSize(24) .fontWeight(FontWeight.Bold) .margin({ top: 24 }); Button('拍照') .width(160) .height(48) .margin({ top: 48 }) .onClick(() => { this.handleTakePhoto(); }); } .width('100%') .height('100%') .justifyContent(FlexAlign.Start) } }

运行这个 Demo 时，建议盯着下面四个状态走一遍，覆盖到才算真正掌握动态申请权限的行为：

实测下来，第一个状态对应的行为最稳定，第四个状态最容易出幺蛾子，因为 "拒绝且不再询问"和"用户手动在设置里关掉"在系统内部被标记成了两种不同的状态，后续申请返回的结果也不完全一样。这个细节直接影响了第五章要讲的翻车场景。

5. 权限申请翻车现场：我踩过的坑与排查思路

这一节把我过去几个月在权限上遇到过的问题集中复盘一遍。每个问题都给出可复现的排查链路，而不是直接给结论，这样下次你遇到类似问题才能自己顺着路子找出答案。

5.1 声明了却没有弹窗：先查 PermissionName 和模块字段

症状：代码里明明调了requestPermissionsFromUser，设备上却一点反应都没有，回调直接返回失败。

我的排查顺序是：

1. 打开module.json5，确认requestPermissions里真的写着目标权限，且name完全正确。这个字段不能有一点拼写错误，比如ohos.permission.CAMERA和ohos.permission.CAMERA大小写不同，系统都视为另一个不存在的权限。
2. 确认usedScene.abilities覆盖了当前页面所在的 Ability。如果当前页面在EntryAbility，但usedScene里只写了OtherAbility，弹窗就不会出现。
3. 确认reason字段引用的字符串资源存在。如果$string:reason_camera对应的资源没定义，部分版本会在解析配置阶段静默失败，导致权限列表为空。
4. 确认目标权限是user_grant类型。system_grant权限不应该走动态申请，强行申请也没有意义，系统不会为这类权限弹窗。

前两步占了问题的八成以上。尤其是usedScene，老工程从低版本升级上来时经常漏补，属于典型的"看起来配置对了，实际上没生效"。

5.2 用户拒绝了就再也拿不到：授权状态机的理解偏差

症状：用户第一次点了拒绝，之后每次进入页面都直接进入失败分支，弹窗也不再出现。

这不是系统 bug，而是权限状态机的正常表现。鸿蒙对用户拒绝的处理分为两个阶段：

• 第一次拒绝：应用还可以再次发起申请，系统会重新弹窗。此时弹窗上可能还会额外提示用户"该权限上次已拒绝"。
• 多次拒绝或勾选了"拒绝且不再询问"：系统把权限标记为永久拒绝，之后requestPermissionsFromUser不会再弹窗，而是直接返回拒绝结果。

产品上的应对策略是：在失败分支里，不要反复去调申请接口，而是把用户往设置页引导。或者提供一个"检查权限状态"的按钮，让用户在主动操作后再回来继续业务流程。

5.3 Context 不对导致的弹窗起不来

症状：点击按钮后，权限弹窗一闪而过，甚至完全不出现，日志里报"context invalid"相关错误。

这个坑主要出现在把申请逻辑封装到了非页面类里。在鸿蒙里，动态申请的context必须是UIAbilityContext或与其相关的能力上下文。如果在纯工具类、数据仓库类、或者globalThis上随便取一个 context 去调用，很可能会因为上下文不具备拉起授权弹窗的能力而失败。

我的处理习惯是：所有需要弹窗的权限申请方法，都要显式从调用方传入UIAbilityContext，比如上一章封装的PermissionManager.requestPermission(context, permission)。内部再校验一下 context 类型，不行就抛错提示调用方式不对，避免线上静默失败。

5.4 多用户与设备账号切换的隐藏槽点

症状：同一个应用，在设备上切了用户空间或换了访客模式后，原本已授权的权限变成未授权，且重新申请时弹窗文案也变了。

原因就是第二章讲的，权限状态和 UserID、TokenID 是绑定的。多用户空间下每个用户的授权记录相互隔离。测试时如果有"访客模式""工作空间"之类的多用户场景，务必在权限用例里覆盖一遍，否则用户切换账号回来后的流程很可能是断的。

此外，应用被卸载重装后，原有的授权记录也会被清空。如果业务对权限状态做过本地缓存，记得在重装后重新走一遍动态申请，不能直接拿旧的缓存结果去判断。

6. 权限方案设计的一点经验：从能用变成好用

权限申请不只是技术实现，它本质上是一个产品体验和用户信任问题。同一款应用，权限弹窗设计得好的，授权率可能高出三成以上。这一节聊聊我在项目里沉淀下来的方案设计经验。

6.1 最小权限原则怎么在产品里落地

最小权限原则挂在嘴上很容易，落到设计上需要回答三个问题：这个功能真的需要权限吗？需要哪个权限？能不能晚一点再要？

我在一个笔记应用里就是这么处理的：用户写文字不需要任何敏感权限，真正需要图库权限的是"插入图片"这个动作。所以我没有在启动时申请图库，而是在用户点击插入图片按钮的前一瞬才发起申请。这样做的结果有两个：启动时的弹窗污染降为零，用户对应用的第一印象明显更好。

另一个更细的决策是：能申请粗粒度权限就不申请细粒度。比如只做天气展示，ACCESS_COARSE_LOCATION就够了，非要申请ACCESS_FINE_LOCATION反而会让用户警觉，也过不了审核的用途审查。

6.2 单次授权和"仅使用期间允许"怎么选

新版本系统的授权弹窗里，用户其实有三个选项：允许、拒绝、仅使用期间允许（或类似的一次性授权形式）。不同授权选项对应的运行状态不一样，"仅使用期间允许"在应用退到后台一段时间后会自动撤销授权。

这对位置类功能影响最大。比如打车软件需要在后台持续上报位置，那么申请ACCESS_BACKGROUND_LOCATION类权限时就要接受更严格的审核和使用场景说明；而一个只看当前定位的天气应用，用"仅使用期间允许"就完全够用，既保护了用户隐私，也降低了商店审核时对权限用途的追问概率。

6.3 测试阶段怎么快速覆盖各种授权状态

权限测试最烦的地方是状态多、组合多。手动去系统设置里反复开关权限，不仅慢，还容易漏。

我建议在测试阶段做到三点：

• 写一个内部测试页面，专门一键列出当前应用持有的所有权限及授权状态，方便回归前快速盘点。
• 在自动化测试中把"拒绝授权"分支作为独立用例跑一遍，不要只测快乐路径，否则拒绝引导逻辑很容易变成无人维护的僵尸代码。
• 每次改动权限声明或授权流程后，都要在"首次安装授权、拒绝后重启应用、设置页手动关闭、多用户切换"四组状态下各回归一轮。前三条覆盖的是常见场景，最后一条最容易漏，但出问题后影响也最隐蔽。

我自己在实际操作中的体会是：权限方案做得好不好，不看代码写得有多漂亮，而是看用户在误操作后能不能自己走回来。把拒绝分支做完整，把设置页引导做顺滑，把授权状态展示准确，比多写十个功能接口都更能拉高应用的评价。这套权限金字塔 ATM 模型和动态申请权限的理解，都会落到这些真实细节里。