P4.04.3Protection by exclusion设计
保护措施不应以排除为形式
别名: 排除式保护 · protective exclusion · access denial as safety
概念解释
排除式保护（protection by exclusion）指以「不让风险人群使用」来实现安全：怕老年人被骗就要求视频人脸验证、怕残障用户误操作就直接禁用其账户功能、怕未成年人出事就把整个年龄段挡在服务之外。它把风险降为零的同时把服务也降为零——被「保护」者失去的是本应享有的访问权。正当的保护形式是改变服务的形态（提供安全模式、简化流程、加强确认），而不是改变准入的人群。
机制
排除成为默认选项，是因为它把风险从平台转移给了用户：拒绝服务的法律与声誉风险远小于允许使用后出事的责任，于是「拒之门外」成为法务最优解。但排除的成本外部化且不可见：被挡住的人不投诉（他们从没进入过）、不产生数据（没有使用记录）、不出现在指标里，排除的代价在仪表盘上是零。被排除者还要承担替代路径的代价——不能用正规转账的人转向更不安全的渠道，不能用主流平台的未成年人在无年龄护栏的环境里活动，保护的名义下风险只是换了地点且更难触达。身份验证式排除还有一道技术性排斥：越需要被包容的群体（无证件、无稳定地址、数字素养低）越难通过验证本身。
边界
排除并非永远不正当：法定年龄限制、金融合规的准入要求、明确的专业意见（如医疗设备的使用禁忌）属于必须排除的情形，问题只在于把「可以做得更包容」偷换成「必须挡住」。判定标准是比例性：是否存在同样有效的非排除手段？为剩余风险付出的包容代价是否与收益相称？「技术上难做安全的模式」常常只是优先级问题，不是不可能问题。
怎么落地
- 对任何「按人群限制使用」的决定做替代方案评审：至少列出两种非排除方案（安全模式、增强确认、陪护人机制）及其成本，书面说明为何不可行才能通过排除方案。
- 为高风险但被限制的人群设计降级可用路径：不能全功能使用时提供受限但有用的模式，而不是一行「您所在的用户组无法使用此功能」。
- 用无障碍与包容性标准预检验证式排除：验证流程本身若对无证件、低数字素养、辅助技术用户不可通过，即视为排除性设计。
- 验证：统计被限制人群的申诉与替代渠道使用情况；申诉集中于「我想用但被挡」而非「我不该被挡」时，限制的正当性需要重新论证。