asyncio.open_connection 连不上服务器？先检查事件循环是否运行及host是否为合法IP字符串；reader.read()需指定长度或加超时；writer.close()后必须await writer.wait_closed()；并发时注意缓冲区大小和日志开销。
asyncio.open_connection 连不上服务器？先检查事件循环和地址格式
绝大多数连接失败不是代码逻辑问题，而是 asyncio.open_connection 被误用在非异步上下文里，或传入了非法地址。它必须在运行中的事件循环内调用，且 host 不能是空字符串、None 或未解析的域名（除非 DNS 可用）。
- 常见错误现象：
RuntimeError: no running event loop—— 没有显式启动asyncio.run()或没用loop.run_until_complete() - 使用场景：只适用于一次性短连接，不推荐在长连接中反复调用；若需复用连接，请直接操作
StreamReader/StreamWriter -
host推荐用 IP 字符串（如"127.0.0.1"），避免 DNS 延迟或失败；端口必须是int，不能是字符串"8080" - 如果服务端监听
0.0.0.0，客户端仍需指定具体 IP（如"127.0.0.1"），不能连"0.0.0.0"
收发字节流时卡住或丢数据？别直接 await reader.read() 不设限
reader.read() 默认不设 n 参数会一直等到 EOF（即连接关闭），而 TCP 连接通常长期存活，这会导致协程永久挂起。真实业务中几乎总要控制读取长度或使用带超时的变体。
- 常见错误现象：程序看似“卡住”，实际停在
await reader.read()，无报错也无输出 - 正确做法优先用
reader.read(n)（固定字节数）、reader.readuntil(b"\n")（按分隔符）或reader.readline()（行协议） - 务必加超时：用
asyncio.wait_for(reader.read(1024), timeout=5.0)，否则网络抖动或对端异常会拖垮整个协程池 -
writer.write()只是把数据塞进缓冲区，必须跟await writer.drain()才真正尝试发送，否则大包可能滞留内存不发出
连接意外中断后怎么安全清理？writer.close() 不等于连接已断
writer.close() 只是标记写通道关闭，底层 socket 不会立刻释放；若不 await writer.wait_closed()，就可能遇到“socket closed while sending”或资源泄漏。
- 常见错误现象：
RuntimeError: writer is closed或OSError: [Errno 9] Bad file descriptor，多发生在重连逻辑里复用了已 close 的writer - 标准清理流程必须成对出现：
writer.close()→await writer.wait_closed()；漏掉后者，socket 可能 linger 在 CLOSE_WAIT 状态 - 不要依赖
finally块里的裸writer.close()—— 它不 await，无法保证执行完成；应写成try...finally+await writer.wait_closed() - 如果连接已断（如对端崩溃），
await reader.read(1)会立即返回空 bytes，这是检测断连最轻量的方式，比心跳包更可靠
并发多个 async TCP 客户端时 CPU 占用飙升？注意默认缓冲区和日志开销
asyncio 本身不阻塞，但大量小包频繁收发 + 无节制打印，会让事件循环线程忙于 syscalls 和字符串格式化，表现就像 CPU 跑满。
立即学习“Python免费学习笔记（深入）”；
- 性能影响：默认
reader缓冲区是 64 KiB，但若每次只 read(1)，会触发上千次系统调用；批量读（如read(8192)）+ 循环解析更高效 - 避免在主收发循环里做耗时操作：比如把
json.loads()或正则匹配放在await外面；它们不 await，但会阻塞事件循环 - 调试时慎用
print()：每秒几百次连接收发，print 会成为瓶颈；改用异步日志库（如aiologger）或关闭调试输出 - Windows 上
ProactorEventLoop对高并发 TCP 更友好，Linux/macOS 用默认SelectorEventLoop即可，不用强行切换
异步 TCP 容易被当成“只要加 async/await 就自动高性能”，其实字节流边界、缓冲区管理、连接生命周期这三块，稍不注意就会从协程退化成同步阻塞——而且更难 debug。
