功能缺失需说明而非静默隐藏
别名: 功能不可用说明 · 原因码 · 受限功能状态 · unavailable feature message
概念解释
可解释的不可用状态（explainable unavailable state）让原本合理期待某项功能的用户知道它当前不能使用、影响范围、可采取的下一步和可用替代方案，而不是让入口或已有内容无故消失。说明并不要求公开全部政策、风控或合规逻辑。界面应把服务端内部原因码映射为最小充分的公开类别，例如“账户设置不支持”“此资源为只读”或“暂时无法完成”，并避免确认受制裁状态、审查命中、账户是否存在、地理定位方法或安全阈值。
机制
静默隐藏会把策略结果伪装成信息架构变化：用户可能以为记错路径、权限丢失、数据被删除或产品故障。始终展示禁用控件也会造成噪声，并向无关用户暴露其无法申请的能力。选择取决于用户是否有合理期待和可行动路径：从未有资格、不可请求且披露名称本身有风险的能力可以隐藏；曾使用、由协作者提及、已有相关对象或可通过设置/管理员恢复的能力应保留可见状态和说明。原因码把易变政策与稳定文案解耦，也允许客户端在不获得敏感细节的情况下给出一致恢复路径。
怎么研究
为每个状态测试“用户预期 × 可行动性 × 披露风险”组合：新用户、既有用户、不同角色、共享链接进入、策略刚变化和服务暂时故障。让参与者回答发生了什么、内容是否还存在、谁能处理以及下一步是什么，记录错误归因、重复尝试、支持求助、放弃和成功恢复。安全评审需用账号枚举、地区探测、规则探测和响应差异作为威胁场景，比较文案、状态码、资源存在性、时序和重试行为。无障碍测试还应确认禁用状态、原因和替代动作能被键盘与辅助技术发现。
边界
“不要静默隐藏”不是要求把所有不可用项永久放进导航。没有行动价值的控件会增加负担，敏感能力名称或精确拒绝原因也可能帮助攻击者。通用安全措辞不能成为没有恢复路径的死胡同：合法用户至少需要知道是稍后重试、联系管理员、修改设置、复制/导出，还是该操作在当前上下文无法提供。网络故障、权限不足、地区策略和资源已删除应在内部保持不同原因码，即使公开文案因安全需要合并，也必须在受控日志和支持工具中可诊断。
怎么落地
- 为 capability 状态定义稳定公开模型：标题、最小原因类别、影响对象、暂时/永久/未知状态、可执行下一步、替代能力和支持入口；内部原因码与公开文案分层，详细策略只进入受控、脱敏日志。
- 若用户从未见过且无法申请该能力，或展示名称会泄露敏感信息，可隐藏入口；若功能刚失效、已有相关对象、来自共享链接或可恢复，则显示只读/禁用状态、保留上下文并解释下一步。
- 对策略拒绝保留未提交输入和可访问内容，提供安全的草稿、复制、导出或替代流程。原因未知时说明当前无法完成且可用性尚不能确定，允许安全重试，但不猜测地区，也不承诺是否或何时恢复。
- 端到端检查网页、移动端、通知、深链接和 API 的状态一致性；同时做枚举与差异响应测试，确认文案、状态码、时序和对象存在性不会泄露敏感规则，并验证合法恢复任务可完成。