“只写 Python”进入生产环境后，承诺发生了变化
Flet 团队发布了 Flet 1.0，这是一个开源 Python 框架。开发者用 Python 编写界面，Flet 通过 Flutter 渲染 Material 和 Cupertino 控件，并将同一套源码构建到 iOS、Android、Windows、macOS、Linux 和浏览器。SDK 要求 Python 3.10 或更高版本，Flet 1.0.0 已发布到 PyPI，采用 Apache 2.0 许可，安装入口是 pip install 'flet[all]'。它面对的问题很明确：让不使用 Dart、Swift、Kotlin 或 JavaScript 的团队，仍能把一个应用送到多个端。
但对技术负责人来说，1.0 的判断标准不能是“能不能写出一个跨端界面”。这类框架最容易把开发阶段的统一语法误认为交付阶段的统一环境。真正的变化在于，Flet 把生产就绪的证据放到了构建、运行时打包、原生依赖和已打包应用测试上。换句话说，它没有消除跨端复杂度，而是试图把复杂度从业务代码里移到一条可以反复执行的工程链中。
八个目标不是八个按钮，而是一条发布矩阵
Flet 的 CLI 接受八类目标：apk、aab、ipa、ios-simulator、windows、macos、linux 和 web。最终产物覆盖六个平台，但这并不意味着只需点击一次构建按钮。框架单元测试覆盖 Python 3.10 到 3.14，同时覆盖 Flutter 侧。控件和示例集成测试检查行为并比较截图，原生库测试则在 Android 和 iOS 模拟器上运行 Python 二进制包。
更重要的是，测试链继续向发布后的形态延伸。构建集成测试会在不同 Python 版本下编译六个平台的应用，flet test 可以启动已打包应用并在五个原生平台上驱动它，其中包括 Linux ARM64。应用团队也可以用 pytest 编写自己的集成测试，并通过 flet test 针对打包结果执行，Android 和 iOS 还支持截图比较。这使“跨端支持”从文档里的兼容性声明，变成可以放进 CI 的组合矩阵。
真正的边界从控件转向 Python 依赖和原生运行时
Flet 1.0 的跨端能力，最终会被依赖而不是控件数量限制。官方包索引列出超过 100 个包，包括 NumPy、pandas、Matplotlib、Pillow、SciPy、scikit-learn、cryptography 和 pydantic-core，并由 mobile-forge 自动构建 iOS 与 Android 的 wheel。这个列表说明 Python 生态正在被搬进移动端，但它不等于所有包在所有目标上都可用。材料明确提示，可用性仍然取决于具体包和目标平台，尤其是带原生库的依赖。
运行时设计则揭示了 Flet 代替团队承担了哪些工作。应用会把 Python 3.12、3.13 或 3.14 随应用一起打包，Web 构建使用对应的 Pyodide 版本。原生应用中的 dart-bridge 让 Python 和 Dart 在同一进程内通信，不经过 socket，并为二进制数据提供专用通道。Android 打包可以直接从 APK 加载 Python 包而不先解压，打包默认启用字节码编译。这些选择可能减少通信和加载路径的额外开销，却也让排障更加依赖 Flet 的打包逻辑、目标平台和测试覆盖。
声明式界面降低状态负担，却把事件循环变成升级风险
Flet 1.0 同时保留声明式和命令式两种写法。声明式 UI 把界面描述为应用状态的函数，并组织成可复用组件，状态变化后由框架重新处理界面。命令式写法则仍然允许事件处理器直接修改控件。Flet Studio 和 Flet 移动应用本身都采用声明式 Flet 应用，说明这不是只存在于文档中的实验接口。
声明式模型并没有让性能问题自动消失。Flet 现在跟踪发生变化的属性，跳过不必要的比较，0.83 基准显示控件 diffing 的性能最高提升 6.7 倍，但这仍然是框架内部优化，不是业务代码可以无条件获得的保证。对 0.28 用户而言，更危险的迁移点在事件循环。旧版本处理器各自运行在线程中，1.0 改为运行在应用事件循环上，因此同步处理器中的阻塞 I/O 或计算可能冻结 UI。升级时必须重新检查处理器，必要时改用异步处理器或线程。
AI 工具能缩短查找路径，却不能替代构建证据
Flet 还把版本化文档接入了 AI 开发流程。Flet MCP server 可以向 AI 编程助手提供特定版本的 API 信息，并帮助查找示例、图标和 CLI 选项。Flet Studio 在浏览器中运行，内置 AI agent，项目完成后可以下载到本地继续开发。对于跨端框架而言，这种工具可以减少 API 版本、构建命令和组件用法之间的查找成本，尤其适合快速搭建已有 Python 代码的界面层。
但 MCP 提供的是可查询的知识和工具入口，不是目标平台上的运行结果。它不能替团队证明某个 Python 二进制包能在指定设备上工作，也不能替代打包应用的权限验证、性能观察、截图回归和事件循环测试。技术负责人更适合把 Flet 看成一条集中管理跨端复杂度的工程路线，而不是绕过原生工具链的捷径。采用前，先为每个目标平台列出依赖和 Python 版本，再用真实应用跑通最难的平台，最后把 flet build 与 flet test 纳入持续集成。这样才能判断团队得到的是可维护的发布能力，还是一个只能在演示环境成立的跨端承诺。