Flutter 年度路线图档案（2020–2025）解读：从渲染引擎更迭到六平台生态的演进主线

导读

本篇文章以仓库 docs/roadmap/[Archive]-Old-Roadmaps.md 中归档的 2020—2025 六份年度路线图为骨架，逐主题梳理 Flutter 在渲染（Impeller/Skia 迁移）、Web（Wasm 与 JS Interop）、移动端（SwiftPM/Cupertino/平台互操作）、桌面多窗口、Dart 语言演进、工具链与 AI、发布节奏以及官方“Non-goals（不做清单）”上的完整脉络，并结合本仓库当前源码、目录与测试给出可核对的落地证据。读完本文，你将理解 Flutter 数年来真正被反复投入的技术主线是什么、官方如何做取舍，以及如何把“路线图意图”与仓库中实际可见的实现对应起来——这对跟踪 Flutter 演进、做技术选型预判和参与贡献都具有直接的参考价值。

阅读前提：这份档案是 Flutter 官方 2020—2025 年发布的历史性、愿景式文件（原文多次强调“aspirational … a statement of intent and not a guarantee”），其内容描述的是当时的规划意图，而非对仓库现状的承诺。文中凡属规划内容均按“当年计划”口径叙述；凡标注“从当前仓库看/已落地”的部分，均以本仓库实际文件为证据。

---

一、文档定位：一份“六连更”的技术演进档案

当前正式路线图 在末尾注明“We maintain an archive of roadmaps from previous years in a separate page”，所指即本档案。仓库同时保留了两类内容：

• docs/roadmap/Roadmap.md：最新年度路线图（本仓库快照中已含 2026 展望，涉及 Impeller Android 迁移完成、Wasm 默认化、GenUI/A2UI、Dart Cloud Functions、MCP Server 等新方向）；
• docs/roadmap/[Archive]-Old-Roadmaps.md：本篇文章的主体——2020、2021、2022、2023、2024、2025 六份年度路线图的完整归档，供研究者回溯“哪些承诺兑现了、哪些被延后、哪些被明确放弃”。

档案正文逐年展开，且多数年份沿用了相近的章节模板（Accessibility、Performance、Mobile、Web、Desktop、Core framework、Tooling、Dart、Releases、Non-goals），这恰恰为我们提供了纵向对比的便利：同一主题（如 Impeller、Wasm、SwiftPM）在 2022—2025 年间如何从“调研”→“迁移中”→“默认化”层层递进，都可以在本文中对照阅读。

另有两点官方在档案中反复交代的“读法”：

1. 路线图内容主要来自 Google 内 Flutter/Dart 员工，但“非 Google 贡献者数量早已超过 Google 雇员”，因此它不是贡献者意图的穷举；
2. 官方优先级很大程度上由 GitHub issue 首条评论的 “Thumbs-Up” 反应数驱动。这一点在 2023 年章节被明确写出，也呼应了仓库中 docs/contributing/issue_hygiene/Popular-issues.md 对 Top-10 高赞 issue 的逐一讨论，以及 docs/contributing/issue_hygiene/README.md 对优先级策略的整体说明。

---

二、历年主题速览：一张表看清六年主线

年份	年度最大主题	关键技术关键词（摘录）
2020	Web/Desktop 地位提升 + 质量优先	Web 达 beta 级质量；“flutter create; flutter run 一次覆盖六平台”；以修 bug 为主；router 重构、实例状态保存恢复、i18n 工作流
2021	Sound Null Safety + 六平台生产级	Dart 空安全落地与生态迁移；iOS/Android 启动 jank；Web/桌面生产级；多独立窗口；一个月一个 beta
2022	开发者体验 + 桌面转正 + 渲染后端重写	Material 3、跨 widget 文本选择、菜单体系；桌面按 Win/Linux/macOS 逐个上 stable；为消除 shader jank 重写图形后端（Impeller 前身）、DisplayList；Web 嵌入普通 HTML
2023	性能为第一优先级	彻底移除 shader compiler jank（先 iOS）；Web 支持 Wasm 目标与多线程渲染；SLSA-3 供应链安全；特性落地（自定义资源 transformer、2D 滚动、多窗口、拖放、iOS 无线调试等）；桌面 Platform Views
2024	Impeller 推进 + 互操作 + AI	iOS 移除 Skia 后端；Android 支持 Vulkan/OpenGLES（保留 Skia opt-out）；Material 3 补完；Dart↔ObjC/Swift/Java/Kotlin 直调；WasmGC 编译与新 JS Interop；Web hot reload 重启；宏观评估 Dart 宏方案
2025	Impeller 默认化 + SwiftPM + Web 深化	Android API 29+ 以 Impeller 为默认、旧设备保留 Skia；SwiftPM 成 iOS 默认依赖方案；移除 legacy HTML/JS 库；Web hot reload 上线；宏方案被判不可行、转向 build_runner；analyzer 与前端的共享重构

---

三、渲染与性能主线：从 “shader jank” 到 Impeller 全面默认化

这是档案中贯穿年份最多、叙述最连贯的一条技术主线，完整记录了 Flutter 图形栈的换代轨迹。

3.1 问题原点：jank 与 shader 编译卡顿

• 2021 年路线图明确提出继续治理 iOS/Android 的启动期 jank；
• 2022 年档案自述：2021 年虽解决了若干 jank 问题，但结论是“需要彻底重新思考 shader 的使用方式”，因此开始重写图形后端，并计划先把 iOS 迁移到新架构，再依据经验移植到其他平台；同时推进由其新 DisplayList 系统带来的性能分析与自省能力。

3.2 Impeller 迁移的“三步走”

• 2023：把“彻底移除 shader compiler jank”列为年度首要性能任务，计划路径为“先 iOS，再 Android 与桌面”；Web 端则推进 Wasm 目标、多线程渲染、缩减基础应用下载体积并优化自定义 shader 性能；VM 后端方面改进内存分配策略以提升响应与启动速度。
• 2024：将 iOS 侧移除 Skia 后端列为计划内完成项；Android 侧目标为支持 Vulkan 与 OpenGLES，近期仍保留切回 Skia 的 opt-out 开关；同时改进 Impeller 测试基础设施以降低线上回归。
• 2025：完成 iOS 迁移（移除 Skia 后端）；Android 聚焦 API level 29 及以上的现代设备，使 Impeller 成为默认渲染器，同时因 2024 年在旧设备上发现的问题，暂定旧设备继续保留 Skia 支持。

3.3 仓库中的落地证据

从当前仓库源码结构看，这条主线已深度落地：

• engine/src/flutter/impeller：Impeller 渲染器源码目录（含 core/entity/renderer/display_list/compiler 等模块），说明渲染器本身已完整存在于引擎内；
• engine/src/flutter/display_list 与 engine/src/flutter/flow：DisplayList 及绘制流水线相关代码；
• engine/src/flutter/skia：Skia 相关代码仍保留，与路线图“旧设备保留 Skia、分阶段移除”的叙述吻合；
• engine/src/flutter/shell/common/switch_defs.h 与 engine/src/flutter/shell/platform/android/io/flutter/embedding/engine/FlutterEngineFlags.java：存在 impeller.enabled 等命令行/嵌入层开关定义，印证了“Impeller 可通过开关控制”的工程事实（Android 端 FlutterShellArgs 亦透传相关 flag）。

需要说明的是：路线图文本仅表达计划与方向，以上目录/开关只能证明计划中的工程实体已存在于当前仓库，具体某次发布默认与否应以对应版本发布说明为准。

---

四、Web 平台：性能治理、Wasm 与新 JS Interop

Web 在六份档案中几乎年年出现，可归纳为“质量与性能 → Wasm 编译链 → 生态清理”三个阶段。

4.1 早期：把 Web 抬到与移动端对等的地位

• 2020 年档案回顾 2019 年 Flutter Interact 上宣布 Web 达到 beta 级质量，并计划让 flutter create; flutter run 生成的应用能在浏览器、macOS、Windows、Android、Fuchsia、iOS 上运行，且拥有 hot reload、插件、测试与 release 构建支持；
• 2021 年目标升级为“交付 Web 的生产级质量”，重点放在保真度与性能而非新功能；
• 2022 年计划提升 Web 的性能、插件质量、无障碍、跨浏览器一致性，并“显著降低把 Flutter 应用嵌入其他非 Flutter HTML 页面的难度”（即后来的 element embedding 方向）。

4.2 Wasm：从调研到既定路线

• 2022 年：随 WasmGC 标准化进程，扩展 Dart 编译工具链以支持编译到 Wasm；
• 2023 年：计划支持 Wasm 目标，并调研多线程渲染、基础应用体积缩减、自定义 shader 性能；
• 2024 年：目标为完成 Dart→WasmGC 编译，随之支持 Flutter Web 应用的 Wasm 编译，并包含一套“同时支持 JS 与 Wasm 编译”的新 JS Interop 机制；性能侧继续做应用瘦身、多线程利用、加载时间优化，并把 CanvasKit 设为默认渲染器、改进文本输入，同时调研 Web SEO 支持选项；
• 2025 年：声明新 JS Interop 已完成，计划移除 legacy HTML/JS 库（并提示参考 breaking change 公告），继续推进 Web 核心（无障碍、文本输入、国际化文本渲染、体积、性能、平台集成）与 Wasm 编译，还计划上线 Web hot reload。

一处值得注意的“反复”：Web hot reload 在 2023 年被列为 Non-goals（理由是 Web 编译器专家全部投入 Wasm 生产支持），2024 年又计划恢复相关工作，2025 年则预期正式推出。这提醒读者：路线图内容会随人力与优先级变化，纵向对照比单看某一年更可靠。

4.3 仓库中的落地证据

• engine/src/flutter/web_sdk 与 engine/src/flutter/wasm、engine/src/flutter/skwasm：Web SDK 与 Wasm/skwasm（Skia/Wasm 相关）目录存在于引擎源码树，对应 Wasm 编译与 Web 渲染目标；
• packages/flutter_web_plugins/lib：Web 平台插件适配层源码；
• packages/flutter_tools/lib/src/web/（如 web_device.dart、bootstrap.dart）：Flutter 工具链中负责 Web 设备发现与启动引导的模块，是 “flutter run -d chrome / 启动 bootstrap” 工作流在工具侧的落点。

---

五、移动平台（Android/iOS）：依赖管理、Cupertino 与系统能力跟进

5.1 iOS：紧跟系统新版本与依赖管理现代化

• 系统跟进：2025 年计划支持当年度的 iOS 19 与 Xcode 17；
• Swift Package Manager（SwiftPM）：2024 年计划以 privacy manifests、SwiftPM 等“最新 Apple 标准”为目标做现代化改造；2025 年明确“完成 SwiftPM 支持”并预期在 2025 年晚些时候将其设为默认依赖管理选项；
• Cupertino：2024—2025 连续两年表示继续精修 Cupertino widget 集（对齐 Apple 人机界面指南 HIG）。

仓库证据：SwiftPM 在工具链中已有完整实现，见 packages/flutter_tools/lib/src/macos/swift_package_manager.dart、packages/flutter_tools/lib/src/macos/swift_packages.dart 以及与其并列的 packages/flutter_tools/lib/src/macos/cocoapods.dart（两条依赖管理路径并存）；packages/flutter_tools/lib/src/features.dart 中定义了 SwiftPackageManager 特性开关（configSetting 名为 enable-switch-package-manager），并附有禁用时的警告文案——这正是“SwiftPM 作为可切换特性逐步默认化”在实现层的体现。Cupertino 组件则集中在 packages/flutter/lib/src/cupertino，覆盖按钮、导航栏、切换、文本选择等 HIG 风格控件。

5.2 Android：Kotlin 化构建脚本与新版系统特性

• 2023 年：计划实现 Android predictive back gesture（预测性返回手势） 与 handwriting input（手写输入） 支持，并推动 camera 插件迁移到最新 CameraX API；
• 2024 年：在 Android 构建文件中引入 Kotlin；
• 2025 年：研究 Android 16 的主要新特性；把 Gradle 构建逻辑从 Groovy 迁移到 Kotlin，并提升构建工具的单元测试覆盖率；同时聚焦 API level 29+ 设备（Impeller 默认化，见第三节）。

5.3 互操作（Interop）：Dart 直调原生语言

这是 2023—2025 年反复出现的关键词，方向高度一致：

• iOS/macOS 侧：实现并完善 Dart 直接调用 Objective-C，继而支持直调 Swift；
• Android 侧：支持 Dart 直调 Java/Kotlin；
• 附加目标：支持调用只能在主 OS/平台线程调用的 API。

仓库中该能力的“前台”形态表现为 engine embedder 层与 flutter_tools 的构建支持；由于互操作能力横跨 engine（如 shell/platform 下的 Darwin/Android embedder）与 dart:ffi 生态，具体 API 形态建议以对应 SDK 发布说明为准。

5.4 混合应用与多视图趋势

• Hybrid/add-to-app：2024 年观察到“大型 Flutter 应用越来越多地从混合应用起步（同时含 Flutter 与原生代码/UI）”，计划从性能/开销与开发者体验两方面改进支持；
• 多视图/多窗口：2023 年支持桌面端 Platform Views（macOS/Windows）与多窗口；2024 年把“多 Flutter view”支持扩展到 Android/iOS，目标是一个 Dart isolate 渲染多个视图，并最终实现“一个 widget 树渲染多个窗口”。

仓库证据：本仓库 examples/multiple_windows 即“多窗口”用法的官方示例（lib 下含多个 window 管理相关实现），可作为研究桌面多窗口渲染的入口。

---

六、桌面平台：生产级目标与 Canonical 的接力

• 2020：目标让同一套 SDK 支撑 Web/macOS/Windows/Android/Fuchsia/iOS，并明确“2020 年不打算提供 Cupertino 的桌面等价物”；
• 2021：承诺交付 Web、macOS、Windows、Linux 的生产级支持，形成六平台同 SDK；桌面侧完成无障碍层并支持多个独立窗口；
• 2022：把桌面支持带到 stable channel——逐个平台推进并宣布，顺序为 Windows → Linux → macOS，配套工作重点是扩充回归测试套件以获得发布信心；
• 2023：macOS/Windows 支持 Platform Views（从而可承载 WebView 等）；Linux 聚焦 GTK4 支持与无障碍；
• 2024：在 macOS/Windows 上推进 Platform Views、Linux 继续 GTK4 与无障碍；跨平台推进“一个 isolate 多视图”，终极目标为“一个 widget 树渲染多窗口”；
• 2025：分工进一步明确——Google 侧聚焦移动与 Web，桌面由 Canonical 的 Flutter 团队持续投入（Windows/macOS/Linux）；2024 年已落地桌面多视图渲染，2025 年 Canonical 计划改进多窗口下的无障碍、键盘、文本输入与焦点，并推进 windowing API。

仓库证据：Linux 桌面端 embedder 代码见 engine/src/flutter/shell/platform/linux（如 fl_engine.cc），Windows 见 engine/src/flutter/shell/platform/windows；同时 dev/ 下存在 devicelab 等桌面测试任务，可进一步佐证“桌面纳入 CI 回归”的工程化方向。

---

七、框架核心与 UI：Material 3、文本、菜单与低啰嗦化

7.1 Material 3 与 Apple 设备适配

• 2022 年：更新 Material 库以支持 Material 3（动机首先是提升与 Android 的保真度，但不限于该平台）；
• 2024 年：预期完成对 Material 3 的全面支持，并调研把核心框架泛化，以更好支持 Apple 设备上的设计期望（如 app bar、tab bar）。

仓库证据：packages/flutter/lib/src/material 下各类组件主题文件（如 button_style.dart、app_bar_theme.dart、list_tile.dart 等）普遍支持 Material 3 相关属性，useMaterial3/M3 主题切换逻辑贯穿整个 material 目录；可结合该目录源码研究 M2/M3 的渐进式迁移机制。

7.2 文本、选择与菜单

• 跨 widget 文本选择（2022 计划）：动机为对齐 Web 平台的保真度，但不限于 Web；
• 文本编辑体验（2022 计划）：提升桌面文本编辑惯例的保真度，并集成 iPadOS 手写识别；
• 菜单体系（2022 计划）：为桌面与 Web 提供右键菜单与菜单栏方案，包括与宿主 OS 集成（对 macOS 尤其相关）。

仓库证据：文本选择与菜单相关实现分散在 packages/flutter/lib/src/widgets（文本/选择/手势）与 packages/flutter/lib/src/cupertino、material 的 context_menu 组件中；Material 菜单组件（menu_anchor 等）在仓库的框架测试（如 packages/flutter/test）中均有覆盖。

7.3 降低样板代码与研究性探索

• 2025 年核心框架方向：调研多项改动以降低 Flutter widget 代码的冗余程度；
• 2020—2021 年即已提出“减少常见目标所需的 boilerplate”“研究迁移工具让破坏性 API 变更更易管理”；
• 早期“long-anticipated”功能（2020 年列示）：router 重构、实例状态保存与恢复、改进的国际化工作流；
• 大数据集组件：2021 年改进 table widgets 并引入 tree widgets；2023 年提出高效 2D 滚动组件（tables/trees）；
• 研究项（多为“experiments/研究”口吻）：自适应布局（先从 Android vs iOS 入手）、把 3D 集成进 Flutter 场景、wide color gamut（广色域，可能先 iOS）、利用新图形后端改进 dart:ui 与 shader 特性。

与文本不同，上述“研究项”是明确标注的调研方向，仓库内对应能力（如 dev/ 下的 wide_gamut 相关测试应用、widget_previews 等）仅表明相关方向已有工程投入，不宜解读为已发布功能。

---

八、Dart 语言与编译链：空安全、宏的“起落”与编译器重构

8.1 Sound Null Safety 与生态迁移（2021）

2021 年将 Dart sound null safety 引入 Flutter，并主导插件/包生态的空安全迁移（含 Flutter 团队自维护包），配套提供迁移工具、样例与文档。

8.2 宏（macros）的完整生命周期：评估 → 放弃

这是档案中最具戏剧性的一条：

• 2022：计划在当年推出一个主要语言特性（“可能是静态元编程”，取决于对语言改进的信心），外加若干小改进（含 import 语法）；
• 2023：启动对 Dart 宏支持可行性的正式评估，若发现不可修复的架构问题则放弃；关键用例是序列化/反序列化、数据类与通用可扩展性；
• 2024：完成评估；若架构不可行则放弃；语言侧转向更增量的特性（primary constructors、import 语法简写、静态检查的协变/variance 支持）；
• 2025：给出结论——在 Dart 中支持宏不可行；转向改进 build_runner 的代码生成能力，并调研改进 Dart 序列化/反序列化的替代方案；计划发布一个或多个正处于语言设计流程中的特性。

仓库证据：Dart 前端服务位于 engine/src/flutter/flutter_frontend_server，体现“前端编译为 flutter run/build 服务”的工程链路；“代码生成主战场仍是 build_runner”这一点与本仓库 dev 下大量使用 build_runner/代码生成的例子（如 flutter_localizations 的 .arb 生成、flutter_tools 中模板与代码生成工具）相互印证。

8.3 编译器与工具重构（2025）

• 重构 Dart analyzer 与前端编译器（front-end），让二者共享更多实现，以加速未来语言特性开发、性能与稳定性；
• 调研 Dart AOT 可执行文件的交叉编译（例如在 macOS 开发机上编译出 Linux AOT 可执行文件）；
• 更早的调研还包括：API 采用 records/patterns、工具链支持 RISC-V、为插件利用新 FFI 特性（2023 年研究项）。

---

九、可访问性、质量与安全：贯穿各年的“隐性主线”

档案中 Accessibility/Quality 条目相对分散但从不缺席：

• 无障碍：多轮强调“无障碍是 Flutter 应用的命脉”，逐年以 bug 修复与小补丁为主推进；2024 年完成了 iOS/Android 若干关键用例的验证，2025 年把重点转向 Web 平台无障碍；2023 年桌面侧配套推进无障碍层。
• 质量问题：2020 年全年修复 17000+ issue，并计划至少维持该影响力；2021 年围绕真实应用改进内存、安装包体积、运行时性能、电量与 jank，并提升内存调试工具；2023 年把“团队速度/技术债”列为最优先，治理 flaky test、清理 issue 积压；2024—2025 年为降低 stable 回归而持续加大测试覆盖。
• 安全/供应链：2023 年推进 SLSA 合规，目标主仓库达到 SLSA-3（次年看向 SLSA-4），并希望把工具链能力外溢到 Flutter 包与应用开发者；2022 年即开始加码供应链安全。

仓库证据：无障碍不仅在文档层面规划，本仓库还设有专门的测试工程 dev/a11y_assessments，其 test 目录内含 accessibility_guideline_test.dart 及针对按钮、菜单、对话框、开关等数十个组件的无障碍用例；自动化测试体系见 dev/automated_tests 等工程，可作为“框架质量防线”的实际样例。

---

十、Tooling 与 AI：编辑器、DevTools 与智能助手

• 长期目标：持续打磨 Flutter DevTools、VS Code、Android Studio/IntelliJ 及 Google IDX，并不断缩短“编辑—刷新”循环、提升整体开发者体验（2022、2025 均有表述）；
• 2023—2025 年连续表态：与 AI 方案集成，为核心编程任务提供 AI 辅助；2024 年计划与 IDX 团队协作并探索与设计工具集成；
• 2022 年开发者体验大项还包括：更好的错误信息、新 lint、API 文档、更有用的样例、Dart→JS 场景下的栈追踪改进等。

仓库证据：packages/flutter_tools/lib（含 analyze 相关、migrations、features 等模块）是这些开发者体验能力的实现主体，例如 packages/flutter_tools/lib/src/features.dart 中集中管理各实验特性开关，可看到工具侧“以 feature flag 灰度新能力”的工程模式。

---

十一、发布节奏与通道策略

• 通道体系：master/beta/stable 三个通道（稳定性递增、变更传播时间递增）。2021 年档案同时记录了曾在 master 与 beta 之间的 dev 通道于 2021 年底退役；
• 节奏：各年基本一致地规划 约每月一个 beta、每年四个 stable（2021—2025 均为 4 stable + 12 beta 的体量）；2023 年起倾向于“新特性到达 beta 通道即官宣”，不再等待 stable，并鼓励追求更快更新节奏的用户使用 beta；
• 质量投入：2025 年为提升发布可预期性与规律性、降低 stable 回归，计划追加测试覆盖，并增强 hotfix/patch 快速发布能力。

仓库证据：发布治理相关的现存文档位于 docs/releases/，如 Release-versioning.md（版本策略）、Hotfix-Documentation-Best-Practices.md（热修复流程）、Flutter-Cherrypick-Process.md（cherry-pick 流程），可与路线图对照阅读。

---

十二、官方 Non-goals：一份值得认真对待的“不做清单”

档案每年都单列 Non-goals，且数年高度一致：

• 不内置 code push / hot update（2022—2025 均如此）：如需代码热更新，官方反复指向第三方 shorebird.dev 的产品；如需“UI 推送/服务端驱动 UI”，官方推荐 rfw 包；
• 不增加新的官方支持平台（2025）；
• 2023 年明确不内置：wearables（Apple Watch、Android Wear）、automotive 集成、Web 内置 SEO 方案、homebrew 安装方式，并坦言“部分方向已有优秀第三方包”；
• 2023 年曾把 Web hot reload 暂时搁置（人力集中于 Wasm），是 Non-goals 中少数随后“复活”的条目（见第四节）。

档案还给出一个极具洞察的自我观察：当团队按 Thumbs-Up 排序解决完所有“技术上可行”的高赞 issue 后，剩下的最高赞 issue 恰好全是“不可行或难以根治”的——这解释了为什么 Non-goals 列表常与 Top 高赞 issue 重合。该论述与 docs/contributing/issue_hygiene/Popular-issues.md 对 Top-10 issue 的分析互为参照。

---

十三、结语：如何用好这份历史档案

从六年档案可以提炼出几条对开发者与研究者的实用启示：

1. 路线图是“意图声明”而非承诺。Impeller、SwiftPM、Web hot reload 等条目的起落与反复表明，规划会随人力分配与外部环境调整，引用时务必标注年份语境；
2. 纵向追踪比单年阅读更有价值。本仓库同时保留 当前路线图 与本文档案，将“当年计划”与“当前仓库实际代码”（如 engine/src/flutter/impeller、packages/flutter_tools/lib/src/macos/swift_package_manager.dart、packages/flutter/lib/src/cupertino 等）比对，即可快速判断一条技术主线的兑现进度；
3. Non-goals 是同样重要的信号。官方明确“不做什么”能帮你把社区方案（如 code push、服务器驱动 UI、桌面窗口扩展等）与官方边界快速切分，减少无效的 feature 诉求。

对于希望深入下一步的读者，仓库内可继续阅读：官方贡献与 issue 治理说明 docs/contributing/issue_hygiene/README.md、发布流程文档 docs/releases/、以及各主题的实现源码（渲染见 engine/src/flutter/impeller 与 engine/src/flutter/display_list，Web 见 engine/src/flutter/web_sdk 与 packages/flutter_web_plugins，多窗口见 examples/multiple_windows）。鉴于本仓库为只读快照，查看与本地运行示例请遵循各示例目录内 README 的说明，分析源码时请以仓库内实际文件为准。