gRPC 比 REST/JSON 更适合 Python 微服务内网通信，因其 Protobuf 序列化更快更省带宽、HTTP/2 多路复用降低延迟、.proto 强契约保障类型安全与跨服务一致性。
因为 Python 微服务内部通信对性能、类型安全和跨服务一致性要求高，而 gRPC 在这三点上比 REST/JSON 更可靠——不是“更先进”，而是更贴合内网高频调用场景的实际约束。
gRPC 的二进制序列化（Protobuf）比 JSON 快且省带宽
Python 中 json.loads() 和 json.dumps() 是纯解释器级文本解析，CPU 开销大；尤其当消息嵌套深、字段多（比如订单含地址、商品列表、优惠券数组）时，反序列化耗时可能占整个 RPC 调用的 30% 以上。Protobuf 生成的 log_pb2.Record 类直接映射内存结构，ParseFromString() 是 C 扩展实现，实测快 3–5 倍，体积小 60–80%。
容易踩的坑：
- 误以为只要换 gRPC 就自动提速——实际必须用
protoc正确生成代码，且不能在 .proto 里滥用optional或嵌套过深的oneof，否则生成的 Python 类反而变慢 - 开发期用
print(request)查看 Protobuf 消息，输出是可读性差的调试字符串，应改用str(request)或request.__dict__（需注意内部字段名带下划线）
HTTP/2 多路复用显著降低微服务链路延迟
Python 微服务常出现“A → B → C”的串行调用。REST 基于 HTTP/1.1，默认每个域名只开 6 个 TCP 连接，B 调 C 时若连接池已满，就会排队等待；而 gRPC 默认复用单个 grpc.Channel，所有 RPC 共享一个 HTTP/2 连接，请求不阻塞、无队头阻塞（head-of-line blocking）。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
实操建议：
- 客户端不要为每次调用都新建
grpc.insecure_channel()或grpc.secure_channel()，应复用 channel 实例（它本身是线程安全的） - 避免在 asyncio 环境中混用同步 channel；如用
grpcaio，必须确保 server 启动时传入max_concurrent_rpcs=100等合理值，否则默认限流会卡住并发 - 内网部署时，禁用 TLS 握手（用
grpc.insecure_channel）能再降 5–10ms 延迟，但仅限可信网络
.proto 文件强制统一契约，避免 Python 动态特性引发的协作故障
Python 项目里常见问题：服务 A 返回 {"user_id": 123}，服务 B 的 client 代码写成 resp["userId"]，运行时报 KeyError；或某字段从 string 改成 int，没通知下游，结果 int("123.0") 直接炸掉。Protobuf 用 user_id = 1 定义字段编号，生成的 Python 类有明确属性访问方式：request.user_id，拼错名或类型不符在 import 阶段就报错。
关键细节：
-
proto3默认所有字段 optional，但 Python 生成代码中仍会做存在性检查（如if request.HasField("user_id")），别依赖is not None - 枚举值必须显式赋值（
STATUS_OK = 0;），否则 Python 生成的 enum 类在比较时可能因底层 int 值不一致出错 - 服务端升级 .proto 增加字段后，老客户端仍可正常收包（新字段被忽略），但老服务端无法解析新字段——这是单向兼容，要双向兼容得靠
reserved预留字段号
真正难的不是写通第一个 stub.GetUser()，而是让团队所有人习惯在改接口前先改 .proto、跑一遍 protoc、提交生成代码，并接受“编译期报错比运行时报错更早暴露问题”这个事实。
