编程之道：推崇详尽解构

背景

在编程中，结构体（struct）的解构（destructuring）是一种常见的操作，可以从一个复合数据结构中提取出所需的字段。不同语言在这方面的语法和灵活性各异。原文作者最初在学习 Rust 时，对解构结构体必须列出所有字段或使用 .. 语法感到困扰——相比之下，TypeScript 和 Haskell 允许只提取需要的字段，写法更简洁。例如，对于 WeatherReading 结构体，只想取出 station_id 和 recorded_at，Rust 必须写：

let WeatherReading { station_id, recorded_at, .. } = weather_reading;

而 TypeScript 只需 const { station_id, recorded_at } = weather_reading;，Haskell 借助扩展也能做到类似简洁。这种差异让作者一度倾向于使用点号访问字段（如 weather_reading.station_id）。

核心内容

然而，在几个月实践后，作者开始强烈偏好结构体解构（尤其是穷尽列出所有字段并显式忽略不需要的字段），而不是直接用点号访问，因为这种做法能大幅提升软件维护的安全性。

问题场景：添加新字段带来的隐患

假设有一个 WeatherReading 结构体，最初包含以下字段：

struct WeatherReading {
    station_id: String,
    recorded_at: DateTime<Utc>,
    temperature: f64,
    humidity: f64,
    pressure: f64,
}

现在编写一个判断天气是否危险的函数 is_dangerous，采用点号访问每个字段：

fn is_dangerous(weather_reading: &WeatherReading) -> bool {
    if weather_reading.temperature > 40.0 { return true; }
    if weather_reading.humidity < 5.0 { return true; }
    if weather_reading.pressure < 960.0 { return true; }
    return false;
}

后来，气象站增加了风速测量，开发者给 WeatherReading 添加了一个新字段 wind_speed: Option<f64>。代码依然能通过编译，但 is_dangerous 函数完全没有考虑风速——强风应该也被判定为危险，但编译器不会给出任何警告。这种遗漏在大型项目中很容易发生，而且难以察觉。

解决方案：穷尽解构（Exhaustive Destructuring）

如果换用穷尽解构的方式编写 is_dangerous，情况就不同了。在函数参数中直接对结构体进行模式匹配，显式列出所有关心和忽略的字段：

fn is_dangerous(
    WeatherReading {
        station_id: _,
        recorded_at: _,
        temperature,
        humidity,
        pressure,
    }: &WeatherReading
) -> bool {
    if *temperature > 40.0 { return true; }
    if *humidity < 5.0 { return true; }
    if *pressure < 960.0 { return true; }
    return false;
}

当 wind_speed 字段被加入后，编译器会报错 error[E0027]: pattern does not mention field 'wind_speed'，迫使开发者主动决定如何处理这个新字段——要么在函数中添加对应的处理逻辑，要么显式忽略它（写为 wind_speed: _）。这样就有效防止了遗漏。

需要注意的是，要利用这个技巧，必须 穷尽地列出所有字段（包括用 _ 忽略的），并 抵制使用 .. 模式 的诱惑。因为 .. 会隐式忽略剩余字段，编译器就不会报错。

在方法中的应用

Rust 中 self 不能直接在参数列表里解构。如果 is_dangerous 写为方法，需要增加一些仪式：

impl WeatherReading {
    fn is_dangerous(&self) -> bool {
        let WeatherReading {
            station_id: _,
            recorded_at: _,
            temperature,
            humidity,
            pressure,
        } = self;
        if *temperature > 40.0 { return true; }
        if *humidity < 5.0 { return true; }
        if *pressure < 960.0 { return true; }
        return false;
    }
}

尽管写法上多了一步，但同样获得了编译期的安全检查。

更广泛的应用场景

作者发现这个技巧在编写 CRUD 网络服务时尤其有用，尤其是在不同层（数据访问层、业务逻辑层、API 层）之间实现 From trait 时。如果某一层添加了一个字段，编译器会强制你在其他层的转换中显式决定是否传播该字段——要么在转换时带上，要么用 _ 忽略。这避免了隐含的遗漏。

此外，如果始终看到同一组字段被一起解构而其他字段被忽略，这可能是一个重构信号：这些字段应该被提取到单独的结构体中，体现更清晰的职责划分。

其他语言的对应情况

• TypeScript：可以使用 Required<Type> 类型来模拟类似效果（强制要求对象包含所有字段，否则报错），但不如 Rust 的模式匹配直观。
• Haskell：令人惊讶的是，目前没有现成的标准解决方案来实现类似的穷尽解构编译时检查，不过已经有一个相关的提案在讨论中。

关键要点

• 穷尽解构 vs 点号访问：使用点号访问字段不会在新增字段时触发编译错误，容易导致遗漏更新相关函数；而穷尽解构（显式列出所有字段）可以强制编译器检查。
• 强制显式处理新字段：当结构体增加字段后，任何使用了穷尽解构的代码都会立即报错，迫使开发者主动决定如何处理新字段，从而避免安全隐患。
• 必须放弃 .. 模式：使用 .. 会隐式忽略剩余字段，相当于放弃了编译期检查。要获得安全性，必须显式列出所有字段并用 _ 忽略不需要的。
• 适用于方法及 trait 实现：尽管在方法中需要额外一层 let 解构，同样能获得相同的安全检查效果；在 From 等 trait 实现中尤其有用。
• 隐含的重构信号：如果多个函数都解构相同的几个字段而忽略其他字段，可能暗示这些字段应当被提取为独立结构体，改善代码组织。
• 跨语言实践：TypeScript 可以利用 Required 类型达到部分类似效果；Haskell 目前尚无成熟方案，但已有提案。

意义与影响

1. 提升代码安全性与可维护性：穷尽解构将“需求变更引发函数遗漏”这类运行时错误转化为编译期错误，极大减少了隐患。在多人协作或长期迭代的项目中，这种习惯能显著降低回归风险。
2. 语言特性对编程习惯的塑造：Rust 的模式匹配与所有权系统天然支持穷尽检查，鼓励开发者采用更严谨的解构方式。相比之下，TypeScript 和 Haskell 的简洁语法虽然方便，但可能让开发者放松警惕。这一实践体现了语言设计如何引导安全编程。
3. 推动工具和生态改进：Haskell 社区对类似提案的关注表明，开发者已经意识到编译期穷尽检查的价值。未来可能会有更多语言提供相关语法或 lint 规则来模拟这种行为。
4. 对 CRUD 服务和分层架构的启示：在多层转换（DTO、实体、API 响应等）中，穷尽解构使得字段的新增与传播变得可追踪，避免出现某些层遗漏字段导致的隐藏 bug。这为系统演化提供了更可靠的保障。
5. 平衡简洁与安全：作者最初因 Rust 解构的冗长而感到沮丧，但最终认识到这种“仪式感”背后的价值。这提醒我们：编程语言中的语法选择往往权衡了表达力、安全性和开发效率。在一些关键代码中，牺牲一点打字便利来换取编译时保障是值得的。