大家好，我是[晚风依旧似温柔]，新人一枚，欢迎大家关注~

📌 前言

（——没有比“请求权限”更能劝退用户的事了，但你不懂它更可怕）

坦白讲，在所有移动平台上，权限都是开发者又爱又恨的存在。
爱它，是因为没有权限你什么都干不了；
恨它，是因为用户一看到权限弹窗就想点“拒绝”，仿佛你要偷他家 Wi-Fi 密码一样。

而到了鸿蒙系统 HarmonyOS，权限体系进一步强化，安全分级也更细、审核也更严格。如果你对权限模型理解不够清晰，轻则功能跑不动，重则应用根本无法上架。

今天这篇文章，我就用比较“人能听懂”的方式，把鸿蒙权限模型这摊事儿讲得透透的。依然是专业深度 + 人类语气的风格，拒绝无聊的文档式啰嗦。

📌 第一章：静态权限 vs 动态权限 —— 这是鸿蒙权限的灵魂分界线

如果你刚开始接触鸿蒙，你会发现权限分成两类：
静态声明权限（manifest 中写）
动态请求权限（运行时弹窗请求）

其实这两者最大的区别就一句话：

静态权限是“提前打招呼”，动态权限是“现场要同意”。

我们来逐一拆开说说。

🎯 1.1 静态权限：写在配置文件里的“户口本登记”

静态权限必须声明在 module.json5 或 config.json 中。
系统在安装应用时就会读取这些权限的存在。

示例：

"requestPermissions": [
  {
    "name": "ohos.permission.CAMERA"
  },
  {
    "name": "ohos.permission.LOCATION"
  }
]

静态权限其实并不算“申请权限”，更像是“我这个应用将来可能要用这些能力”。

用户不会因此看到弹窗，只有在真正调用接口时才触发动态权限流程（若该权限为动态权限类型）。

静态权限两大核心作用：

1. 告诉系统应用有什么需求（否则系统不会让你调用任何敏感 API）
2. 在应用审核阶段让审核人员判断你是否合理使用该权限

一句话总结：
静态权限 = 白纸黑字地写出来：“我需要这些能力（但我还没用）”。

🎯 1.2 动态权限：用户必须点击“允许”才能生效

动态权限才是用户看到的弹窗那种：

“是否允许 xxx 访问相机？”

这些权限必须在运行时通过 API 调用：

import abilityAccessCtrl from '@ohos.abilityAccessCtrl';

let atManager = abilityAccessCtrl.createAtManager();

atManager.requestPermissionsFromUser(this.context, ["ohos.permission.CAMERA"])
  .then((data) => {})

动态权限的本质是：
只有在需要时才向用户询问授权，否则不允许直接访问设备能力。

🎯 1.3 鸿蒙权限体系特别之处

鸿蒙把权限按风险等级做了细分：

• 普通权限（不需要动态授权）
• 受控权限（需要动态授权）
• 最高敏感权限（部分需要系统签名）

比如：

• 相机、麦克风、位置 → 受控权限
• 后台运行、系统设置修改 → 审核严格
• 系统服务类权限 → 必须系统签名（普通开发者没法用）

权限模型比安卓更严格，审核也更狠。

具体有多狠？
——你申请了一个明明没用的权限，审核直接给你揪出来。

所以项目里一定要严格区分权限类型，否则你将面临反复“被打回重做”的痛苦。

📌 第二章：鸿蒙常用权限清单（最实用版本）

此部分我不会把几十页权限文档照搬给你，而是给你实际开发中最常用、最实战的权限分类。

---

📷 2.1 摄像头与媒体类

权限	说明
ohos.permission.CAMERA	调用摄像头
ohos.permission.MICROPHONE	使用麦克风
ohos.permission.READ_MEDIA	读取媒体文件
ohos.permission.WRITE_MEDIA	写入媒体文件

摄影、扫码、视频录制都会用到这些。

📍 2.2 位置类权限

权限	描述
ohos.permission.LOCATION	一般位置权限
ohos.permission.LOCATION_IN_BACKGROUND	后台定位（极其敏感）

如果你做打车、导航类产品，肯定需要后台定位，但该权限审核极为严格。

🗂️ 2.3 存储权限

权限	说明
ohos.permission.READ_USER_STORAGE	读取用户文件
ohos.permission.WRITE_USER_STORAGE	写用户文件

---

📞 2.4 通讯权限（敏感度非常高）

权限	说明
ohos.permission.READ_CONTACTS	读取通讯录
ohos.permission.GET_TELEPHONY_STATE	获取电话状态

注意：大部分普通应用不能随便申请这些权限。

---

🔊 2.5 其它常用权限

权限	用途
ohos.permission.INTERNET	网络访问（几乎所有应用都要）
ohos.permission.BLUETOOTH	蓝牙操作
ohos.permission.VIBRATE	控制震动

以上权限不一定都需要动态申请，有些是普通权限。

---

📌 第三章：请求权限的完整实战代码（含最佳实践）

好了，说了这么多，你肯定想直接看代码。

我给你一个最标准、也最推荐用的请求权限写法。

---

🎯 3.1 获取权限管理器

import abilityAccessCtrl from '@ohos.abilityAccessCtrl';

let atManager = abilityAccessCtrl.createAtManager();

---

🎯 3.2 查询当前权限状态

let grantStatus = await atManager.checkAccessToken(
  this.context.tokenId,
  'ohos.permission.CAMERA'
);

if (grantStatus === abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED) {
  console.log('权限已授权');
}

---

🎯 3.3 请求权限（用户弹窗）

let result = await atManager.requestPermissionsFromUser(
  this.context,
  ['ohos.permission.CAMERA']
);

if (result.authResults[0] === 0) {
  console.log('用户已授权');
} else {
  console.log('用户拒绝授权');
}

requestPermissionsFromUser 返回的结构如下：

authResults: [0] // 0 表示授权成功
permissions: [...]

---

🎯 3.4 推荐的权限工具函数（实际项目必备）

很多项目写权限时喜欢重复代码，下面给你一个最常用的权限工具封装：

async function requestPermission(context, permission) {
  let atManager = abilityAccessCtrl.createAtManager();

  const status = await atManager.checkAccessToken(
    context.tokenId,
    permission
  );

  if (status === abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED) {
    return true;
  }

  const result = await atManager.requestPermissionsFromUser(
    context,
    [permission]
  );

  return result.authResults[0] === 0;
}

用法：

const ok = await requestPermission(this.context, 'ohos.permission.CAMERA');

if (ok) {
  this.startCamera();
}

非常干净利落。

---

📌 第四章：隐私与安全注意事项 —— 你可能觉得麻烦，但审核比你更严格

鸿蒙非常强调隐私和安全，尤其是 HarmonyOS NEXT 更是强化了一整套用户数据保护体系。

下面我告诉你几个最容易“踩雷”的地方。

---

⚠️ 4.1 不能用权限做与权限无关的事情

例如申请位置权限却只用来推送广告。
这种行为直接导致：

• 审核拒绝
• 甚至封号

不要侥幸。

---

⚠️ 4.2 必须提供权限用途说明（隐私弹窗）

华为审核要求所有敏感权限必须加入“用途说明”，也就是：

• 为什么需要这个权限？
• 用户拒绝会影响哪些功能？

必须放在 UIAbility 的隐私声明弹窗里。

---

⚠️ 4.3 不允许在应用启动时立刻请求所有权限

这是很多开发者的通病。
你一打开应用，“滴滴滴滴”弹一堆权限，用户直接跑。

正确做法：

• 在“需要用到”时再请求
• 必要时给二次解释页（例如相机功能页）

---

⚠️ 4.4 后台定位等敏感权限需要更严格的审核证明

后台定位需要满足以下条件：

• 必须是导航、打车、运动类应用
• 必须在应用内提供“功能解释页面”
• 必须在应用描述中公开标注

否则上架审核必拒。

---

⚠️ 4.5 不允许偷偷收集用户数据

不解释了，现在所有平台都抓得严得要死。

---

📌 第五章：应用发布阶段如何处理权限（审核重点）

这一章非常关键。
你权限写得再漂亮，只要审核不过，整个应用就发布不了。

---

🎯 5.1 应用市场要求

华为应用市场对权限审核主要看三点：

1. 是否合理申请权限

例如：
记事本申请读取通讯录 → 不合理
相机应用申请麦克风 → 合理（视频录制需要声音）

2. 是否按需动态请求

如果你在应用启动就请求权限，就被判“不合理提示”。

3. 是否向用户清晰解释用途

这部分很多开发者做得很差。

---

🎯 5.2 HAR / 依赖库也会触发权限！

例如引用了第三方库，而库内部声明了权限。

这会导致：

• 你明明没用某权限
• 审核却要求你解释用途
• 你解释不了 → 审核拒绝

解决方案只有两个：

1. 去掉该依赖
2. 找能替代的无权限依赖

---

🎯 5.3 发布前清单验证

正式发布前，必须确保：

✔ requestPermissions 中没有用不到的权限
✔ 动态权限只在使用前触发
✔ 代码中未使用隐私敏感 API
✔ 用户拒绝权限时不会崩溃
✔ 提供权限使用说明
✔ 未开启后台定位等敏感权限（除非必要）

---

🎯 5.4 通过华为审核的“黄金法则”

你申请的每一个权限，都必须符合下面三点：

1. 应用真的需要
2. 用户使用中能看到相关功能
3. 代码中确实调用了对应能力

只要遵循这一点，审核基本稳过。

---

📌 总结：权限不是“可有可无”，而是鸿蒙应用能否落地的基础工程

如果你能把本文这 5 大章节的内容搞明白：

• 静态 vs 动态权限区别
• 常用权限的合理场景
• 权限请求代码与封装
• 隐私与安全注意事项
• 上架审核需要关注的关键点

那么你的鸿蒙应用在权限这块基本已经“毕业”了。

权限体系看着很烦，但只要逻辑清晰，遵循规范，它甚至能帮助你让项目结构更加严谨，用户体验也更加合理。

毕竟，真正好的应用不会无脑要权限，而是恰当地、透明地告诉用户“为什么需要它”。

如果觉得有帮助，别忘了点个赞+关注支持一下~
喜欢记得关注，别让好内容被埋没～