本文详解如何通过服务端状态共享与客户端主动刷新机制，在 flet 框架中实现多用户访问时的全局计数器实时同步，避免页面陈旧数据问题，无需手动刷新即可保持所有客户端视图一致。
在 Flet 中，每个 page 实例是独立的客户端会话（session），这意味着 views_count 这类全局变量仅在单个 Python 进程内有效，且不同用户连接会触发独立的 main() 执行——因此你观察到“用户1看到1、用户2看到2、但用户1未更新”是预期行为：状态未共享，更新未广播。
单纯调用 page.update() 只能刷新当前会话的 ui，无法影响其他已连接的客户端。而无限循环 while True: page.update() 会阻塞主线程，导致事件（如路由跳转、点击）无法响应，造成界面冻结——这正是你遇到“页面停止响应”的根本原因。
✅ 正确解法需满足两个核心原则：
- 状态集中管理：将计数器持久化到进程外（如文件、数据库），并确保读写线程安全；
- 每次请求动态渲染最新值：不在初始化时静态捕获 views_count，而是在每次路由变更或页面构建时实时读取并渲染当前最新值。
以下是优化后的完整实践方案（含文件锁保障并发安全）：
import flet as ft import threading import os # 全局文件锁，防止多会话并发写入冲突 file_lock = threading.Lock() def get_views_count() -> int: """安全读取当前浏览量""" try: with open("views", "r") as f: return int(f.readline().strip() or "0") except (FileNotFoundError, ValueError): return 0 def increment_views() -> int: """原子化递增并返回新值""" with file_lock: count = get_views_count() count += 1 with open("views", "w") as f: f.write(str(count)) return count def main(page: ft.Page): page.title = "Real-time View Counter" page.vertical_alignment = ft.MainAxisAlignment.CENTER # ✅ 关键：不缓存初始值！每次 route_change 都重新读取最新状态 def route_change(e: ft.RouteChangeEvent): # 清空旧内容，避免重复添加 page.clean() # 动态获取最新计数 + 更新UI current_views = increment_views() views_display = ft.Container( content=ft.Text(f"Views: {current_views}", size=24, weight="bold"), alignment=ft.alignment.center, ) page.add(views_display) page.update() # 仅更新当前会话的页面 # 绑定路由事件 page.on_route_change = route_change page.go("/") # 初始化路由? 关键改进说明：
- increment_views() 封装了带锁的原子写入，避免并发写入导致计数丢失；
- route_change 中不再依赖全局变量 views_count，而是每次调用都 get_views_count() → increment_views() → 渲染，确保每个用户看到的是全局最新值；
- page.clean() + page.add() + page.update() 构成标准 UI 刷新范式，安全可靠；
- 移除了所有冗余的文件反复打开/关闭操作，提升健壮性。
⚠️ 注意事项：
- 若需更高并发能力（如千级用户），建议替换为 redis 或轻量数据库替代文件存储；
- Flet 本身不提供服务端推送能力（如 websocket 广播），因此“用户A刷新后用户B自动更新”需借助客户端轮询（不推荐）或前端集成 SignalR 等方案——但在典型计数场景中，每次导航即拉取最新值已是最优实践；
- 生产环境务必添加异常处理（如 try/except 包裹文件 I/O）并设置合理的日志记录。
总结：Flet 的实时同步本质是「状态去中心化 + 视图按需渲染」。放弃“维护全局内存状态”的思路，转向“每次交互都查最新状态”，配合线程安全的持久化层，即可优雅解决多用户数据一致性问题。