K1.12.4cross-platform permission assumption设计
跨平台应用不能假设某权限在所有系统上行为一致
别名: 跨平台权限 · permission status enum · 权限适配
概念解释
同一套跨平台代码里调用「申请相机权限」，不能假定返回值、空状态、设置路径和失败后的界面在每个系统上可互换。封装层常把各系统的状态压成允许 / 拒绝两个值，把「未决定」「受限制」「仅本次」「有限图库」抹掉。产品若按其中一个系统写完分支，在另一个系统上就会出现点了允许却仍失败、点了重试却没有对话框、去设置却打开错误页。这条谈的是跨平台假设本身会在哪里裂开，时机、覆盖范围、再请求规则是裂开的原因，但各自已有专页；这里只处理「一套逻辑走天下」为什么不成立。
机制
跨平台框架用一套 API 去调底层不同的权限管理器。枚举对齐时，一端的「受限制」被标成「拒绝」，产品于是画出「去设置打开」，人到了设置里却没有可拨的开关——限制来自家长或配置文件。一端的「仅本次」在进程结束后回到未决定，下一冷启动又问；若产品把仅本次存成「已永久允许」，第二次启动会跳过申请并在调用时崩溃或黑屏。设置深层链接的 scheme 各系统不同，照抄「打开应用设置」在定制系统上会落到无关页。还有一端根本没有这道权限（某能力是默认可用或根本不存在），封装层仍返回「已允许」，功能却做不出来，人以为是产品缺陷。假设的危害不在某一条规则写错，而在用一个系统的状态机去解释另一个系统的返回值。
边界
只发布在单一系统、且最低版本已冻结的应用，不必为不存在的平台写分支；一旦增加第二个系统或跨过大版本，假设立刻失效。纯网页产品走浏览器权限模型，那是第三套状态机，不能复用原生封装的允许 / 拒绝。测试机若全是同一厂商的同一大版本，封装层的错误映射测不出来。服务端无法代为申请设备权限，跨平台一致性只能在客户端按系统拆，不能靠接口返回一个「权限 OK」了事。
怎么落地
- 在封装层下面保留各系统的原始状态，产品分支按「未决定 / 允许 / 拒绝 / 受限制 / 一次性 / 有限范围」书写，而不是只判断布尔值。
- 为每个系统单独验收：第一次申请、拒绝后重试、去设置的落点、仅本次与受限制。共用同一张流程图只允许画到「进入该系统的状态机」为止。
- 验证：用同一套跨平台构建在三个系统上走「拒绝相机再重试」。记录系统框是否出现、设置页是否为相机项、仅本次之后下次启动是否再问。任何一端与另外两端的按钮结果不一致，而代码只有一条分支，就是假设还在当通用规则用。