pzip不兼容标准gzip因采用分块并行压缩：每块独立gzip压缩，仅保留首块header和末块trailer，中间块用NoHeader模式，需专用解压器。
为什么 pzip 不是简单起见用 gzip + runtime.GOMAXPROCS
因为标准 gzip.Writer 内部状态（比如哈夫曼树、滑动窗口）不是并发安全的，强行多 goroutine 写同一个 gzip.Writer 会 panic 或产生损坏数据。而 pzip 的核心思路是「分块并行压缩 + 后续拼接」，不是让多个 goroutine 并发写同一压缩流。
它把输入数据切分成固定大小块（默认 1MB），每个块独立调用 gzip.NewWriter 压缩，再把各块压缩结果按顺序拼起来——但这样直接拼出来的字节流不符合 gzip 格式规范（缺少全局 header/trailer，且各块 trailer 会干扰下一个块）。
- 真正实现时，
pzip会丢弃中间块的 gzip trailer（即最后 8 字节），只保留第一个块的 header 和最后一个块的 trailer - 每个中间块实际用的是
gzip.NoHeader模式，避免重复 header；解压端需配合识别这种“multi-block without inter-block headers”格式 - 这意味着：它不是标准 gzip 兼容的，不能直接用
gunzip解，必须用配套的pzip解压器或手动处理块边界
pzip 的压缩块大小怎么选？默认 1MB 合理吗
块太小（如 64KB）：线程调度和内存分配开销占比上升，压缩率下降（小块难以建立有效字典）；块太大（如 16MB）：单块压缩耗时拉长，无法充分利用 CPU 核心，且内存峰值飙升（每块需独立缓冲区）。
实测在多数 SSD+16 核场景下，512KB–2MB 是较优区间。关键看你的数据局部重复性：
立即学习“go语言免费学习笔记（深入）”；
- 日志类（高重复前缀）：可尝试 256KB，更快收敛字典
- JSON/文本混合（中等重复）：1MB 是平衡点
- 已加密或随机二进制数据：别用
pzip，压缩率接近 0，还白占 CPU
设置方式是传入 pzip.Options{BlockSize: 1024 * 1024}，不是改环境变量或全局配置。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
为什么用 pzip 压缩后文件反而变大了
这不是 bug，是分块压缩固有代价：每个块都要携带自己的 gzip header（10 字节）和（除最后一块外）被丢弃的 trailer；更严重的是，小块无法复用跨块的字典信息，LZ77 匹配距离受限。
典型表现：
- 原始文件
- 含大量短重复串（如
{"id":1,"name":"a"}连续出现）：单块内匹配不到跨块重复，压缩率比单线程gzip低 10%+ - 用了
gzip.BestSpeed级别：块内压缩本就粗糙，叠加分块损失，效果更差
建议先用 head -c 10M bigfile | gzip | wc -c 和 pzip -b 1M | wc -c 对比 10MB 样本，别直接压全量。
如何判断当前数据是否适合 pzip
适合的核心信号只有一个：文件足够大（≥50MB）且内容有中长距离重复模式（比如数据库 dump、归档日志、CSV 表格）。其他都是次要条件。
快速验证步骤：
- 用
gztool -v file.gz查看单线程 gzip 的压缩比和平均匹配长度（avg match len> 20 更可能受益） - 跑一次
pzip -b 1M -o test.pz file，再用gunzip -t test.pz—— 会失败，说明你忘了它不兼容标准工具；正确验算应是pzip -d test.pz | sha256sum对比原文件 - 监控
top -p $(pgrep -f "pzip")，如果 CPU 利用率长期卡在 100% ×（逻辑核数 − 1），说明 I/O 或锁瓶颈，不是计算瓶颈，这时加核无用
真正难处理的是半结构化数据：比如 protobuf 序列化后的二进制流，重复模式隐含在字段偏移中，pzip 这种基于字节流的分块完全抓不住——这种场景得换 zstd 多线程模式或自定义分帧逻辑。
