最小可行通信核心是服务器监听、客户端连接、双方收发数据；socket需AF_INET与SOCK_STREAM配对；bind用"0.0.0.0"允外部访问，"127.0.0.1"仅限本机；recv()需防阻塞，sendall()优于send()。
直接能跑通的最小可行通信，核心就三步：服务器监听、客户端连接、双方收发数据。其他全是围绕这三点的容错和扩展。
socket() 创建套接字时，AF_INET 和 SOCK_STREAM 必须配对
这两个参数不是随便选的：AF_INET 表示 IPv4 地址族，SOCK_STREAM 表示 TCP 流式传输。混用会报错，比如用 SOCK_DGRAM（UDP）却走 TCP 逻辑，connect() 或 send() 可能直接失败。
- Linux/macOS 下错误通常是
Protocol not supported或Operation not supported - Python 中若写成
socket(AF_INET, SOCK_DGRAM)却调用connect()，会抛OSError: [Errno 95] Operation not supported - 服务端监听必须用
SOCK_STREAM+listen()；客户端也得用同类型才能connect()
bind() 绑定地址时，“0.0.0.0” 和 “127.0.0.1” 的区别很关键
bind() 的地址参数决定服务器能被谁访问。"127.0.0.1" 只响应本机回环请求，外部机器连不上；"0.0.0.0" 才监听所有网卡，允许局域网或公网设备连接。
- 开发调试阶段用
"127.0.0.1"更安全，避免意外暴露端口 - 部署到树莓派或云服务器时，必须用
"0.0.0.0"，否则客户端connect()会超时 - 如果绑定了具体内网 IP（如
"192.168.1.100"），只对该网段生效，换网络就失效
accept() 后的 conn.recv() 是阻塞的，不加处理会导致单连接卡死
默认模式下，conn.recv(1024) 会一直等满缓冲区或对方关闭连接。如果客户端只发一半数据就挂了，服务端线程就永远卡在这儿，无法处理新请求。
- 简单应对：给
recv()加超时，conn.settimeout(5)，捕获socket.timeout异常后主动关闭连接 - 更稳做法：在循环里检查
recv()返回值——空 bytes（b''）代表对方已关闭连接，应跳出循环并close() - 别依赖
recv()自动分包：TCP 是字节流，"hello"和"world"可能被合并在一次recv()中返回，也可能拆成两次
send() 和 sendall() 不是等价替换
send() 只保证尽力发送，返回实际发出的字节数，可能小于你传入的长度；sendall() 会循环调用 send() 直到全部发完或出错。生产环境几乎都该用 sendall()。
- 用
send()时必须检查返回值，比如n = conn.send(data)，若n ，得手动补发剩余部分 -
sendall()看似省事，但它在发送中途遇到连接断开（如客户端崩了），会直接抛异常，不会静默失败 - Python 中字符串要先
.encode()成 bytes 才能传给sendall()，否则报TypeError: a bytes-like object is required
真正难的不是写通第一对收发，而是让服务端扛住多个客户端同时连、不丢消息、不卡死、不崩溃——这些全藏在 accept() 后的连接生命周期管理里，而不是开头那几行 socket() 调用中。
