不等于的陷阱

在仅有 A、B 两类时，使用 =A 或 !=B 确实能得到相同的结果，但二者逻辑不同：一个是直接选取，一个是反向排除，前提是你已明确“非 B 即 A”。

在编码中，我更倾向于使用 =A 来直接描述意图，因为这样更准确清晰。试想若未来新增 C 类，!=B 的含义就变得模糊——既可能是 A，也可能是 C，这种隐晦的表达容易埋下隐患。

当然，有时“不等于”在写法上确实更方便。例如在 a1～a5 属于 A 类、b1 和 b2 属于 B 类的场景中，用 value != b1 AND value != b2 表示 A 类，看似省事——即使未来新增 a6，也无需修改代码，仿佛“预测了未来”。在前后端分离项目中，这类写法还能减少两端的改动，似乎一举两得。

但我仍然不愿采用这种不直观的表达。因为它虽然方便了自己，却可能增加了他人的理解成本，也让代码更晦涩。对于因扩展带来的修改问题，我建议将分类设置为可配置项，例如后端从数据库读取分类集合，前端通过接口获取。这样新增类别时，只需更新配置，无需改动代码。

“不等于”看似能预测未来，令人着迷。可一旦预测失误，又未被及时发现，就可能引发难以预估的风险。相比不可控的“聪明”，我宁愿选择可控的“谨慎”。

此外，在数据库查询中使用“不等于”还可能导致索引失效。因为查询优化器难以预测不等于条件所匹配的结果集规模，进而无法高效利用索引。看来，“不等于”不仅试图预测未来，还会阻止别人预测它。

归根结底，优秀的软件工程实践倡导一种“实事求是”的精神：精准描述已知，审慎对待未知。直接定义“是什么”，是基于已知事实构建系统的基石；而依赖“不是什么”，则可能为未来埋下不确定的陷阱。系统的真正智慧，不在于它能多么“聪明”地预测变化，而在于它能多么“清晰”地表达现状，并为此后的演变留出稳定、可控的扩展路径。这时的代码，展现的是一种更高层次的优雅：那就是清晰、准确与稳定。