pytest-timeout 不适合处理 Socket 阻塞，因其仅在测试函数级超时后强制杀进程，无法捕获 connect()/recv()/send() 等系统调用层面的阻塞，且导致 fd 泄漏、掩盖真实网络问题；应改用显式 socket.settimeout()。
pytest-timeout 不能防止 Socket 死锁，它只负责在测试函数整体超时后强制终止进程 —— 这会掩盖真实问题，且无法捕获连接阶段的阻塞。
为什么 pytest-timeout 不适合处理 Socket 连接不稳定
Socket 阻塞发生在 connect()、recv() 或 send() 等系统调用层面，而 pytest-timeout 是在 Python 解释器层通过信号（Unix）或线程监控（Windows）中断整个测试函数。一旦触发，你得不到任何堆栈信息，也分不清是 DNS 解析卡住、SYN 包丢失，还是对方 SYN-ACK 没回来。
更严重的是：强制 kill 可能留下未关闭的 socket 文件描述符，导致后续测试因 Address already in use 或 Too many open files 失败。
- 它不干预 socket 的 I/O 行为，只是“计时+杀进程”
- 无法区分“慢但有效”和“彻底卡死”，容易误判
- 在 CI 环境中可能掩盖网络配置缺陷（如防火墙拦截、DNS 轮询异常）
真正该在测试里做的：显式设置 socket.settimeout()
所有 socket 操作都应带明确超时，尤其在单元/集成测试中。这是唯一可控、可调试、可复现的方式。
立即学习“Python免费学习笔记（深入）”；
-
settimeout(3.0)对connect()和recv()都生效；设为0.0切换非阻塞模式（需配合select或poll） - 避免用
socket.setdefaulttimeout()—— 它影响所有新 socket，测试间易污染 - 超时值建议设为生产环境值的 1.5~2 倍（例如生产用 2s，测试用 4s），既防假阳性，也不拖慢 CI
def test_socket_client_connects():
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.settimeout(4.0) # 显式、局部、可读
try:
s.connect(("localhost", 8080))
assert s.fileno() > 0
finally:
s.close() # 必须 close，否则 fd 泄漏测试中检测连接是否真的断开（而不仅是超时）
仅靠超时不够 —— 你得确认失败原因是网络不可达，而不是服务没启、端口错、或 TLS 握手卡住。关键看异常类型：
-
ConnectionRefusedError：目标端口无监听进程（最常见于本地测试） -
OSErrorwith.errno == errno.EHOSTUNREACH或ECONNRESET：路由不通或对端 RST -
socket.timeout：纯等待超时，不说明底层连通性 - 不捕获
Exception—— 否则会吞掉MemoryError或KeyboardInterrupt
复杂点在于：测试套件里混用阻塞/非阻塞 socket 很容易出错
比如你在 fixture 中创建了一个 setblocking(False) 的 socket，又在测试里直接调用 recv(1024)，结果抛 BlockingIOError 而不是 socket.timeout —— 这种不一致会让断言逻辑混乱。务必统一策略：
- 单元测试优先用阻塞 +
settimeout()，语义清晰 - 集成测试若需模拟高并发，再用
select.select()或asyncio.open_connection()，但要单独隔离 - 永远在
finally或contextlib.closing()中释放 socket，别依赖 GC
