单机支撑5000+ WebSocket连接需避开三大坑：连接管理（用set+心跳+异常移除）、消息广播（asyncio.gather并发发送+分批+过滤）、阻塞调用（全程异步+线程池+异步DB/HTTP）。
单机撑住 5000+ 活跃 WebSocket 连接，不是靠堆硬件，而是避开连接管理、消息广播、阻塞调用这三个坑。FastAPI + Uvicorn 组合本身足够强，但默认写法极易掉进同步陷阱。
async def websocket_endpoint() 必须全程异步
常见错误是：在 websocket.receive_text() 和 websocket.send_text() 之间插入 time.sleep()、requests.get()、未加 await 的数据库查询，或直接用 json.loads() 解析大 JSON 字符串。这些操作会卡死整个事件循环，所有连接一起变卡。
- HTTP 调用必须换
httpx.AsyncClient，不能用requests - 数据库必须用异步驱动：
asyncpg（PostgreSQL）、aiomysql（MySQL），而非psycopg2或pymysql - CPU 密集型操作（如大 JSON 解析、加密）要丢进线程池：
await asyncio.to_thread(json.loads, data) - Pydantic 校验默认同步，高频场景建议关掉或改用
model_validate_json()避免重复解析
别用 list 存连接，set + try/except 才安全
用 active_connections = [] 然后遍历发送，看似简单，但客户端异常断开（比如关浏览器、网络中断）时，websocket.send_text() 会抛出异常，若没捕获，连接就永远留在列表里 → 内存持续上涨 → OOM。
- 改用
set而非list，天然去重且增删快 - 每次广播前必须对每个连接做
try/except，捕获WebSocketDisconnect和通用Exception，失败后立即从set中移除 - 加心跳检测：在
while True:循环里定期await websocket.ping()，超时主动close() - 生产环境务必用
psutil.Process().memory_info().rss定期打点监控连接数与内存增长
Uvicorn worker 数和并发限制必须手动配
gunicorn main:app -k uvicorn.workers.UvicornWorker -w 4 是常见配置，但盲目加 -w 反而降低性能 —— Uvicorn 本身是单线程异步，每个 worker 独占一个事件循环；过多 worker 会导致 CPU 上下文切换激增、内存冗余、甚至文件描述符耗尽。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
立即学习“Python免费学习笔记（深入）”；
- worker 数推荐值：
CPU 核心数 × 1～1.5（例如 4 核机器设-w 4或-w 6） - 必须加
--limit-concurrency 100，防止单个 worker 接收过多连接压垮内存 - 启用
--ws-per-message-deflate开启 WebSocket 压缩，文本消息体积可减小 40%+ - 生产环境禁用
--reload，它会 fork 多个进程导致连接状态不同步
广播不能 for-loop + await 逐个发
当有 2000 个连接时，for conn in connections: 然后 await conn.send_text(...) 是串行的，总延迟爆炸。正确做法是并发发起所有 send，再统一等待完成。
- 用
asyncio.gather(*[conn.send_json(msg) for conn in connections], return_exceptions=True) - 不要用
return_exceptions=False，否则一个连接失败整个广播就中断 - 如果连接数极大（>3000），建议分批
gather，每批 100～200 个，避免 event loop 负载过重 - 广播前先过滤掉已关闭连接（靠心跳标记或
try/except捕获结果判断），减少无效调用
最易被忽略的是连接泄漏和广播异常处理 —— 它们不会立刻报错，但会在几小时后让服务缓慢崩塌。上线前务必压测并观察 psutil 内存曲线和连接数变化趋势。
