Pythonsocket编程入门详解

本文深入解析了Python socket编程中最核心却极易出错的基础模型，直击客户端必须用connect()、服务端必须用bind()+listen()+accept()这一不可颠倒的协议铁律，并系统厘清了阻塞与非阻塞模式下recv()的等待逻辑、超时设置陷阱（如settimeout(0)的致命误区）、send()不保证全量发送的本质原因及正确补发策略（推荐sendall()），同时强调accept()返回的连接socket完全独立于监听socket——需单独配置超时、关闭资源，避免因配置继承或泄漏导致卡死或连接耗尽；内容聚焦实战痛点，用典型错误（如ConnectionRefusedError）反推原理，帮助开发者避开90%的入门级socket坑。

socket.connect() 和 socket.bind() 到底谁该用在客户端

客户端必须用 connect()，服务端必须用 bind() —— 混用会直接报错或连不上。不是风格问题，是协议层强制要求。

常见错误现象：ConnectionRefusedError: [Errno 111] Connection refused，八成是客户端连了没启动监听的服务端；或者服务端误调用了 connect() 而不是 bind() + listen()。

• 客户端只管发起连接：先 socket()，再 connect((host, port))，之后读写
• 服务端要先占地址：bind((host, port))（host 通常用 '' 表示所有接口），再 listen()，最后 accept()
• bind() 在客户端不是必须的；但若你明确要指定源 IP 或端口（比如多网卡机器、端口复用场景），才需要提前 bind()，否则系统自动分配

阻塞 vs 非阻塞：recv() 卡住不返回怎么办

默认 socket 是阻塞的，recv() 会一直等数据来，哪怕对方只发了一半、或网络断了没通知。这不是 bug，是设计如此。

使用场景：简单脚本、调试工具、单连接小应用，阻塞最省心；高并发服务、带 UI 的程序、需要响应超时逻辑的，必须改非阻塞或用 select/poll。

• 设非阻塞：s.setblocking(False)，之后 recv() 立即返回，没数据就抛 BlockingIOError
• 更常用的是设超时：s.settimeout(5.0)，超时后抛 TimeoutError，比纯非阻塞好处理
• 注意：settimeout(0.0) 等价于 setblocking(False)，别写成 settimeout(0) —— 那是禁用超时，不是零秒

send() 不保证一次发完，为什么 data = b'hello' * 1000 有时只发了前 200 字节

TCP 是流式协议，send() 只负责把数据交给内核缓冲区，返回值是“实际拷入缓冲区的字节数”，不等于你传入的长度。尤其在网络忙、缓冲区满、或对方接收慢时，很容易少于预期。

性能影响：盲目循环调用 send() 不检查返回值，会导致部分数据静默丢失；而每次发一点就等确认，又严重拖慢吞吐。

• 正确做法是检查返回值，手动补发：

  while total_sent 

• 更轻量的替代：用 sendall() —— 它内部帮你循环补发，直到全发出或出错，推荐日常使用
• 注意：sendall() 不解决粘包，也不保证对方 recv() 一次收全；它只保证“发送端发出去了”

服务端 accept() 后的 conn 和 listen_sock 共享同一个文件描述符吗

不共享。每个 accept() 返回的新 socket（conn）是独立 fd，有自己的接收/发送缓冲区、超时设置、阻塞标志。修改 conn 的属性，完全不影响原始 listen_sock。

容易踩的坑：有人在 accept() 后忘了给 conn 单独设超时，结果沿用 listen_sock 的阻塞行为，导致后续 recv() 卡死；或者误以为关掉 conn 会影响监听。

• listen_sock 只负责接新连接，生命周期长；conn 处理单次会话，用完必须 close()
• 不要对 conn 复用 listen_sock 的配置，比如 settimeout()、setsockopt()，得重新设
• Windows 下 fd 数有限，conn 忘关会快速耗尽资源；Linux 虽宽松，但泄漏仍会导致 TIME_WAIT 积压

事情说清了就结束

好了，本文到此结束，带大家了解了《Pythonsocket编程入门详解》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！