权限模型基础：权限分类与权限等级
权限管理，说白了就是系统给应用发的一张「通行证」。
我刚开始接触鸿蒙时，觉得权限这东西很简单——要什么给什么呗。后来在项目中踩过坑才发现，权限模型的设计直接决定了系统的安全性。今天我们就来聊聊权限的分类和等级，这是理解鸿蒙安全机制的基石。
一、权限的两大分类
鸿蒙把权限分成两大类：系统权限和应用权限。这两者的区别，我习惯用一个比喻来解释——
- 系统权限：系统自己保留的「特权」，普通应用拿不到。比如修改系统设置、访问底层硬件。
- 应用权限：应用可以申请的「常规权限」，比如读取相册、使用相机。
你可能会问：为什么要把权限分这么细？
嗯，我在项目中遇到过这样一个场景：某个第三方应用申请了「读取设备信息」权限，结果它偷偷把IMEI号上传了。如果这个权限是系统级的，普通应用根本申请不到，问题就不会发生。所以分类的本质，就是控制风险范围。
核心区别一览：
| 类型 | 授予对象 | 典型例子 |
|---|---|---|
| 系统权限 | 系统服务、预置应用 | 修改系统时间、安装应用 |
| 应用权限 | 第三方应用 | 读取联系人、使用麦克风 |
二、权限的三个等级
光分类还不够。鸿蒙又把权限分成了三个等级：normal、dangerous、signature。这就像给权限贴上了「危险程度」的标签。
1. normal（普通权限）
这类权限风险很低。应用申请后，系统直接授予，不需要用户确认。
举个例子：读取网络状态、设置闹钟。这些操作不会泄露隐私，也不会破坏系统。
我个人习惯把normal权限叫做「自动放行」权限。你想想看，如果每次联网都要弹窗问用户，那体验得多糟糕。
2. dangerous（危险权限）
这类权限涉及用户隐私或设备安全。应用申请时，系统会弹窗让用户手动确认。
比如：读取通讯录、获取位置信息、使用相机。这些权限一旦被滥用，后果很严重。
我曾经在调试一个地图应用时，发现它申请了「读取短信」权限。我当时就警觉了——一个地图应用要短信干嘛？后来查代码才发现是第三方SDK偷偷加的。所以dangerous权限，一定要让用户知情。
避坑指南： 我曾经见过一个开发者，把所有权限都声明成dangerous级别，结果用户安装时被一堆弹窗吓跑了。记住：只申请你真正需要的权限，别偷懒。
3. signature（签名权限）
这是最高级别的权限。只有和系统使用相同签名的应用才能获取。
说白了，就是「自己人」才能用的权限。比如修改系统UI、访问系统级API。
我记得有一次，合作伙伴的应用需要调用一个系统级接口。他们申请了signature权限，但因为签名不一致，死活拿不到。最后只能通过系统预装的方式解决。
权限等级对比表：
| 等级 | 授予方式 | 风险等级 | 典型场景 |
|---|---|---|---|
| normal | 自动授予 | 低 | 读取网络状态 |
| dangerous | 用户确认 | 中 | 读取位置信息 |
| signature | 签名匹配 | 高 | 修改系统设置 |
三、知识体系结构图
下面这张图，帮你把权限分类和等级的关系理清楚：
四、实际开发中的注意事项
讲完了理论，说点实际的。我在项目中总结了几条经验：
- 权限声明要精确：别图省事把所有权限都写上。多一个权限，多一分风险。
- dangerous权限要动态申请：不要一启动就弹窗，等真正用到的时候再申请。用户体验会好很多。
- signature权限别乱用：除非你的应用是系统预置的，否则别碰这个等级。我曾经见过一个第三方应用试图申请signature权限，结果直接被系统拒绝安装。
小技巧： 在开发阶段，可以用鸿蒙的「权限调试工具」查看应用实际申请了哪些权限。我每次发布前都会跑一遍，确保没有多余的权限声明。
好了，权限分类和等级就聊到这里。记住一句话：权限不是越多越好，够用就行。下一节我们会深入权限的申请流程，到时候再细聊动态权限的处理细节。
公众号:蓝海资料掘金营，微信deep3321