直接用socket写聊天室易卡死或收不到消息，因默认阻塞I/O使recv()死等数据、send()缓冲满时阻塞，双向等待导致“双卡”；须用非阻塞、多线程或select/poll破局，新手推荐服务端多线程处理连接、客户端收发分线程。
为什么直接用 socket 写聊天室容易卡死或收不到消息
因为 socket 默认是阻塞式 I/O，recv() 会一直等数据来，send() 在缓冲区满时也会卡住；客户端和服务端若都只调一个 recv() 就停住，互相等对方先发，就“双卡”。必须用非阻塞、多线程或 select/poll 打破单线程等待困局。
新手最稳妥的起步方式是：服务端用多线程处理每个客户端连接，客户端用两个线程分别负责收和发——这样逻辑清晰、改动少、不依赖额外库。
- 服务端每 accept 一个新连接，就
threading.Thread(target=handle_client, args=(conn, addr)).start() - 客户端启动后立即开一个线程跑
recv()循环，主线程只管input()和send() - 别用
time.sleep(0.1)去“防卡”，那是掩盖问题；线程才是正解
如何让多个客户端之间真正“看到彼此的消息”
服务端不能只把收到的消息 echo 回原客户端，得维护一个所有活跃连接的列表，每次收到消息就遍历转发（排除自己）。但要注意：连接断开时没清理列表，就会在下次广播时报 OSError: [WinError 10053] 或 BrokenPipeError。
关键不是“转发”，而是“安全转发”：每次 send() 前加 try/except，失败就从列表中移除该连接。
- 用
clients = []存连接对象，每次append(conn)后记得conn.setblocking(False)或至少设超时（conn.settimeout(2)）避免某客户端挂起拖垮全体 - 转发循环里捕获
ConnectionResetError、BrokenPipeError、TimeoutError，然后clients.remove(conn) - 别用字符串拼接做协议，哪怕只是加个换行符
\n—— 客户端recv(1024).decode().strip()才能稳定切分消息
为什么客户端输完消息没反应，或者发一次就退出
常见原因是发送后没加换行或结束标记，服务端 recv() 拿到的是不完整数据，又没做粘包处理，导致后续所有消息错位。更隐蔽的问题是：客户端主线程在 send() 后直接 break 或结束，而接收线程还在跑，Python 可能强制终止子线程，造成资源残留。
最简方案就是约定消息以 \n 结尾，双方都按行收发 —— 这比自己解析长度头或 JSON 更适合新手验证逻辑。
- 客户端
input()后立刻sock.send((msg + '\n').encode()) - 服务端用
conn.makefile('r', newline='\n')包装连接，再用for line in file_obj:逐行读（自动处理缓冲和换行） - 客户端接收线程里也用
makefile('r')+readline()，别用recv(1024)硬截
Windows 上测试时连不上，报 ConnectionRefusedError: [WinError 10061]
这说明客户端连的地址或端口根本没服务在监听。90% 是因为：服务端没跑、服务端绑定的是 '127.0.0.1'（只接受本机连接）、防火墙拦截、或端口被占用。
局域网内多台机器互通，服务端必须绑定 '0.0.0.0'，而不是 'localhost' 或 '127.0.0.1'；客户端连的时候填服务端真实局域网 IP（如 192.168.1.105），不是 127.0.0.1。
- 服务端
s.bind(('0.0.0.0', 8888))——0.0.0.0表示监听所有网卡 - 查服务端 IP：Windows 运行
ipconfig，找 “IPv4 地址” 那行；macOS/Linux 用ifconfig | grep "inet " - 临时关防火墙测试：
netsh advfirewall set allprofiles state off（完事后记得开回来）
实际跑通的关键不在“功能多全”，而在每条连接是否干净建立、消息是否按约定边界收发、异常是否被及时清理。很多看似通信失败的问题，其实是某个连接静默断开后还留在列表里，下一次广播就崩掉整个服务端。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
