客户端必须用 connect()，服务端必须用 bind()；阻塞模式下 recv() 会等待数据，超时或非阻塞需显式设置；send() 不保证一次发完，须检查返回值并补发。
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 积压
事情说清了就结束
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
