zlib压缩大型文本需用compressobj分块处理并转义换行符：创建压缩器对象分块压缩，flush确保完整性；压缩后将 和\双阶段转义，解压时逆序还原；单行对应一个完整压缩块，短文本需长度校验避免膨胀。
zlib 压缩大型文本数据时，不能直接用 zlib.compress() 读全量再压——内存会爆，且无法流式写入文本文件（比如每行一条压缩记录）。必须改用对象模式 + 分块处理 + 转义规避换行符。
用 zlib.compressobj() 替代 zlib.compress()
直接调 zlib.compress() 会把整个文本一次性加载进内存，对几百 MB 的 JSON 日志或批量导出数据极易 OOM。正确做法是创建压缩器对象，分块喂数据：
-
compressor = zlib.compressobj(level=6)—— level 推荐 6，平衡速度与压缩率；设 1 适合高频写入场景，9 仅在离线归档时考虑 - 每次只读
1024或8192字节，调compressor.compress(chunk)累积输出 - 最后必须调
compressor.flush()，否则末尾几字节会丢
压缩后字节流含
，导致按行读取失败
原始 zlib 输出是二进制，其中可能含
字节（ASCII 10），若直接写入文本文件并用 for line in f 读取，会在错误位置截断，解压必然报 zlib.error: Error -3 while decompressing data: incorrect header check。
- Base64 编码能解决，但体积膨胀约 33%，对短文本（如单条 JSON）几乎没收益
- 更轻量的做法：对压缩后的
bytes做双阶段转义——把所有b'\n'，把所有\（反斜杠字面量）先转成b'\\'，避免冲突 - 解压时按顺序还原：
data.replace(b'\\', b'\').replace(b'\n', b' ')
zlib.decompressobj() 必须配合增量解压逻辑
对应压缩端的流式写入，解压端也不能靠 zlib.decompress() 一把梭——它要求输入是完整、未转义的压缩块。你得自己拆出行、还原转义、再喂给解压器：
- 逐行读文件：
line = f.readline().rstrip(' ')，然后line_bytes = line.encode('latin-1')（避免 UTF-8 解码失败） - 执行转义还原：
raw_compressed = line_bytes.replace(b'\\', b'\').replace(b'\n', b' ') - 初始化
decompressor = zlib.decompressobj()，循环调decompressor.decompress(raw_compressed)，最后decompressor.flush() - 注意：单行必须对应一个完整压缩块，不能跨行——写入时就要保证每行只存一个
compressor.flush()输出
小数据反而越压越大，必须加长度判断
zlib 对极短文本（如小于 100 字节的 JSON）压缩后可能更大，尤其 level > 1 时。线上服务若不拦截，会导致存储浪费甚至协议解析失败。
立即学习“Python免费学习笔记（深入）”；
- 压缩前检查原始长度：
if len(data) ，直接跳过压缩，加个标记前缀（如 <code>b'U'表示未压缩，b'Z'表示已压缩） - 解压时先读首字节判断类型，再决定是否调
zlib.decompress() - 这个阈值不是固定值，建议在目标数据集上实测：用典型样本跑
len(zlib.compress(sample)) / len(sample)，取压缩率 > 1.05 的临界长度
decompressobj() 不是无状态函数，同一实例不能复用于多个压缩块；而转义若没处理 \ 冲突，还原时会把 \n 错当成字面量
。这两处一错，整条流水线就静默损坏。 
