zstandard、LZ4、brotli 各有适用场景：zstd 通过 level/dict/write_size 调优吞吐与压缩率；LZ4 适合低延迟流式场景，需规避隐式 footer；brotli 仅在 CDN 预压缩大文本时优势显著；解压前务必校验输入完整性以防失败。
压缩速度和内存占用差距大到影响服务响应？先看 zstandard 的 zstd.ZstdCompressor 级别控制
zstandard 不是“开箱即用就最快”，默认参数（level=3）在吞吐和延迟之间做了妥协。高并发日志上传或实时流式压缩时，level=1 能压到 500+ MB/s，但压缩率比 level=9 低 20%～30%；而 level=9 可能吃掉单核 80% 以上 CPU，还触发 GC 压力。
关键不是调等级，而是用 dict 和 write_size：预训练字典（ZstdCompressionDict）对结构化日志、JSON 片段提升显著；write_size 设为 64KB～256KB 可减少小 buffer 频繁 flush 开销。
- 别在
ZstdCompressor初始化里传大dict对象，应提前dict = zstd.ZstdCompressionDict(data)缓存复用 -
compress()直接传 bytes 比传 file-like 对象快 15%～20%，后者会多一层read()循环 - 用
zstd.ZstdCompressor(threads=-1)启用多线程时，注意 Python GIL 不阻塞 C 扩展，但线程数 > CPU 核心数反而降低吞吐
lz4 在 RPC 或内存敏感场景下真香？警惕 LZ4FrameCompressor 的隐式 flush 行为
lz4 的优势不在压缩率，而在确定性低延迟：1MB 数据压缩稳定在 0.8ms 内（Intel i7），且内存峰值固定（约 16MB）。但它默认的 LZ4FrameCompressor 会在 compress() 结束时自动写入 frame footer —— 这导致你无法流式拼接多个块，除非手动 update() + flush()。
典型踩坑：用 lz4.frame.compress(data) 处理分片上传，结果每个分片都带独立 header/footer，下游解压失败。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 流式场景必须用
LZ4FrameCompressor实例，而非函数式接口 -
compressor.update(chunk)后不要立刻compressor.flush()，等整条消息结束再 flush，否则产生冗余 footer -
lz4.block.compress()更轻量（无 frame 开销），但不支持 streaming，适合 KV 缓存 value 压缩
brotli 的高压缩率在哪儿真正起作用？别在短文本或小文件上浪费 CPU
brotli 的 BrotliCompressor 在 100KB+ HTML/JS/CSS 上比 zstd level=9 多压 8%～12%，但代价是压缩耗时翻倍（尤其 mode=MODE_TEXT）。对小于 4KB 的数据，它甚至可能输出比原文还大的结果 —— 因为字典和 Huffman 表开销固定。
它唯一不可替代的场景：CDN 静态资源预压缩。这时 CPU 不是瓶颈，带宽和存储是。
- 禁用
mode=MODE_TEXT处理二进制数据（如 protobuf），否则压缩率反降、速度更慢 -
quality设为 4～6 是性价比拐点，quality=11比quality=6多压 2% 但慢 3 倍 - Python 的
brotli包不支持多线程压缩，别指望靠threads参数提速
选错算法会导致解压失败？重点检查 decompress() 的输入完整性
zstandard 和 brotli 解压器对输入极其敏感：少一个字节、多一个零，直接抛 zstd.ZstdError 或 brotli.error；而 lz4 有时会静默返回截断结果。这不是 bug，是设计使然 —— 它们依赖完整帧结构校验。
线上最常出问题的是网络传输截断、base64 decode 错位、gzip/lz4 混淆（比如误把 lz4 数据当 gzip 解）。
- 用
zstd.decompress(data, max_output_size=...)显式限长，防 OOM - lz4 解压前先用
lz4.frame.get_frame_info(data)检查 magic 和 size，避免盲目调decompress() - brotli 不提供帧信息 API，必须确保 base64 decode 后长度与原始压缩长度一致，否则大概率是 padding 错误
压缩算法不是黑盒开关，每个库的 error 边界、内存模型、流式语义都不同。拿 lz4 当 zstd 用，或拿 brotli 压日志流，问题往往不出在“压不压得小”，而出在“压完能不能稳稳解开”。
