直接说结论**鸿蒙上不是所有「看起来像受限」的权限都要申请 ACL真正要走 ACL 的只有 3 项我一次申请、全部通过。**但在这之前我差点因为「凭印象申请」把一批根本不用交的权限白交上去。如果你也准备鸿蒙上架、正在为「这个权限到底要不要申请 ACL」发愁这篇值得看完——判定规则、差点白交的清单、3 项一次通过的申请原因文案和提交细节全都给你照抄就能用。一、先解上篇的扣子根子就在 ACL上篇结尾我留了个扣子「随包自带 Node、npm、pnpm、Python、pip、uv 等运行时和工具」这条路走不通。根子就在这篇要讲的 ACL。这个坎我在更早的文章里就埋过伏笔当时叫它「第二层难点」——二进制证书个人开发者不可得。当时我想得很美插件市场要「一键安装」最省事的做法是把完整工具链随包带上用户装完应用Node、pnpm 全都有。结果一查鸿蒙的分发规则发现这事不是「申请个权限」那么简单而是一整套权限 证书的组合门槛。这篇把它彻底讲透。二、判定规则什么才需要 ACL踩坑的起点是搞清一个反直觉的判定规则受限开放权限需 ACL⟺provisionEnable true且availableLevel ∈ {system_basic, system_core}。翻译一下只有「需要开通provision」且「级别是 system_basic 或 system_core」的权限才需要走 ACL 申请。第一手判定依据就是 SDK 自带的权限定义目录每条权限的 level、provisionEnable 都写得明明白白。provisionEnable false的不管名字多唬人都是开放权限——写进requestPermissions声明即可把它们提交 ACL 就是浪费配额。这里有两个最常见的误判我差点就栽在第一个上名字带kernel.前缀 ≠ 受限。像kernel.IGNORE_LIBRARY_VALIDATION听起来像内核级权限实际是开放权限声明即可。grantMode: system_grant≠ 不用申请。受限权限绝大多数也是 system_grant——安装即授予但前提是发布 Profile 里有它没进 Profile照样不生效。这一条规则值回整篇文章先查provisionEnable再查availableLevel两个条件都满足才动手申请。三、最大的坎二进制证书个人不可得我最初的目标很「完整」随包自带 Node / npm / pnpm / Python / pip / uv让插件市场的「一键安装」开箱即用。结果第一道坎就过不去随包分发 ELF比如 Node 运行时需要「二进制证书」AGCcertType: 4而华为不授予个人开发者——它要求企业名称与资质只能走在线工单系统申请不是自助操作。这意味着「随包自带完整工具链」这条路对个人开发者直接封死。更坑的是连带效应那批为「自有 ELF」服务的 native 权限——ohos.permission.ALLOW_EXTERNAL_NATIVE_CODE、ohos.permission.kernel.LOAD_INDEPENDENT_LIBRARY——也一并失去意义。**我差点把这批权限白交上去。**ELF 过不了签名闸门这两项建议暂缓提交。不过路没有完全堵死有两条不需要证书的替代路线① 复用设备自带工具链应用 PATH 已含系统 hnp 目录② 进程内 JS 跑 pnpm不落 ELF、不 spawn。这里不展开先把权限侧讲完。四、差点白交6 项里只有 3 项需要 ACL痛定思痛后我按判定规则重新盘了一遍上架真正需要的权限。清单里 6 项只有 3 项需要 ACL权限level是否需 ACL用途kernel.ALLOW_WRITABLE_CODE_MEMORYsystem_basic✅ 需要内置 V8/Electron 引擎 JIT 编译READ_PASTEBOARDsystem_basic✅ 需要剪贴板文本/图片粘贴READ_WRITE_DESKTOP_DIRECTORYsystem_basic✅ 需要读写用户桌面目录READ_WRITE_DOCUMENTS_DIRECTORYnormal❌ 开放权限文档目录READ_WRITE_DOWNLOAD_DIRECTORYnormal❌ 开放权限下载目录FILE_ACCESS_PERSISTnormal❌ 开放权限文件选择器授权持久化后 3 项是normal级开放权限写进requestPermissions即生效首次访问弹窗授权在 AGC 的 ACL 列表里通常都无法勾选——提交它们就是「白交」。五、这类权限根本不存在执行 /system/bin/sh还有个高价值冷知识在鸿蒙上执行/system/bin/sh没有任何权限可申请。我把 SDK 的权限目录翻遍了ohos.permission.EXECUTE_CMD不存在也不存在任何以「执行 shell / 启动进程」为语义的权限。原因在于进程执行根本不由权限体系管辖而由 SELinux 域 seccomp 管辖叠加强制代码签名门禁。所以如果你做鸿蒙应用想着「我要执行 shell去申请个权限」这是方向性错误——这个权限不存在申请都不知道往哪填。六、看名字唬人、实则与你无关这些别申请ACL 有配额、有审核节奏别把额度浪费在看名字唬人、实则与你无关的权限上CUSTOM_SANDBOX仅华为内部可得上架不可得RUN_ANY_CODE无第三方正当用途申请了反而会降低整批权限的可信度四个*PLUGIN*权限只有分发「鸿蒙插件包」才需要而本工程插件是 Node 包一律不申请。一句话先问自己「这个权限服务我的什么功能」答不上来就别申请。七、申请原因怎么写3 项一次通过的文案ACL 审核的关键在「申请原因」≤256 字。我的写法就一条主线说清楚「用于什么、不用来干什么」。以最硬的kernel.ALLOW_WRITABLE_CODE_MEMORY为例申请原因里我死死咬住三句话仅用于内置 V8/Node 引擎的JavaScript JIT 编译保障 AI 对话与工具调用性能不用于应用热更新、不下载执行外部代码已适配**坚盾模式JShield**且该模式下不崩溃仅平板 / 2in1 设备。这三点正好命中官方对该权限的约束JIT 编译专用、禁热更新、适配坚盾模式所以一次过。另外两项同理READ_PASTEBOARD仅在用户主动粘贴时读取不在后台读取、不上传READ_WRITE_DESKTOP_DIRECTORY仅访问用户主动选择/授权的桌面目录不批量扫描磁盘。发现没有每一条都是「正面用途 明确排除」。审核方要的不是你多会写而是你清楚地知道边界在哪。八、提交与落地几个别踩的细节申请本身不难细节坑不少提交路径AGC → 开发与服务 → 项目 → 应用 → 项目设置 → ACL权限 → 勾「我已知晓」→ 选权限 → 填申请原因/使用场景 → 申请。配额与节奏单次最多30 个权限结果一起返回上一批未审完不能提交新一批。获批落点获批权限在创建发布 Profile 时自动写入。⚠️若 ACL 在 Profile 创建后发生变更必须重建 Profile——这个坑本工程真实踩过不重建构建出来的包就是不带新权限的。区域中国大陆账号正常支持海外账号仅支持亚太与欧洲。另存在「试用调试 Profile」5 天有效期、每应用最多 5 个可在正式 ACL 下来前先验证可行性。九、结果3 项一次通过最终这 3 项JIT 内存 / 剪贴板 / 桌面目录一次申请、全部通过。复盘下来通过的原因就一条**先用判定规则砍掉「白交项」再把申请原因写到官方约束的靶心上。**名额精准、文案收敛审核自然痛快。写在最后以上就是鸿蒙 ACL 权限申请的全过程**先搞清判定规则别凭印象申请二进制证书个人不可得断了「随包自带运行时」的念想最后 3 项受限权限一次通过。**如果你也在做鸿蒙上架这套「先判定、再精准申请、申请原因咬住官方约束」的思路可以直接抄。下一篇我写App 上架合规踩坑被 AppGallery 打回 12 条整改从商标撞名到 ArkWeb 合规一条条踩过去。关注公众号并设为星标别错过。代码已开源https://github.com/fellow99/dsh-desktop-hos 欢迎star支持。相关开源工程DeepSeek Harness上游项目https://github.com/deepseek-ai/deepseek-harnessdsh-market插件市场https://github.com/dsh-market/dsh-marketharmonypc-electronElectron-on-鸿蒙运行时https://atomgit.com/jianguoxu/harmonypc-electrondeepseek-harness-workspace工作区总览https://github.com/fellow99/deepseek-harness-workspacedsh-desktop桌面端https://github.com/fellow99/dsh-desktopdsh-desktop-hos鸿蒙端https://github.com/fellow99/dsh-desktop-hos感谢各位关注欢迎访问我的 GitHub 主页https://fellow99.github.io/