强迫型：以功能为要挟换取同意
别名: 功能要挟 · bundled consent · forced consent
概念解释
强迫型（forced action）把「使用功能」与「让渡权利或信息」捆绑：想用就得同意、想继续就得交出通讯录、想看内容就得先装 app。它的定义特征是要挟结构——「不同意」不是被引导走开，而是被功能性地排除；其他三类还保留选择，强迫型取消选择。
机制
捆绑有效是因为它改写了用户评估的对象：同意本该是对「我是否接受这个条款」的独立判断，捆绑后变成「我多想要这个功能」——而后者的回答永远被任务动机抬高，用户为了一件事答应另一件事。捆绑同时摧毁同意的可分性：本可只同意必要部分，现在全有或全无。与前三类的分界清晰：干扰偏移选择，障碍惩罚选择，强迫取消选择。灰度在「合理捆绑」：相机应用要相机权限是功能必需，社交应用要通讯录才能用核心功能就是要挟——判定标准是被索要的东西是否为该功能所必需，必需性有客观答案，不随商业意愿改变。
怎么研究
权限索取研究做功能依赖编码：对主流应用逐个标注哪些权限为核心功能所必需、哪些是增值收集，必需率即强迫程度的基础数据。实验研究测捆绑同意对同意率、事后撤销率与后悔率的影响；判例研究（GDPR「不同意也应能用」原则的执法案例）提供规范性坐标。方法论注意点：实验室里告知「可以拒绝」本身会改变行为，真实场景的用户并不默认知道自己有拒绝权，测量时要区分「有权拒绝而未用」与「不知道可拒绝」。
边界
商业模式依赖是灰区：免费服务以数据换服务，属于「条款苛刻」还是「要挟」，取决于退出选项的真实存在性——市场里有可信替代品时是谈判，独家时是要挟。功能必需性随技术变化：以前必需的（读通讯录做匹配）被新方案（选人邀请）替代后，继续强制索要就转为强迫型，审计要定期重做。合规上强制同意在 GDPR 域已被明确排除，其他法域执行强度不一，合规不能替代设计判断。
怎么落地
- 建权限-功能映射表：每个索要的权限与同意标注「哪个功能必需」，映射不上的不得捆绑索要，改为功能触发时点索要。
- 保「最小可用」路径：拒绝非必需授权后核心功能保持可用，用降级体验而非锁死来表达后果。
- 验证：负例测试——以「全部拒绝」走完整流程并记录每一步，被锁死的每个点都是强迫型残留，进修改队列。