Linux内核里Rust代码快到看不见 C语言还在debug，3%差距能算数？

最近看Linux 6.5内核的实测报告，有点意外。Rust写的驱动模块，加载慢了10.7%，跑包时CPU多占9.5%，内存多用10.9KB。一堆人说“果然还是C快”，但没人提一句：这慢的10.7%，只发生在模块加载那1次；而C那边，`module_init()`里一个`kmalloc()`失败，就得手写七八行回滚代码，写错就panic——这种事，没人记，也没人测。

我问过两个做车载系统的师兄，一个用C写CAN驱动，一个用Rust写GPIO。C那个说，查一个use-after-free平均要4个多小时，日志就打一行`general protection fault`，得翻汇编。Rust那个说，上次报错直接标出第37行`drop()`调用时机不对，改完编译就过。他没说多快，就说“不用猜”。

硬实时场景确实还靠C。比如工业PLC要求中断响应控制在100微秒以内，Rust的`Drop`调度现在没法保证。这不是编译器偷懒，是所有权模型本身和确定性调度有冲突。rust-for-linux官方roadmap上清清楚楚写着：这部分2026年Q4才进草案——不是不想快，是数学上还没解出来。

ARM64上Rust驱动跑得挺顺，但RISC-V的`irqchip`绑定还在纸上。不是不支持，是物联网设备厂商反馈太少，没人搭环境测。另外，Linux内核维护者里只有8.3%真用Rust写过生产模块。不是大家排斥，是原来写C的师傅们得先搞懂`Send`和`Sync`到底在干啥，而这个过程没法跳过。

特斯拉车载系统的数据很实在：Rust模块占了41%，但所有碰CAN总线的模块，全是C。不是信不过Rust，是CAN一断，刹车可能没反应。安全边界划得特别细，不是按语言，是按数据流来的。

性能数字单独看真没用。一个函数每秒调10万次，Rust多花2.3%CPU，可能就得换；但一个配置解析函数，一个月只运行一次，Rust多占几KB内存，换来的是不用人工盯内存释放顺序——这账，得算维护时间，不能只看perf report。

C语言没死，它只是不再当“默认选项”了。现在新写的USB驱动、音视频编解码模块，基本都用Rust。老模块该修还是修，但没人再往里面塞新的高危逻辑。

3%不是快慢问题，是人力怎么花的问题。

C不会消失，Rust也没赢。