语言选择原则：性能 vs 可维护性的真实取舍

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

性能在嵌入式里到底指什么

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

实际场景中的取舍

把性能和可维护性放到实际场景里讨论才有意义。当内存和确定性是硬约束的时候，我们需要那种把所有开销显式交给工程师来把控的语言和风格。下面是一个常见的中断处理器的 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 -fno-exceptions），限制堆分配，用 constexpr 和 std::array 替代 new。

一个非常实用的模式是：高层用 C++ 的抽象获得可维护性，低层（尤其是 ISR）用受限的确定性实现保证可预测性。下面这个例子展示的就是用 RAII 做资源清理，但不依赖堆分配：

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

void append_log(const char* msg) {
    ScopedIrqLock lk;  // 在栈上完成可预测的加锁/解锁
    ring_buffer_write(&log_buf, msg, strlen(msg));
}

ScopedIrqLock 在构造时关中断，析构时自动恢复——整个过程都在栈上完成，不涉及堆分配，时间完全可预测。这样我们既保持了高层的可维护性，又保证了关键路径的确定性。

安全关键场景

如果项目需要严格认证、内存安全极为重要（医疗设备、汽车 ECU 等），那语言选择还得把认证成本和错误代价一并算进来。在这种场景里，语言能在编译期阻止某类错误本身就是价值。Rust 的借用检查可以在很多情况下避免数据竞争和悬挂指针，这直接降低了后期验证和修复的工作量。

但引入新语言也意味着工具链、编译器支持、第三方库成熟度以及团队学习成本都要评估清楚。没有哪种语言可以自动替你完成合规性工作——语言只是把某些错误提前移到编译期，减少运行时的风险。选语言的时候想清楚这笔账就行。

长期拥有成本

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

收尾

语言选择不是在性能和可维护性之间做一刀切的牺牲，而是把项目的约束、错误代价、团队能力和长期维护成本放在一起比较的结果。用数据证明瓶颈在哪，按模块分层使用不同工具，制定并用自动化手段执行受控的语言子集——我们的终极目标就是一条：把"可预测的成本"降到最小。

记住这点就够了：用对的工具做对的事，别把工具当信念。