从 Firefox 151.0.0 起，浏览器里所有 gzip 压缩与解压缩操作已经不再走那个 1995 年就嵌入几乎所有主流软件的 C 语言 zlib——取而代之的是用 Rust 从头重写的 zlib-rs。绝大多数用户不会感知到任何变化，但这恰恰是这件事最值得关注的理由：一次底层基础设施的无感替换，比任何高调发布更能说明 Rust 在生产环境中的成熟度。
zlib-rs 是什么，为什么替换它意义重大
zlib 是互联网压缩的基石。HTTP gzip 传输、PNG 图像编码、ZIP 打包、Git 对象存储……几乎所有涉及 deflate/inflate 的场景都依赖它。Mark Adler 和 Jean-loup Gailly 从 1995 年维护至今，代码量不大却承载了惊人的责任。问题在于：C 语言、手动内存管理、三十年累积的隐含假设——这类基础设施正是内存安全漏洞的高发地带。
zlib-rs 由 Trifecta Tech Foundation 推动，目标不是"另起炉灶做新算法"，而是用 Rust 逐函数对齐 zlib 的行为和性能，做到 API 兼容、输出一致，同时消除整类内存安全问题。这意味着下游集成方不需要改任何调用逻辑，只需要换掉底层实现。
Firefox 怎么完成这次切换
Firefox 的网络栈长期依赖系统 zlib 或内嵌 zlib 做 gzip 内容解码。切换到 zlib-rs 的路径并不复杂，但工程上需要验证几个关键点：
- 压缩输出比特一致性：同一输入，zlib-rs 产生的 deflate 流必须与 zlib 逐比特相同，否则 CDN 缓存、ETag 校验等全链路机制会出问题。
- 性能不能退步：gzip 解压是浏览器渲染路径上的高频操作，任何延迟都会直接体现在页面加载时间上。
- Fallback 机制：在少数平台或构建配置下仍需保留 zlib 作为备选。
Mozilla 选择"静默上线"而非大版本公告，恰恰说明验证已经足够充分——如果替换出了问题，用户反馈会立刻涌入，而事实是没有人注意到变化。
在自己的项目里用 zlib-rs
zlib-rs 已经发布在 crates.io，任何 Rust 项目都可以直接替换 flate2 等库的后端。下面是一个最小可运行示例，演示 gzip 压缩与解压缩：
# Cargo.toml
[package]
name = "zlib-rs-demo"
version = "0.1.0"
edition = "2021"
[dependencies]
flate2 = "1.1"
# 关键：指定 zlib-rs 作为 flate2 的后端，而非默认的 miniz_oxide
flate2-zlib-rs-backend = "0.1"
// src/main.rs
use flate2::read::GzEncoder;
use flate2::read::GzDecoder;
use flate2::Compression;
use std::io::Read;
use std::io::Write;
fn main() {
let raw = b"Hello from zlib-rs — your data is now compressed by Rust.";
// 压缩
let mut encoder = GzEncoder::new(raw.as_slice(), Compression::default());
let mut compressed = Vec::new();
encoder.read_to_end(&mut compressed).unwrap();
println!("原始长度: {} 字节", raw.len());
println!("压缩后长度: {} 字节", compressed.len());
// 解压缩
let mut decoder = GzDecoder::new(compressed.as_slice());
let mut decompressed = Vec::new();
decoder.read_to_end(&mut decompressed).unwrap();
println!("解压后内容: {}", String::from_utf8_lossy(&decompressed));
assert_eq!(raw.as_slice(), decompressed.as_slice());
println!("✓ 比特一致性验证通过");
}
运行方式：
cargo run
注意：
flate2-zlib-rs-backend的版本号和可用性可能随时间变化，请以 crates.io 最新发布为准。如果你的项目之前依赖flate2的默认后端（miniz_oxide），切换到 zlib-rs 后行为应完全一致，但建议跑一遍你自己的压缩输出回归测试。
更广泛的启示与采纳建议
这次替换的意义超出 Firefox 本身：
-
基础设施替换可以是无感的。zlib-rs 的策略——逐比特兼容、API 对齐——是让下游采纳者零成本迁移的关键。如果你也在考虑用 Rust 重写某个 C 基础库，优先保证输出兼容，而非追求"更好的 API"。
-
Rust 已经进入"静默替换"阶段。早期 Rust 的叙事是"新项目用 Rust"；现在变成了"老项目里的老 C 代码被 Rust 静默替换"。这比任何宣言都更有说服力。
-
性能不是牺牲品。zlib-rs 在多数基准测试中与 zlib 性能持平甚至略优，这说明内存安全并不必然带来运行时代价。
采纳 checklist：
- [ ] 确认你的项目依赖链中哪些库最终调用 zlib（
ldd/cargo tree都可以查） - [ ] 在测试环境替换为 zlib-rs，跑全量压缩/解压回归
- [ ] 对比性能基准，关注解压延迟（这对用户体验最敏感）
- [ ] 保留 fallback 路径，直到 zlib-rs 在你的目标平台上经过足够生产验证
- [ ] 关注 zlib-rs 的 crate 更新日志，它仍在快速迭代中
三十年历史的 C 库不会一夜消失，但 Firefox 151 证明了一件事：替换它们，可以安静地发生，而且不需要任何人为此付出代价。