一个被低估的语言特性：穷尽检查

在订单状态、支付流程或页面渲染里，switch 少写一个分支，程序通常不会立刻报错，它只会在某个边角输入下悄悄做错事。

穷尽检查经常被误认为只是“语法更好看一点”。它真正做的事是：当你列举一种数据的所有可能状态时，编译器帮你确认——是不是每一种都处理到了。

这类能力常见于带模式匹配的语言，比如 Rust、OCaml、Haskell，也部分出现在 TypeScript、Kotlin、Swift 这类语言里。表面上看，它只是让 match 或 switch 更严谨；实际价值是把一类常见 bug 提前拦在编译阶段，而不是留到运行时。

它解决的不是“写起来麻烦”，而是“改起来会漏”

普通代码里，常见的问题不是第一次写错，而是后来加了新状态，旧代码没跟上。

比如一个订单状态原来只有：

• 待支付
• 已支付
• 已取消

你在多个地方写了判断。后来业务加了一个“退款中”。这时最危险的往往不是数据库或接口，而是那些散落在各处的条件分支。

如果语言没有穷尽检查，很多地方会继续通过编译，然后在运行时落入默认分支，或者直接被当成“未知状态”。这种 bug 不一定会崩，它只是结果不对。

如果语言支持穷尽检查，编译器会直接提示：这里少处理了一种情况。每次模型变化，遗漏都会更早暴露出来。

为什么它被低估

因为很多人只把它当成“高级语法”。

if/else、switch、模式匹配，看起来都能完成分支判断，于是穷尽检查常被看成“写法偏好”。但它真正提供的不是写法，而是约束。

这类约束平时不显眼，只有在代码变复杂、状态变多、迭代变快的时候，差别才会放大。它不像性能优化那样可以跑分，也不像新框架那样容易演示；它更像一张防错网，存在感低，但漏一次就能感受到价值。

穷尽检查不能代替设计，但能逼着设计更诚实。状态定义如果本来就混乱，这个特性不会自动修复问题；它只是让混乱更早暴露出来。

它适合什么场景

1. 状态明确、数量有限的逻辑

最典型的是状态机。支付、审核、同步、任务调度、前端页面加载状态，都适合。

比如前端常见的几种数据状态：

• loading
• success
• error
• empty

如果只是用几个布尔值拼起来，isLoading、hasError、data === null 很快就会互相打架，甚至能组合出“既在加载又有成功数据”这样的矛盾状态。

如果用带穷尽检查的枚举或联合类型，编译器会提醒你：页面渲染时是不是把 empty 漏了。

2. 对外接口的返回值

很多代码习惯返回 null、空字符串、-1、默认对象。这些做法短期方便，长期容易变成猜谜。

更稳妥的方式，是明确列出“成功”“失败”“权限不足”“未找到”这类结果，再让调用方必须处理。这样代码读起来不是在推理隐含规则，而是在消费一份明确协议。

3. 经常被多人修改的代码

代码一旦不是只给自己看，穷尽检查的收益会更大。它减少的是“你以为别人会补，别人以为你已经补了”的空档。

它不适合什么场景

也别把它神化。

1. 状态本身是开放集合

比如 HTTP 状态码、用户自定义标签、外部平台不断新增的事件类型。这类集合不是你能完全控制的，强行追求穷尽，最后往往仍然要保留一个“其他”分支。

2. 只是简单脚本

几十行的一次性脚本，用不用穷尽检查，差别可能不大。特性越强，通常也意味着建模成本更高，不是所有代码都值得精细建模。

3. 团队还没养成“先定义状态”的习惯

如果大家还停留在“先写几个判断再说”，直接引入这类特性，常会变成语法负担。更合理的顺序是：先把状态想清楚，再让语言帮你守住边界。

怎么用得实际一点

不用一开始就追求完整的模式匹配体系。更现实的做法是：

先找最容易漏分支的地方

通常是这些位置：

• 状态流转
• 错误处理
• 接口返回
• 前端渲染分支

先把这些地方从“散装布尔值”改成“明确的有限状态”。

少用兜底默认分支

很多语言里，default 或 _ 分支写起来很省事，但也最容易把穷尽检查的价值抵消掉。

兜底不是不能写，而是要知道：一旦写了它，编译器通常就没法继续提醒你“新状态漏处理了”。如果场景确实是封闭集合，尽量把每个分支写明。

让数据结构表达意图

不要只想着“怎么判断”，先想“这个值到底有哪些合法形态”。语言特性真正帮到你的地方，不在分支语句，而在你是否把问题建模成了有限且清晰的集合。

真正被低估的，其实是编译期提醒

很多开发者愿意花时间加日志、补监控、做回滚，却不太愿意花精力让编译器多管一点。原因也不复杂：前者看得见，后者像是“还没出事”。

但有些问题，本来就不该留到日志和监控来发现。能在保存文件或编译时被指出来，就没必要等到请求进来才知道错了。

比起讨论模式匹配本身，也许更值得继续追问的是：哪些业务状态，真的值得被建模成一个有限集合？