grpcio的asyncio API是否具备生产就绪性？

我完全理解你遇到这些问题时的挫败感——grpcio的asyncio API确实在早期迭代阶段存在不少稳定性和配置生效的坑，不少开发者在生产环境试水时都踩过类似的雷。

先说说你碰到的两个具体问题：

• 客户端异常退出时协程冻结：这个情况挺普遍的，尤其是在流式RPC场景下，当客户端直接被杀死（不是优雅关闭流连接），服务端的协程经常因为没正确捕获到连接断开的信号而挂起。虽然后续版本的grpcio针对这个问题做了修复，但某些边缘场景下还是可能出现遗漏。
• maximum_concurrent_rpcs配置失效：这个问题我自己测试时也碰到过——明明把参数设为1，却还是能同时发起多个RPC请求。后来发现这个参数在asyncio模式下的生效逻辑和同步模式差异很大，早期版本对流式RPC的并发控制确实存在漏洞，很多时候需要结合服务端的任务调度逻辑额外做一层手动限流才能达到预期效果。

回到你最关心的问题：有没有人在生产环境用它？答案是有的，但大多是在特定场景下——比如业务流量不算特别大、或者对并发控制要求没那么严苛的场景，而且很多团队会在官方API之上做一层封装，比如自己实现协程的生命周期管理、手动加并发限制，以此规避官方API的固有问题。

如果你的业务是高并发的流式场景，那目前上生产可能需要谨慎：要么等grpcio推出更稳定的版本，要么在现有基础上自行补充防护逻辑，同时一定要在预发环境做充分的压测，覆盖客户端异常退出、高并发流式请求等核心场景，提前暴露问题。

备注：内容来源于stack exchange，提问作者Parlor311