python socket建连后收不到数据主因是recv()默认阻塞，需设timeout、检查端口连通性、依返回值判断实际接收字节数，并区分tcp粘包（加长度头或分隔符）与udp特性；qwen本地部署不支持直接socket通信，需自建服务封装；windows端口冲突需so_reuseaddr及进程清理。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 免费无限量使用 DeepSeek R1 模型☜☜☜
Python 用 socket 建连后收不到数据？先看 recv() 是否阻塞
绝大多数“连上了但没反应”的问题，其实卡在 recv() 默认阻塞行为上。它会一直等，直到对端发来数据、关闭连接，或者超时（如果你设了 settimeout()）。没设超时又没发数据，程序就挂那儿不动了。
实操建议：
- 服务端启动后，先用
telnet localhost 8080或nc -u localhost 8080（UDP）手动连一下，确认端口真通、服务真在收 - 客户端加
sock.settimeout(3)，避免无限卡死；捕获socket.timeout异常做兜底 -
recv(1024)不代表一定能收到 1024 字节——它只保证最多收这么多，实际可能 1 字节、也可能 1024，得靠返回值判断是否读完 - 别用
recv()直接解析 JSON 或协议头；先收够包长，再解包
Python socket TCP 粘包怎么破？自己加分隔符或长度头
TCP 是字节流，不保留消息边界。你 send(b"hello") 两次，对方 recv(1024) 一次可能拿到 b"hellohello"，也可能第一次只收到 b"hel" —— 这不是 bug，是协议特性。
实操建议：
- 简单场景：每条消息末尾加换行符
\n，用makefile()包一层转成类文件对象，再调readline() - 更稳的做法：发送前先发 4 字节整数表示后续内容长度（
struct.pack("!I", len(data))），接收方先收 4 字节，再按长度循环recv()补齐 - 别依赖
sendall()解决粘包——它只保证发完，不负责分包 - UDP 天然无粘包，但不可靠、有大小限制（通常 65507 字节），别拿它传大文件
千问AI 本地部署后想 socket 对接？注意它默认不开放 HTTP 以外的端口
千问（Qwen）官方推理代码如 qwen-cli 或 transformers 加载模型，默认只提供 API 接口（HTTP/REST），没有内置 socket 服务。你不能直接连它的 8080 端口然后发 raw bytes。
实操建议：
- 如果非要 socket 通信，得自己写一层薄服务：用
socket监听，收到请求后调用model.generate()，再把结果序列化（如 JSON）回传 - 注意模型加载耗内存、推理慢——socket 每次新建连接都重载模型？绝对不行。得做成常驻进程 + 连接复用（如用
select或asyncio） - 别把
tokenizer和model放在handle_client()函数里初始化；它们必须全局复用，否则秒崩 - 官方
Qwen2ForCausalLM输出是 logits，要torch.argmax(..., dim=-1)才能转 token ID，再用tokenizer.decode()得到文本
Windows 上 socket 报错 [WinError 10048]？端口被占或未释放干净
[WinError 10048] Only one usage of each socket address (protocol/network address/port) is normally permitted，意思是这个地址+端口组合正被占用。常见于改代码后 Ctrl+C 中断服务，但系统还没回收连接（TIME_WAIT 状态）。
实操建议：
- 服务端加
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)，允许快速重用地址（Linux 也建议加） - 用
netstat -ano | findstr :8080查 PID，再用taskkill /PID 1234 /F干掉残留进程 - 别让多个脚本同时 bind 同一个端口；测试时用随机端口
sock.bind(("", 0))，然后sock.getsockname()[1]拿实际分配的 - Python 脚本异常退出时，
sock.close()可能没执行；用try/finally或上下文管理器with socket.socket() as s:更安全
socket.socket()，而是处理好连接生命周期、缓冲区边界、错误恢复——这些地方没日志、不压测，上线后才露馅。 
