H4.09.4granular pickers weaken full-access justification设计
精细化权限选择器出现后，全量权限申请的正当性下降
别名: 选择器优先 · 全量正当性 · picker-first · limited library
概念解释
系统一旦提供「选中的照片 / 选中的联系人」这类选择器，产品再申请全部访问就必须单独证明：为什么枚举整库或整本通讯录是当前任务不可替代的。以前「没有别的 API」可以当理由；选择器出现后，这个理由消失。发图、邀人、换头像走选择器是默认，全量变成要辩护的例外。这条谈正当性如何随平台能力变化，不是选择器本身怎么用，也不是匹配好友时服务器留什么。
机制
授权的最小充分集随可选手段而变。没有选择器时，全量是完成「贴一张图」的唯一技术路径，必要性成立。有了选择器，同一任务的充分集缩小到所选文件，全量变成「为了方便以后、为了分析、为了预加载」——这些不是用户正在做的事。继续把全量当默认，是把平台已经拆开的粒度在产品里再捏回去，人会在系统弹窗上看到「选中的项目」却被应用引导去点「允许全部」，选择器的保护被绕开。正当性下降不是道德口号，而是任务—能力匹配：手段变了，原来的「必须」不再为真。
边界
备份整库、按人脸整理、企业通讯录只读目录、无选择器的旧系统版本，全量仍可能是最小充分集。应用若同时服务新系统与旧系统，应按能力分支：有选择器就走选择器，不能为了代码统一在全平台要全量。用户主动在系统弹窗里选了全部，产品可以接受，但不得用更大按钮、更吓人的「否则无法使用」把人从选中档推过去。
怎么落地
- 以平台是否存在选择器作为分支：存在则主路径不调用全量 API；全量入口单独放在管理/备份，并写清为何选择器不够。
- 系统弹窗出现「选中的项目 / 允许全部」时，应用的前置说明应对准选中档，不要把「全部」画成推荐。
- 审查旧代码里「一启动就请求图库或通讯录」的调用，能改选择器的改掉，并记下仍要全量的功能与理由。
- 验证：在提供选择器的系统上完成发送与邀请主路径，全量权限应保持未请求。统计全量弹窗的触发功能清单，每一项都要能回答「选择器为何不够」；答不出的触发点删掉。