一条让我印象很深的评论 上个月发了一篇纯Python SIP协议栈的文章，评论区有一条：

“Python做信令，生产环境能用？别闹了，就是个玩具。”

这条评论我没删，因为这个问题值得认真回答。

先说结论 500路设备同时在线，稳定。并发点播200路，首帧平均480ms。持续运行4小时，无掉线，内存稳定。

测试环境：8核16G云服务器，Docker部署，没做特殊调优。

这个数据不算惊艳，但也不丢人。

为什么Python没成瓶颈？ 关键不在语言，在架构。

第一，信令和视频流是两条路。

信令走UDP/TCP，数据量很小。一条REGISTER消息才几百字节，一条INVITE消息一两千字节。真正吃带宽的是RTP视频流，走的是ZLMediaKit，和Python没关系。

所以“Python慢”影响的是信令处理，不是视频转发。

第二，信令处理做了四层优化。

对象池预分配2000+对象，热路径零GC压力

SIP消息用线程池多核并行解析

预过滤Handler在分发前砍掉70%的无效消息

分片DialogManager把会话管理拆开，锁竞争降低16倍

第三，Python的asyncio天生适合信令场景。

信令处理是IO密集，不是CPU密集。等设备响应、等网络IO，这些操作asyncio处理起来很高效。

什么时候Python确实不行？ 上万路设备，每秒几千条信令。 这种规模，Python确实吃力，该用C还是得用C。

但问题是，绝大多数项目根本到不了那个量级。

一个园区、一个工厂、一个县级平台，几百路设备顶天了。这种规模下，Python的性能完全够用。

那为什么还有人觉得Python是玩具？ 因为很多人对Python的性能印象还停留在十年前。

那时候Python的asyncio还不成熟，GIL限制严重，做高并发确实不行。但现在不一样了。asyncio成熟了，uvloop提升了事件循环性能，对象池和分片锁解决了GC和锁竞争问题。

还有一个原因：他们没见过真的用Python做生产环境的项目。

PyGBSentry不是第一个用Python做网络服务的项目。Instagram用Django撑起了上亿用户，Dropbox用Python做了核心同步逻辑。Python做生产环境，早就被验证过了。

一个让我很感慨的反馈 有个集成商用我的项目做了一个园区平台，300多路设备。他之前用的是商业中间件，18万一套。换我的项目之后，他给我发了条消息：“跑了一周，稳。我都不敢相信这是Python写的。”

偏见这东西，说再多不如跑一遍。

项目现状 PyGBSentry已经开源，AGPL v3.0协议，支持GB/T 28181-2022，向下兼容2016版。设备注册、实时预览、录像回放、云台PTZ、语音对讲、平台级联，功能完整。

部署三条命令：

git clone https://gitee.com/suoten/PyGBSentry.git

cd PyGBSentry/editions/open-source

python tools/generate_env.py --docker && docker compose up -d

Gitee： suoten/PyGBSentry

GitHub： suoten/PyGBSentry

你觉得Python做生产环境，最大的障碍是什么？评论区聊聊。