socket.accept()后必须用新线程或异步处理，否则主线程阻塞在recv()会导致服务端无法接受新连接；多线程适合I/O密集低并发，asyncio适合高并发；不可混用settimeout()与setblocking(False)；需正确处理客户端断开和发送异常；readexactly()适用于固定长度协议，read()适用于流式数据。
为什么 socket.accept() 后必须用新线程或异步处理
阻塞在 accept() 本身没问题，但一旦接收到连接，若直接在主线程里调用 recv() 并处理业务逻辑，整个服务端就卡死——后续连接无法被接受，超时、重传、连接拒绝都会发生。
常见错误是写成“主线程 accept → 主线程 recv → 主线程 send → 关闭”，这本质是串行单连接模型，不是服务端。
- 多线程：每个连接分配一个
threading.Thread，适合 I/O 密集、连接数不超几百的场景 - 异步（
asyncio）：用async def handle_client()+asyncio.start_server()，内存开销低，适合高并发 - 进程池（
multiprocessing）极少用于 TCP 服务端，因进程间通信和 socket 继承复杂，容易出错
socket.settimeout() 和 socket.setblocking(False) 别混用
两者目标都是避免永久阻塞，但机制冲突：setblocking(False) 让所有 I/O 立即返回（OSError: [Errno 11] Resource temporarily unavailable），而 settimeout() 是阻塞式调用带超时。混用会导致行为不可预测，比如 recv() 抛出 timeout 异常后又突然抛出 EAGAIN。
- 想用超时控制：只设
sock.settimeout(30)，然后正常recv()，捕获socket.timeout - 想用非阻塞 + 轮询：只设
sock.setblocking(False)，然后配合select.select()或epoll使用 - 用
asyncio时完全不用手动设 timeout 或 blocking，它内部已封装
如何安全关闭客户端连接而不触发 ConnectionResetError
客户端断开时，服务端若还在调用 recv()，会返回空字节 b''；但若服务端先调用 close()，而客户端紧接着发数据，就可能收到 RST，再调用 send() 就抛 ConnectionResetError。
立即学习“Python免费学习笔记（深入）”；
- 必须检查
recv()返回值：等于b''表示对端已关闭，应立即退出循环并close() - 发送前可加
try/except捕获ConnectionResetError和BrokenPipeError，然后清理资源 - 不要依赖
finally块里的sock.close()来“兜底”——如果send()已失败，close()可能触发 SIGPIPE（尤其在 Linux 上）
使用 asyncio 时，StreamReader.read() 和 readexactly() 的区别很关键
HTTP、自定义二进制协议等场景下，读取长度不确定或需严格按字节边界解析时，选错方法会导致粘包、截断或无限等待。
-
read(n)：最多读n字节，可能返回少于n（包括b''），适合流式文本或有分隔符的协议 -
readexactly(n)：必须读满n字节才返回，否则挂起（或抛IncompleteReadError），适合头部固定长度的协议（如 4 字节包长） -
readuntil(separator)：遇到分隔符才返回，含分隔符，适合 HTTP 请求行或行协议 - 永远别在未校验数据完整性前就调用
write()——比如读到 2 字节就发响应，但实际协议要求先读 4 字节长度头
真正难的不是写通，而是处理半包、重复 FIN、TCP 快速重传导致的乱序字节流。这些细节不会报错，但会让协议解析器静默失败。
