怎么利用 Socket 编程实现基础的客户端与服务器通信

先说几个核心判断：Socket通信这事儿，听起来玄乎，但把底层逻辑理清了，无非就是建立连接、收发数据、处理异常这三板斧。真正能把服务端写稳的，靠的不是背API，而是对连接生命周期里那些“坑”心里有数。

直接能跑通的最小可行通信，核心就三步：服务器监听、客户端连接、双方收发数据。其他全是围绕这三点的容错和扩展。听起来是不是很简单？但实际操作中，参数配错、地址绑错、阻塞没处理好，单机跑没问题，一上生产环境就崩的事儿，可太常见了。

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() 是阻塞的，不加处理会导致单连接卡死

别小看 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 < len(data)，得手动补发剩余部分
• sendall() 看似省事，但它在发送中途遇到连接断开（如客户端崩了），会直接抛异常，不会静默失败
• Python 中字符串要先 .encode() 成 bytes 才能传给 sendall()，否则报 TypeError: a bytes-like object is required

真正难的不是写通第一对收发，而是让服务端扛住多个客户端同时连、不丢消息、不卡死、不崩溃——这些全藏在 accept() 后的连接生命周期管理里，而不是开头那几行 socket() 调用中。