题目与范围
Python 3.14 将 Zstandard 支持加入标准库 compression.zstd，提供一次性函数、open()、ZstdFile 以及增量压缩和解压类。题目考察 API 语义、流边界、资源上限和渐进兼容，分类为 coding。标准库可用不等于所有部署都已升级，也不等于 zstd 对每类数据都更快或更省空间。
面试官考察点
应区分一次性压缩与增量压缩，说明 FLUSH_BLOCK 与 FLUSH_FRAME 的边界，处理截断、未知输入和解压炸弹风险。还要讨论压缩级别、字典、线程模型、旧 Python 回退，以及用吞吐、压缩比、延迟和峰值内存做基准。
先澄清的问题
- 数据是完整文件、分块日志，还是必须边写边发的网络流？
- 接收端是否支持 zstd，能否统一升级到 Python 3.14？
- 目标是吞吐、压缩比、尾延迟，还是峰值内存中的哪一项？
- 单个 frame 的最大大小和失败后的重试边界是什么？
- 输入是否可能来自不可信用户，解压端如何限制资源？
- 是否需要跨语言互操作、字典协商或可审计的压缩参数？
30 秒答题框架
“先确认协议、数据块和部署版本，再选择一次性或流式 API。对大输入使用 ZstdCompressor，按块写入并在消息结束时刷新 frame；解压端限制输出大小和并发。用同一数据集比较 zstd 与现有 gzip/外部库的压缩比、吞吐、p95、CPU 和 RSS，在旧版本用可验证的回退实现，并保留格式版本与参数记录。”
分步作答
步骤 1：选择 API 与边界
完整且受控的小对象可用 compress()；文件接口可用 open() 或 ZstdFile。长连接和大日志使用增量对象，把每条消息或批次映射到明确的 frame 边界，避免把多个租户数据拼进不可拆分的 frame。
步骤 2：设计流式刷新
增量压缩时，compress() 产生中间输出；flush(FLUSH_BLOCK) 结束一个块但保持 frame，flush(FLUSH_FRAME) 结束当前 frame。只有在协议允许接收端解码时才刷新，不要为了每个小片段都结束 frame 而制造额外开销。
from compression import zstd
cctx = zstd.ZstdCompressor(level=3)
out = cctx.compress(chunk)
tail = cctx.flush(zstd.ZstdCompressor.FLUSH_FRAME)步骤 3：控制解压风险
压缩比高的输入可能在解压后占用远大于网络大小的内存。为不可信输入设置最大输出字节数、单请求并发和超时；校验 frame 完整性，区分格式错误、截断和业务取消。不要把压缩大小当作内存预算。
步骤 4：处理兼容与回退
启动时探测 compression.zstd 是否存在，并把编码协商写进协议。Python 3.13 或更早版本需要明确锁定的 backport 或外部库，不能静默改变格式。跨语言系统应以 zstd 标准 frame 互测，而不是只验证 Python 对 Python。
步骤 5：用基准决定上线
固定数据集、块大小、压缩级别和并发度，测量压缩比、端到端吞吐、CPU、p50/p95、RSS、分配次数及 frame 数量。分别测试文本、重复日志、随机数据和小 payload；小块可能被调用开销和 frame 头部淹没。灰度期间保留旧编码回退与可观测参数。
参考答案
“compression.zstd 适合 Python 3.14 服务中需要标准库 zstd、流式边界清晰且能控制资源的场景。我会用一次性 API 处理受控小对象，用增量压缩处理大流，并在协议层定义 block、frame、最大输出和取消行为。解压端限制展开大小和并发，启动时协商能力，旧版本使用明确回退。最后用固定数据集测压缩比、吞吐、尾延迟、CPU 与 RSS，再根据实测和跨语言互操作结果灰度。”
常见错误
- 把
flush()当作关闭对象 → 可能只完成 block 或 frame → 明确选择刷新模式并结束生命周期。 - 按网络字节数限制解压 → 高压缩比输入会耗尽内存 → 按展开后字节数和并发限制。
- 每条日志都新建 compressor → 初始化与 frame 开销放大 → 按批次复用增量对象。
- 默认所有运行时都有 3.14 API → 旧部署启动失败 → 启动探测并固定回退版本。
- 只测随机数据 → 看不到重复日志的真实收益 → 覆盖多种数据分布和 payload 大小。
- 只验证 Python 对 Python → 跨语言 frame 或参数不兼容 → 加入其他 zstd 实现的互测。
追问
追问 1：什么时候使用一次性 compress()？
输入完整、大小受控且无需中途发送时可以使用。大输入或需要背压时应采用增量 API，避免一次性构造完整压缩结果。
追问 2：为什么区分 block 和 frame？
block 是 frame 内的刷新边界，frame 是可独立解码的压缩单元。协议若要求消息独立解压，应在消息结束时刷新 frame，而不是只刷新 block。
追问 3：如何让旧版本继续工作？
在启动检查模块能力，协商编码；锁定并测试 backport 或外部库，确保生成相同 zstd frame 语义，并在日志中记录实际编码路径。
追问 4：基准中最容易遗漏什么？
常被遗漏的是解压端 RSS、p95、frame 数量、压缩级别变化和小 payload 的固定开销。应把这些指标与吞吐、压缩比一起比较。