语言选择原则：性能 vs 可维护性的真实取舍（一点碎碎念）

笔者这里发一个小牢骚，我注意到不少同志似乎对工具选择缺乏某一种理性思考，也就是说——基于标签而不是实际表现行为来评价工具，导致语言选择常常被讲成一种道德判断：“C 是纯粹的、贴近硬件的真实工程；C++/Rust 是高级而懒惰的生产力工具。”把它说成道德问题没错很有感情，但对工程决策毫无帮助。真正的工程问题不是“哪种语言更高级”，而是“现在这台机器、这条时序、这群人、这份产品路线图，哪种做法让我们在合理的成本内把东西做对且做完”。性能和可维护性并非天生对立的两团魔法，它们在不同的维度上带来不同的风险与开销——最大的错误是把语言当作万能钥匙或末日药方，而不是工程工具链的一部分。

先说清楚“性能”在嵌入式语境下到底指什么。性能不是单纯的 CPU 基准分数，它包括闪存占用、RAM 占用、启动时间、实时中断延迟、功耗，以及时序可预测性。你在 Cortex-M0 上跑一个必须在 5µs 内完成的中断处理例程，和在 Raspberry Pi 上跑一个 UI 线程有着完全不同的“性能”含义。可维护性也不是抽象的“代码漂亮”，而是指团队能否在未来六个月到三年里稳定复用、修复与扩展这套代码：是否容易写单元测试、是否能在 CI 上复现 bug、接手的人能否在一周内理解模块边界。

把两者放到实际情形里讨论更有用。例如当内存与确定性是硬约束时，你需要那种把所有开销显式交给工程师的语言/风格。下面是常见的中断处理器在 C 里的写法：这段代码把开销和边界都交给了人来把控。

// IRQ handler - 必须尽快返回
void TIM2_IRQHandler(void) {
    if (TIM2->SR & TIM_SR_UIF) {
        TIM2->SR &= ~TIM_SR_UIF;
        // 尽可能少做事情：设置标志，或写环形缓冲一字节
        rx_ring_put(&uart_rx_ring, TIM2->CNT); 
    }
}

如果你要在中断里做内存分配、抛异常或者调用复杂的虚函数，那就得非常小心。那并不是语言天生坏，而是使用不当会带来不可预测的延迟。现代 C++ 本身并不排斥高性能；它的“零开销抽象”是可以实现的，但前提是有一套被团队认同并能被自动化工具检查的约束：禁用异常和 RTTI（给咱们的编译器上指标-fno-rtti），限制堆分配，使用 constexpr 与 std::array 替代 new。一个常见且实用的模式是在高层使用 C++ 的抽象，在低层（尤其是 ISR）使用受限的、确定性的实现，这样既保持了高层的可维护性，又保证了关键路径的可预测性。示例代码如下，展示 RAII 用于资源清理而不依赖堆分配：

struct ScopedIrqLock {
    ScopedIrqLock() { __disable_irq(); }
    ~ScopedIrqLock() { __enable_irq(); }
};

void append_log(const char* msg) {
    ScopedIrqLock lk; // 在栈上进行可预测的进入/退出
    // 写入静态缓冲区或通过 DMA 提交
    ring_buffer_write(&log_buf, msg, strlen(msg));
}

如果项目是那种需要严格认证、内存安全非常重要的场景（医疗设备、汽车 ECU 等），那么语言选择还要把认证成本和错误代价一并算进来。在这种场景里，语言能在编译期阻止某类错误本身就是价值。例如 Rust 的借用检查可以在很多情况下避免数据竞争和悬挂指针，这直接降低了后期验证和修复的工作量。但引入新语言也意味着工具链、编译器支持、第三方库成熟度以及团队学习成本都要评估清楚。没有哪种语言可以自动替你完成合规性工作；语言只是把某些错误提前移到编译期以减少运行时风险。

最后要说的是长期拥有成本。维护成本体现在调试时间、修复缺陷、团队交接与未来扩展难度上。很多时候，良好的测试、可复现的构建流水线、清晰的模块边界和详尽的文档对总成本的影响，远大于在某些微基准上节省的那几毫秒。选择一门能让团队稳定产出并容易进行代码审查与自动化测试的语言，往往比在单核峰值性能上赢得一点点更有意义。

总之，语言选择不是在性能和可维护性间做一刀切的牺牲，而是把项目的约束、错误代价、团队能力和长期维护成本放在一张表上比较的结果。用数据证明瓶颈所在，按模块分层使用不同工具，制定并用自动化手段执行受控语言子集，最终目标是把“可预测的成本”降到最小。要记住的工程智慧很简单：用对的工具做对的事，而不是把工具当成信念。