Fil-C项目硬刚内存安全老问题，用编译器魔法给C语言套上安全枷锁，性能损耗控制在20%左右。推特上关于Rust unsafe、C指针乱飞、GLSL限制的争论炸了锅，Fil-C作者亲自下场撕逼，核心就一句：别跟我扯理论，看谁家代码真敢零开销跑起来。
安全Rust的零unsafe神话说服不了任何实战派
Rust粉丝最爱吹的梗就是“我写的程序零行unsafe代码”。这话在推特上被Fil-C作者一棍子打醒：每个能正经发货的Rust程序，要么自己偷偷用unsafe，要么依赖的库把unsafe当饭吃。你拿cargo-geiger扫一遍依赖树，红色警告能亮瞎眼。
这不是抬杠，这是包管理器的基本操作。你写个网页服务器，底层HTTP解析库用了unsafe优化字符串转换，你根本不知道。你写个游戏引擎，物理碰撞检测库为了速度直接操作裸指针，你照样看不见。零unsafe的Rust程序就像宣称零卡路里的奶茶，骗鬼呢。
更狠的是，Fil-C作者补了一刀：你们Rust社区天天教人写零unsafe代码，倒是让GNU Coreutils用零unsafe跑一遍啊？人家Coreutils在Fil-C上五分钟就跑了，Rust移植版折腾了多久心里没点数？
C语言的指针算术是个永远关不上的后门
推特上有人抬杠说C语言也有安全子集，比如GLSL着色器语言就严禁指针乱飞。Fil-C作者直接笑出声：大哥，GLSL那是连地址运算符都不给你的残疾版C，写个链表都得靠数组下标模拟，这叫编程语言还是叫紧箍咒？
日常C程序员写代码，指针加加减减跟呼吸一样自然。你写个字符串拷贝，指针往前挪一位；你写个数组遍历，指针往后跳两步；你写个结构体解析，指针强转各种类型。这些操作在C标准里全是安全出口，编译器一个都不拦。
Fil-C作者的原话翻译成人话就是：C语言的安全问题不是bug，是feature。每个指针操作都是语言给你的逃生通道，通道密度高到你想避都避不开。Rust好歹把逃生通道浓缩成一个unsafe关键字，你至少知道危险区在哪。C语言倒好，整个代码全是雷区，踩不踩中全看命。
安全C子集的理论存在不等于实践可行
那个叫Workhouse Overseer的网友抛了个理论炸弹：Rust可以写零unsafe的非平凡程序，但C语言写零指针的非平凡程序纯属做梦。这话逻辑没错，但Fil-C作者回怼的角度更刁钻：你说的是理论可能性，我说的是现实发生率。
现实是什么？现实是WebKit浏览器引擎的C++代码早就这么干了。加号操作符和中括号操作符全用边界检查的重载版本，整数运算单独拎出来保证安全。这套玩法在C++社区叫安全子集实践，不是什么新鲜事。
但问题来了，WebKit团队有几百个编译器专家天天盯着代码，你普通C项目养得起这种豪华安保团队吗？安全C子集的理论可行跟普通码农实际能写出来，中间隔着十个Google的代码审查流程。
Rust的unsafe背锅侠当得有点冤
推特上有个叫Ekinohito的网友疯狂输出：Rust有cargo-geiger插件可以统计所有unsafe代码，每个不安全操作都透明可追踪。Fil-C作者就回了一句没人真这么干，直接把对方噎死。
为什么没人这么干？因为统计完你会崩溃的。你项目依赖的tokio异步运行时底层用了unsafe优化事件循环，你依赖的serde序列化库用了unsafe加速JSON解析，你依赖的regex正则引擎用了unsafe实现DFA状态机。统计完了你能怎么办？全部重写？
更扎心的是，Rust的unsafe机制本身就是个免责声明：我知道这里危险，但我相信我能搞定。问题是真搞不定的时候呢？内存安全照样崩，崩溃时还多背一条unsafe使用不当的锅。Fil-C的哲学更光棍：我不搞什么安全子集，我把整个C语言全部重新编译成安全版本，要死一起死，要安全全部安全。
性能开销20%换全局安全到底值不值
Fil-C最炸裂的数据是性能损耗大约20%。这个数字在推特上炸了两波人。一波人觉得20%太贵了，C语言图的就是性能裸奔，你加层安全枷锁不如直接上Rust。另一波人觉得20%便宜爆了，想想内存安全漏洞造成的经济损失，这点性能换安全简直白送。
Fil-C作者的真实意图其实更激进：他在用编译器技术解决生态系统问题。现有的C代码库有几亿行，你让这些代码全用Rust重写纯属做梦。Fil-C的做法是让这些旧代码原地升级安全属性，编译时直接插入安全检查。
换个说法就是Rust在教你怎么盖新房，Fil-C在教你怎么给老破小装防弹玻璃。两种路线都有价值，但Fil-C的路线显然更适合存量市场。推特上那个叫Mitchell Hashimoto的大佬刚发了SIMD实战教程，说白了就是性能优化永远有市场，但前提是代码先跑对再跑快。
谁的逃生通道更安全已经不重要了
整个推特论战最精彩的转折点是Linus Torvalds那句我不知道你们在吵什么。这位Linux之父的态度就是懒得站队，反正内核里C代码继续写，Rust模块慢慢加，Zig和Bun爱咋咋地。
Fil-C作者最后补的那条推特是点睛之笔：如果觉得我的论点烂，倒是拿反论证来怼啊。这话翻译成初中生能懂的话就是光喷不练假把式，有本事你写个比Fil-C更安全更快的内存安全方案出来。
所以这场架吵到最后就一个问题：你愿意为安全付出多少性能代价？Rust的选择是零成本抽象但unsafe全靠自觉，Fil-C的选择是20%成本全覆盖无死角。选哪个都行，但别骗自己说哪个是零代价的完美方案。
站在2026年回头看，内存安全早就不是技术问题而是经济问题了。
C语言的指针算术是历史包袱，Rust的unsafe是免责声明，Fil-C的20%开销是保险费用。保险公司从来不承诺不出事，只承诺出事时赔得起。Fil-C赔得起，Rust得看谁写的unsafe，C语言压根没买保险。
这就是编程语言的现实江湖。谁都想要内存安全，谁都不想掏性能成本，最后全在妥协中找平衡点。Fil-C至少把成本摆桌面上明码标价，比那些号称零开销的内存安全方案真诚一百倍。
做内存安全就像买意外险，你永远不知道哪行指针操作会崩掉整个服务器。Fil-C说你每年交20%保费我全包，Rust说你小心开车自己规避风险，C说你信我反正开了三十年没出大事。选哪个？反正我选明码标价的，至少赔钱时不扯皮。