压缩流API演示

CompressionStream API 是现代浏览器提供的原生 Web API，允许在客户端（浏览器中）对数据进行流式压缩和解压缩。它支持 Gzip、Deflate 和 Brotli（部分浏览器）等格式。由于采用流式处理，即使处理大型数据也不会阻塞主线程，非常适合在 PWA、离线应用或需要前端数据压缩的场景中使用。该 API 属于 W3C 标准规范，在 Chrome 80+、Edge 80+、Firefox 113+、Safari 16.4+ 中得到支持。

Gzip 是最广泛使用的压缩格式，基于 DEFLATE 算法，兼容性极好，几乎所有浏览器和服务器都支持。压缩速度较快，适合实时压缩场景。
Brotli 是 Google 开发的现代压缩算法，相比 Gzip 通常能获得 15-25% 更高的压缩率，尤其对文本类数据（HTML、CSS、JS、JSON）效果显著。但压缩速度较慢，更适合静态资源预压缩。
选择建议：对兼容性要求高的场景选 Gzip；追求极致压缩率和传输效率的场景选 Brotli。在实际 Web 服务器中，两者常结合使用。

这是正常现象。Gzip 和 Brotli 等压缩格式都有固定的头部和尾部开销（Gzip 约 20-30 字节，Brotli 也有类似开销）。当原始文本非常短（比如只有几个字节）时，压缩算法无法通过消除冗余来抵消这些开销，导致压缩后的数据反而比原始数据更大。通常建议对 大于 1KB 的文本数据使用压缩才有明显收益。你可以试试在输入框中输入 "hello" 来观察这个现象。

服务器端压缩（如 Nginx gzip 模块）在数据发送前进行压缩，浏览器接收后自动解压，对用户透明。优点是减少网络传输量。
浏览器端压缩（CompressionStream API）在客户端进行压缩，适用于：上传大文件前压缩以减少上传时间、PWA 离线数据存储、生成压缩包供下载、本地数据加密前的预处理等场景。两者可以互补使用。

目前的 CompressionStream API 规范不支持自定义压缩级别。浏览器会使用各自的默认级别（通常是平衡压缩率和速度的中等级别，Gzip 约 level 6，Brotli 约 quality 4-6）。如果你需要精确控制压缩级别，可以考虑使用 WebAssembly 编译的 zlib/brotli 库（如 fflate、brotli-wasm），它们提供更灵活的配置选项。

截至 2024 年：
✅ Gzip/Deflate：Chrome 80+、Edge 80+、Safari 16.4+、Firefox 113+、Opera 67+
✅ Brotli ('br')：Chrome 116+、Edge 116+、Firefox 119+（Safari 目前不支持 Brotli 压缩流）
覆盖了约 93%+ 的全球用户。对于不支持的浏览器，建议使用 polyfill 或回退方案。

压缩后的数据是二进制格式（Uint8Array），可以通过以下方式处理：
1. Base64 编码：转为文本字符串，适合在 JSON、XML 或 URL 中传输
2. 直接上传：作为 application/octet-stream 或带 Content-Encoding 头的请求发送
3. Blob/File：转为 Blob 对象，用于下载或存储到 IndexedDB
4. Hex 编码：用于调试和日志记录