Gzip压缩后体积没变小，根本原因是压缩前数据太小（通常低于1KB），导致压缩开销超过收益，甚至体积略增。
为什么Gzip压缩后体积没变小？
常见现象是启用了 gzip 但响应体大小几乎不变，甚至略增。根本原因通常是：压缩前数据太小（application/json 响应真正启用压缩。
实操建议：
- 用
curl -H "Accept-Encoding: gzip" -I https://api.example.com/data检查响应头是否含Content-Encoding: gzip - 确保 Web 框架配置了「压缩阈值」，例如 Flask +
flask-compress默认只压缩 ≥500 字节的响应，可设COMPRESS_MIN_SIZE = 100 - 避免在 Nginx 和应用层重复压缩——若 Nginx 已配
gzip on，Python 后端就不要再用gzip.compress()手动压缩响应体
Protobuf 替换 JSON 后接口报错“Unknown field”
典型错误信息：google.protobuf.message.DecodeError: Error parsing message 或客户端提示字段不存在。这通常不是协议不兼容，而是 schema 同步断裂导致的。
关键点：
立即学习“Python免费学习笔记（深入）”；
- Protobuf 要求前后端使用**完全一致的
.proto文件生成代码**；哪怕只是注释改动、字段重排，也可能因二进制序列化依赖 tag 编号而失败 - 务必禁用 JSON 的「字段名动态映射」习惯——Protobuf 中
user_name和username是两个不同字段，tag 编号必须严格对齐 - 用
protoc --python_out=. user.proto生成 Python 类后，检查生成的user_pb2.py中_descriptor.FieldDescriptor的number是否与 proto 文件中定义一致
Flask/FastAPI 怎么同时支持 JSON 和 Protobuf？
不能靠 Accept 头自动切换序列化方式，因为大多数框架默认只走 JSON 路径。需显式拦截请求、解析 Content-Type，并手动调用对应编解码逻辑。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
FastAPI 示例片段（核心逻辑）：
@app.post("/data")
def handle_data(request: Request):
content_type = request.headers.get("content-type", "")
if "application/x-protobuf" in content_type:
raw = await request.body()
msg = MyDataProto()
msg.ParseFromString(raw) # 解析 Protobuf
result = process(msg)
return Response(
result.SerializeToString(), # 序列化回二进制
media_type="application/x-protobuf"
)
else:
return {"error": "only protobuf accepted"} # 或 fallback 到 JSON
注意点：
- 别用
Body()依赖 Pydantic 自动解析 Protobuf——它只认 JSON/表单，不识别二进制 payload - FastAPI 的
Response必须显式指定media_type，否则默认为application/json，浏览器或 curl 可能误判 - Flask 中同理，用
request.get_data()取原始字节，再交由ParseFromString
Gzip + Protobuf 组合真比 JSON 快吗？
不一定。实测中，小响应体（ JSON 字符串 encode 时间。只有当 payload ≥2KB 且含大量重复结构（如列表嵌套对象）时，优势才稳定出现。
决策依据：
- 先用
timeit测你的真实数据：分别跑json.dumps(obj)、pb_obj.SerializeToString()、gzip.compress(pb_bytes)，看瓶颈在哪 - Protobuf 的真正价值不在「比 JSON 少几个字节」，而在强 schema 约束带来的前后端字段一致性保障——这点常被忽略，却大幅降低联调和线上字段缺失类 bug
- 如果前端是浏览器，注意
fetch()默认不自动解压二进制响应；需用response.arrayBuffer()接收，再传给 Protobuf JS 解析器
实际部署时，最容易被跳过的环节是 Protobuf 的版本管理和向后兼容设计——比如新增 optional 字段却不设默认值，旧客户端解析就会直接失败。这不是技术问题，是协作流程问题。
