FastAPI后端通过@app.websocket("/ws")暴露WebSocket端点，Tkinter客户端需用websockets库在子线程中连接并调用await websocket.accept()；收发消息必须经queue.Queue中转，严禁跨线程直接操作Tkinter控件。
FastAPI后端如何暴露WebSocket端点供Tkinter连接
Tkinter本身不支持原生WebSocket，但可以用 websockets 库在子线程中维持连接。FastAPI必须用 WebSocket 而非HTTP路由，且不能混用 async def 和阻塞式Tkinter主循环。
关键点：FastAPI的WebSocket端点需显式调用 await websocket.accept()，否则Tkinter客户端会卡在连接阶段；同时要避免在WebSocket handler里直接调用Tkinter控件（如 label.config()），会触发线程冲突。
- FastAPI端必须用
@app.websocket("/ws")，不是@app.get() - 不要在WebSocket handler里执行
root.update()或修改StringVar—— 这些操作只能在主线程做 - 推荐用
queue.Queue中转消息：子线程收到WebSocket数据后put()到队列，主线程用root.after(100, check_queue)定期检查
Tkinter如何在主线程安全地收发WebSocket消息
直接在Tkinter主线程启动 asyncio 事件循环会卡死GUI；用 threading.Thread 启动独立异步循环是可行路径，但必须确保该线程只负责I/O，不触碰任何Tkinter对象。
典型错误是写 await websocket.send("hello") 在按钮回调里——这会阻塞UI，因为没用 asyncio.to_thread() 或线程隔离。
立即学习“Python免费学习笔记（深入）”；
- 发送消息：按钮回调中往
queue.Queue放字典（如{"type": "send", "data": "ping"}），由后台线程消费并调用await websocket.send() - 接收消息：后台线程收到
await websocket.receive_text()后，queue.put({"type": "recv", "data": msg}) - 主线程用
root.after(50, lambda: process_queue(queue))检查队列，再更新Text或Label
为什么用 queue.Queue 而不用 threading.Event 或全局变量
threading.Event 只能通知“有事发生”，无法传递数据；全局变量在多线程下可能被覆盖或读取到中间状态，尤其当FastAPI发来连续JSON消息时，Tkinter主线程可能解析到半截字符串。
queue.Queue 提供原子性 put()/get()，且默认阻塞行为可防止竞态。注意：如果后台线程崩溃，队列可能堆积，建议加超时和最大长度限制。
- 初始化时用
queue.Queue(maxsize=100)防止内存暴涨 - 主线程
get()必须带timeout=0.1，否则root.after会卡住 - 不要用
queue.Empty异常控制流程——它只是信号“暂无数据”，不是错误
FastAPI WebSocket断开时Tkinter如何感知并重连
FastAPI默认不主动发close帧，Tkinter端靠 await websocket.receive_text() 抛出 websockets.exceptions.ConnectionClosedOK 或 ConnectionClosedError 来判断断连。但Tkinter主线程无法捕获这个异常——它发生在后台线程里。
解决方案是让后台线程在异常后向队列发特殊信号，例如 {"type": "disconnect", "reason": "closed"}，主线程收到后禁用发送按钮、显示重连提示，并启动定时重试逻辑。
- 重连间隔要用指数退避，比如第一次1秒，第二次2秒，第三次4秒，避免高频请求打垮后端
- 重连前检查
websocket.closed状态，避免重复connect() - FastAPI端若配置了
ping_interval=20，Tkinter端必须响应pong，否则连接会被自动关闭
tcl.TclError: invalid command name。 
