Rule — 禁止阉割式修复¶

触发场景：用户说「X 点了没反应」/「X 不能用」/「X 坏了」时，修复方案的第一冲动。

反面教材（v0.10.64 → v0.10.65）¶

ISSUE-0044 Bug 5: 用户截图质量分点击不排序
  → 我选: 把 quality 加进 unsortable，sortable:false
  → 结果: 表头不可点，连箭头都没。"明确告诉用户做不到"
  → v0.10.65 又撤回，加 hasEmailOnly 同款 client-sort 真排序
  → 多花一轮 + 用户截图二次抗议

核心错误：我跳过了"想想能不能真做"这一步，直接选了"承认失败"。

三段诊断（修之前必做）¶

1. 真的做不到吗？¶

现状	99% 真相
"DB 不支持这个 sort"	jsstore 不行 → 客户端 JS sort 行
"API 不返回这个字段"	客户端能算 / 别处能拼接
"组件库不支持"	wrap / 改 prop 一般能搞
"现有数据没这个"	migrate / backfill 一次性脚本

绝大多数"做不到"是做需要写代码 — 写就完了。

2. 不做 vs 做的成本对比¶

维度	不做（阉割）	做（真实现）
工程成本	5 分钟改 1 行	半小时~2 小时写一段路径
用户痛点	永久存在	一次性消除
截图重报概率	100%（用户记得这个功能）	0
后续翻车	下一轮 ISSUE 又要撤回	不再被提起

永久痛点 vs 一次性工程，永远选一次性工程。

3. 阉割是不是真的"诚实"？¶

❌ 不是。用户提 bug = 想用这个功能。阉割告诉用户"你想要的不可能" — 相当于否认需求。

正确"诚实"：在做不到时告知具体限制（"按 X 排序受 5w 上限"），而不是"按 X 排序不存在"。

何时才能用 disabled / hidden / sortable:false¶

只有当真实现的成本 > 100x 收益时才可以阉割。例子：

真要存数据库做 schema migration + 复杂 backfill + 跨版本迁移
涉及第三方 API 不在我们控制（成本不可控）
用户群极小（< 0.1%）

判断标准：如果你能描述出"做需要这些 step"且其中没有阻断点，就别阉割。

决策树¶

用户报"X 不能用"
    ↓
"为什么不能用？" — 找根因
    ↓
"客户端能做吗？" ← 90% 答案是能
    ↓ 能              ↓ 不能
真实现              "DB 能做吗？"
                   ↓ 能           ↓ 不能
                  写 migration   "用户能换方式吗？"
                                  ↓ 能         ↓ 不能
                                文档/提示      最后才考虑阉割

阉割是兜底，不是首选。

钩子语¶

修 bug 前默念：

"我能不能让它真正工作？"

答 yes → 做答 no → 再想一遍，真的 no 吗？还是 no → 才考虑阉割

案例库¶

ISSUE	阉割尝试	真实现	教训
0045 (本规则源头)	sortable:false	hasEmailOnly 同款 client-sort	50k 行 50ms JS sort 完全够用
未来	要么避免要么对照