accept()卡住是正常阻塞行为，因它需等待客户端连接；确认客户端已connect、服务端已正确bind()和listen()，并检查端口占用、地址解析及防火墙等问题。
socket.accept() 为什么总卡住不返回？
因为 accept() 是阻塞调用，它会一直等直到有客户端发起连接。这不是 bug，是设计使然——TCP 服务端本就该“守着端口等连接”。如果你在测试时发现程序停在 accept() 这一行不动，先确认客户端是否真的发起了 connect()；再检查服务端是否已成功 bind() 并 listen()。
常见疏漏点：
-
bind()传的地址是('localhost', 8080)，但客户端连的是127.0.0.1——多数情况没问题，但某些系统或防火墙策略下，localhost解析可能受 hosts 干扰，建议统一用('0.0.0.0', 8080)或('127.0.0.1', 8080) - 忘记调用
listen()，或者参数写成listen(0)（最小合法值是 1） - 端口被占用：运行时报
OSError: [Errno 98] Address already in use，加sock.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)再bind()
recv() 读不到完整消息？别假设一次能收完
TCP 是字节流协议，recv(n) 最多返回 n 字节，但可能返回更少（包括 0），尤其在网络延迟、小包发送、或对方调用 send() 分多次时。你不能指望 recv(1024) 一定填满 1024 字节，也不能默认一次 recv() 就对应一个“逻辑消息”。
实际处理建议：
立即学习“Python免费学习笔记（深入）”；
- 对短文本交互（如简单命令），可用
recv(1024).decode().strip()，但要容错空字节或解码失败 - 若需可靠接收定长数据（如协议头 4 字节表示 body 长度），得循环调用
recv()直到凑够指定字节数 - 若按行解析（如 HTTP/FTP 的 \r\n 分隔），不要依赖单次
recv()包含完整行，应缓存未处理字节，拼接后找换行符 - 收到空字节
b''表示对端已关闭连接，该close()对应的 client socket
为什么 accept() 返回的新 socket 要单独 recv()，不能用原 socket？
服务端 socket（调用 bind()+listen() 的那个）只负责“接客”，它本身不传输数据。accept() 返回的是一个全新的、已建立连接的 socket 对象，这个新 socket 才真正承载客户端与服务端之间的双向字节流。原 socket 必须保持打开，继续等待下一个 accept()；否则后续连接会被拒绝或丢弃。
典型错误写法：
server_sock = socket(AF_INET, SOCK_STREAM)
server_sock.bind(('127.0.0.1', 8080))
server_sock.listen(5)
conn, addr = server_sock.accept()
# 错误：用 server_sock.recv() —— 它根本没建立连接，会报 OSError
data = server_sock.recv(1024) # ❌
<h1>正确：用 accept 返回的 conn</h1><p>data = conn.recv(1024) # ✅
单线程服务端怎么同时处理多个客户端？
标准 accept()+recv() 是串行的：接一个、处理完、再接下一个。真想“同时”响应，必须让每个客户端连接脱离主线程阻塞。最直接的方式是为每次 accept() 到的 conn 启一个新线程：
- 用
threading.Thread(target=handle_client, args=(conn, addr)).start() -
handle_client()函数里做所有recv()/send()逻辑，并在结束前conn.close() - 注意线程安全：避免多个线程共用同一个文件对象或全局变量，除非加锁
更现代的做法是用 asyncio + async/await，但那是另一套并发模型；纯 socket 模块下，线程或进程是最直白的入门方案。别一上来就折腾 select() 或 epoll() —— 那是为万级连接准备的，不是为理解 accept 和 recv。
真正容易被忽略的是：每个 conn 的生命周期管理。忘了 close()，连接会堆积；过早 close()，数据可能发不出去；在异常路径里没 close()，会导致资源泄漏——这些比“怎么写 accept”更常引发线上问题。
