asyncio.start_server 更适合长连接服务，因其内置事件循环调度、连接生命周期管理与协程隔离，避免手动处理底层陷阱；典型用于im中转、设备心跳、行情推送等万级长连接场景。
asyncio.start_server 为什么比直接用 socket.socket() 更适合长连接服务
因为 asyncio.start_server 内置事件循环调度、连接生命周期管理、协程上下文隔离，避免手动处理 select/epoll、缓冲区拆包、连接泄漏等底层陷阱。直接裸写 socket.socket() + setblocking(False) 容易在高并发下卡死或丢数据——不是不能做，而是你得重造 asyncio 已经验证过的轮子。
典型场景：IM 消息中转、设备心跳保活、实时行情推送。这些都要求单连接持续数小时甚至数天，且每秒可能只有几条小包，但连接数常达万级。
-
asyncio.start_server自动为每个新连接启动独立协程，天然隔离读写状态，不用自己维护连接字典和锁 - 它默认使用
SO_REUSEADDR，避免重启时报Address already in use - 不支持半关闭（
shutdown(SHUT_WR)）语义，所有通信必须走完整协程生命周期，这对长连接反而是好事——省去判断recv()返回空字节后的清理逻辑
如何正确传参给 asyncio.start_server 避免启动失败
最常踩的坑是把协程函数名写成调用形式，或者漏掉 host/port 参数导致绑定失败。错误示例：asyncio.start_server(handle_client(), host='0.0.0.0', port=8888) —— 这里 handle_client() 立即执行并返回 None，不是协程对象。
- 第一个参数必须是协程函数名（不带括号），如
handle_client，不是handle_client() -
host建议显式指定为'0.0.0.0'或'::'（IPv6），不传可能只监听127.0.0.1，导致外部连不上 -
start_serving=False可用于延迟启动（比如先加载配置再开服），但之后必须手动调用server.serve_forever()或await server.serve_forever() -
backlog默认 100，万级连接建议设为2048或更高，否则新连接可能被内核拒绝，现象是客户端报Connection refused而不是超时
handle_client 协程里怎么安全读写长连接数据
长连接的核心矛盾是：既要低延迟响应心跳，又不能因一次 read() 阻塞整个协程。asyncio 的 StreamReader/StreamWriter 就是为此设计的，但用法不对照样出问题。
- 别用
reader.read(1024)读固定长度——如果对端只发了 2 字节就停，协程会永远挂起；改用reader.readline()（需协议换行）、reader.readexactly(n)（需提前知道长度）或reader.readuntil(b'\x00') - 写操作必须
await writer.drain()，否则 TCP 窗口满时数据滞留在内存缓冲区，看似发送成功，实则对方收不到；尤其在频繁小包场景下，漏掉drain()会导致连接假死 -
writer.close()后必须await writer.wait_closed()，否则连接可能残留 FIN_WAIT2 状态，Linux 下积压过多会耗尽文件描述符 - 不要在
handle_client里捕获ConnectionResetError或BrokenPipeError并吞掉——这是连接已断的明确信号，应立即return退出协程，让 asyncio 清理资源
为什么连接数上不去？检查这三处系统级限制
代码跑通不代表能扛住真实流量。asyncio.start_server 本身不设上限，但 Linux 内核、Python 进程、硬件都会卡脖子。
- ulimit -n 默认常为 1024，用
ulimit -n 65536临时提升，或永久写入/etc/security/limits.conf - Python 的
asyncio.selector_events._SelectorSocketTransport在高并发下可能触发OSError: [Errno 24] Too many open files，这不是 asyncio bug，是没调大 ulimit - 内核参数
net.core.somaxconn控制 listen 队列长度，默认常为 128，连接突增时新 SYN 包会被丢弃；建议设为65535，同时确认net.ipv4.tcp_max_syn_backlog也同步调高
真正难的从来不是写出让连接“通”的代码，而是让上万条连接在后台安静呼吸、不互相干扰、断了能干净回收——这些细节藏在 reader.readexactly() 的异常分支里，在 ulimit 的数字后面，在 wait_closed() 是否被 await 的那一行上。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
