Flask 开启 debug=True 时自动启用重载机制，导致主进程被 fork 出多个子进程，而 queue.Queue 仅在线程间共享、不跨进程可见，因此 TCP 线程写入的队列在 Web 请求处理进程中为空。
flask 开启 debug=true 时自动启用重载机制，导致主进程被 fork 出多个子进程，而 `queue.queue` 仅在线程间共享、不跨进程可见，因此 tcp 线程写入的队列在 web 请求处理进程中为空。
在 Python 多线程编程中，queue.Queue 确实是线程安全（thread-safe）的——它通过内部锁机制保证多个线程对同一 Queue 实例的 put()/get() 操作不会引发竞态条件。但关键误区在于：Queue 并非进程共享（process-shared）。当 Flask 以 debug=True 启动时（如 app.run(..., debug=True)），Werkzeug 内置的重载器（reloader）会启动两个进程：一个监控文件变化的父进程，以及一个实际运行应用的子进程。每次代码修改后，子进程会被重启，而新进程拥有独立的内存空间——包括全新的 measurements = Queue(...) 实例。这意味着：
- TCP 服务器线程在原始进程中向
measurements写入数据； - 而
/measurements接口请求由重启后的子进程处理，其measurements是空的新队列。
因此，你看到 list(measurements.queue) 始终为空，而 handle_tcp_connection 中打印的长度却正常——它们根本不在同一个进程内存中。
✅ 正确解决方案
1. 禁用调试重载（推荐开发阶段临时使用）
if __name__ == "__main__":
# ❌ 错误：触发多进程重载
# app.run(host='0.0.0.0', port=PORT_UI, debug=True)
# ✅ 正确：单进程运行，确保所有线程共享同一 Queue 实例
app.run(host='0.0.0.0', port=PORT_UI, debug=False, use_reloader=False)
? 验证是否单进程：在路由和 TCP 处理函数中分别添加
print(os.getpid())，确认输出 PID 完全一致。
2. （进阶）使用跨进程通信方案（生产环境必备）
若需长期稳定运行或必须启用热重载（如配合 uvicorn），应改用进程安全的数据结构：
-
multiprocessing.Manager().Queue()：支持跨进程共享（但性能略低于queue.Queue）； - 或更推荐：使用轻量级持久化存储，如
sqlite3内存数据库（:memory:）或 Redis（适合分布式扩展）。
示例（使用 multiprocessing.Manager）：
from multiprocessing import Manager
# 替换原 Queue 初始化
with Manager() as manager:
measurements = manager.Queue(maxsize=86400) # 注意：需在主线程创建，并传入子线程
⚠️ 注意：Manager().Queue 不支持 list(q.queue) 这类直接访问内部属性的操作，需改用 q.qsize() 和循环 get_nowait() + put() 来实现“最近 24 小时”过滤逻辑。
3. 修复代码中的其他隐患
-
handle_tcp_connection中存在未定义变量value（应为dist）； -
measurements.get()在无数据时会阻塞，应改为measurements.get_nowait()并捕获queue.Empty； -
list(measurements.queue)属于内部实现细节，不应依赖（queue.Queue不保证.queue属性公开可用）；正确做法是使用queue.queue（不推荐）或改用collections.deque+ 手动加锁（若需频繁遍历）。
总结
queue.Queue 的“线程安全”不等于“进程安全”。Flask 的 debug=True 是典型诱因。开发时优先关闭重载验证逻辑；生产部署务必使用 gunicorn/uvicorn + 进程安全存储，而非依赖内存队列跨进程通信。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
