Windows Terminal v1.0 路线图全解析：里程碑节奏、交付计划与源码中的 v1.0 核心场景

本文以仓库内的 v1.0 路线图文档（doc/terminal-v1-roadmap.md）为主体，完整还原 Windows Terminal 从 2019 年开源到 v1.0 发布的全部时间线、4 周里程碑交付节奏、Issue 分级机制，以及 v1.0 承诺的核心场景清单；并结合当前仓库源码（渲染引擎、分屏、可托管终端控件、UIA 无障碍、JSON 配置模式等），逐条印证这些路线图目标在实现层面是如何落地的。读完本文，你可以掌握该项目的版本交付方法论，并理解每个 v1.0 关键特性在代码库中对应的具体模块与文件位置。

一、路线图总览：面向 2020 年春天的 v1.0

路线图开篇即给出总体目标：计划在 2019 年 12 月达成 Terminal v1.0 功能完备（feature-complete），并在 2020 年 4 月正式宣告 v1.0（文档原文表述为"by spring 2020"）。文档特别强调了一条关键定位：

⚠️ 注意：Terminal v1.0 是一个以质量为导向、在很大程度上由社区驱动的发布。所以，如果你看到 Bug，请发现/提交它们！

这说明 v1.0 阶段的社区参与（报 Bug、验证质量）本身是路线图计划的一部分，而非可选项。

二、4 周里程碑交付模型

Windows Terminal 以 4 周一个里程碑的节奏工程化交付，每一轮内部固定划分为三个阶段：

时长	活动	产出
2 周	开发工作（Dev Work）：面向未来 Windows 版本的修复/特性、面向 Windows Terminal 的修复/特性	第 2 周末向内部自托管者（Internal Selfhosters）发布
1 周	质量与稳定性：Bug 修复、性能与稳定性、UI 打磨、测试等	第 3 周末推送至 Microsoft Store
1 周	发布（Release）：第 4 周周二从 Microsoft Store 与 GitHub Releases 发布；发布 Release Notes 与公告博客；工程系统维护；社区互动；文档；规划下一里程碑	新版本可从 Microsoft Store 与 GitHub Releases 获取

这个三段式节奏（开发 → 质量 → 发布）在仓库的构建与测试体系中可以得到印证：仓库提供了完整的自动化测试脚本与配置，例如 src/host/runft.bat、src/host/runut.bat、tools/runft.cmd、tools/runut.cmd 与 tools/tests.xml，支撑每个里程碑周期中"质量与稳定性"阶段的回归测试。

三、完整时间线：从开源公告到 v1.0

路线图给出的主时间线如下（保留原文档全部条目）：

里程碑截止日期	里程碑名称	关键交付物
2019-05-07	Announcement（公告）	Terminal 发布并开源（Build 2019 Terminal 主题演讲、"Sizzle" 宣传视频）
2019-07-09	v0.2（update）	首个通过 Microsoft Store 发布的 Terminal 版本，基础特性就位：基础标签页控制、基础 UI 布局、JSON 配置文件与设置
2019-08-02	v0.3	重大 UI 改进、改进的标签栏布局与配色、基础无障碍（a11y）支持、Azure Cloud Shell 连接
2019-08-27	v0.4	HTML 复制、标签页标题、双击/三击选择、本地设置（Local Settings）、JSON 设置校验、无障碍改进
2019-09-24	1909	稳定性与质量改进；随包安装 Cascadia Code 字体；为 profiles.json 设置文件加入 JSON Schema，使 VSCode 等编辑器可提供 IntelliSense 补全
2019-10-22	1910	级联设置（Cascading Settings）、动态配置文件（Dynamic Profiles）
2019-11-19	1911	v1.0 的最后特性开发窗口
2019-12-17	1912	"Feature Complete"——全部 v1.0 特性就位
冬季假期	N/A	无计划内工作
2020-01-28	Beta 1	Pri 0/1/2 Bug 修复与打磨
2020-02-25	Beta 2	Pri 0/1 Bug 修复与打磨
2020-03-24	RC	仅 Pri 0 Bug 修复
2020-05	v1.0	Terminal v1.0 正式发布

可以看到一条清晰的收敛曲线：从 1909 到 1912 三个月内按主题（稳定性 → 特性冻结 → 最后特性收尾）推进，随后 Beta 1/Beta 2/RC 三个质量里程碑中允许修复的缺陷优先级逐级收窄（0/1/2 → 0/1 → 仅 0），是典型的发布前缺陷收敛（defect convergence）策略。

时间线上还体现了与操作系统版本节奏的耦合：1909/1910/1911/1912 这些里程碑名直接沿用 Windows 10 的版本号，与"面向未来 Windows 版本"的并行开发工作相互呼应。

四、GitHub Milestone 映射机制

路线图中每一个时间线里程碑都映射到 GitHub 项目管理的 Milestone 上：

Milestone	说明
Terminal-1909	规划在 1909 的工作
Terminal-1910	规划在 1910 的工作
Terminal-1911	规划在 1911 的工作
Terminal-1912	规划在 1912 的工作
Future Milestones	即将设立
Terminal v1.0	规划为 v1.0 但尚未分配到具体里程碑的工作
Terminal Backlog	尚未分配到任何里程碑或发布的工作

这套两级结构（按 OS 版本排期 + 按发布目标兜底 + 全局 Backlog）保证任何需求都不会"无处安放"，也与下一节的分级流程形成闭环。

五、Issue 分诊与优先级（P0/P1/P2）

路线图定义了明确的 Issue 分诊策略：新进入的 Issue/需求每周分诊数次，打上标签并按优先级分配到里程碑：

• P0（严重崩溃、数据丢失等）：立即安排处理，尽快解决；
• P1/P2 的 Issue/特性/诉求：分配到当前或未来的里程碑；如果该特性是交付 v1.0 所必需的，则挂到 "Terminal v1.0" 里程碑等待后续分配；
• 不属于 v1.0 特性清单 的 Issue/特性/诉求：统一进入 "Terminal Backlog" 里程碑，留待后续分诊、排序与排期。

文档还注明：v1.0 之外有大量特性会被重新评估并排入 v2.0，其规划文档计划在 2020 年初发布（当前仓库中确实存在后续路线图文档 doc/terminal-v2-roadmap.md，与这一规划相衔接）。

六、v1.0 场景清单（完整继承并逐条剖析）

路线图的核心是一张 v1.0 场景（Scenarios）表，按优先级分为三档：

• 0 —— Mandatory（必须交付）
• 1 —— Optimal（应当交付，最优项）
• 2 —— Optional / Stretch-goal（可选/挑战目标）

下表完整继承原文档全部 17 个场景，并结合当前仓库源码补充了每项在代码库中的对应落点（均可按相对路径自行查证）：

优先级	场景	描述/备注（原文）	源码佐证
0	Performance & Efficiency（性能与效率）	Terminal 必须快速高效，尽可能消除输入延迟；内存高效，避免不必要的依赖以最小化内存占用与磁盘足迹	见下文"渲染引擎"小节的 atlas 引擎：自定义 GPU 字形缓存即为此服务
0	Reliability（可靠性）	尽一切合理努力确保 Terminal 不会意外崩溃；崩溃问题默认按 Pri-0 优先处理	仓库内置大量测试基建：src/host/ft_host、src/host/ut_host、src/til/ut_til 等
0	Code Reuse（代码复用）	Terminal 核心引擎在可行处复用/共享 Windows Console 内部组件，最小化两者的支持与维护成本	从源码结构看，src/cascadia（Terminal 应用层）与 src/terminal（parser/adapter）、src/types（含 src/types/colorTable.cpp、src/types/convert.cpp）等公共模块被 conhost 与 Terminal 共用，正是此条的工程体现
0	Terminal Reuse（终端可托管性）	Terminal 核心应可托管为 UWP（以及可能的 WPF）Control，让应用可以内嵌一个高质量终端控件，满足客户与合作伙伴长期诉求	src/cascadia/TerminalControl/TermControl.cpp（XAML/UWP 控件）与 src/cascadia/WpfTerminalControl（WPF 封装）直接对应此场景；src/cascadia/TerminalControl/HwndTerminal.cpp 则展示了 HWND 托管形态
0	Rich, modern text renderer（富现代文本渲染器）	必须渲染东亚、中东语言字形（中文、希伯来文、阿拉伯文等）以及 Emoji（越来越多编程语言支持在方法与变量名中使用 Emoji）；需要 DirectWrite 布局与渲染系统，支持字体回退（font fallback）、可定制文本布局、GPU 加速渲染等内置控制台当时不支持的能力	src/renderer/atlas/ 即 DirectWrite 基于的 GPU 加速渲染器，架构说明见 src/renderer/atlas/README.md
0	Solid Unicode & UTF-8 support（扎实的 Unicode 与 UTF-8 支持）	必须能存储 UTF-16/UCS-2 与 UTF-8 编码的数据（含代理对 surrogate pairs）；v1.0 尚不支持无法用单个 codepoint 表示的组合字符或 grapheme cluster，留待后续版本	宽字符宽度检测与覆盖表见 src/types/CodepointWidthDetector.cpp 及 src/types/unicode_width_overrides.xml
0	International text rendering（国际化文本渲染）	支持几乎所有拥有等宽字体的语言的文本渲染（含东亚语言）；RTL 语言/书写系统为加分项	与"富现代文本渲染器"同一套 DirectWrite + 字体回退体系；仓库自带字体 res/fonts/CascadiaMono.ttf 等（路线图 1909 里程碑提到随包安装 Cascadia Code）
0	Multiple instances（多实例）	用户必须能启动多个相互独立的 Terminal 实例，以便并行/独立运行工具	多窗口/多实例逻辑集中于 src/cascadia/TerminalApp/AppLogic.cpp 与 src/cascadia/TerminalApp/TerminalPage.cpp；命令行参数（含多窗口行为）解析见 src/cascadia/TerminalApp/AppCommandlineArgs.cpp
0	Elevation（提权）	可按需以管理员权限启动 Terminal，执行影响全机器状态的操作	提权相关的命令行与进程模型处理见 src/cascadia/TerminalApp/AppCommandlineArgs.cpp，其规格讨论亦见 [doc/specs/#5000 - Process Model 2.0/](https://gitcode.com/GitHub_Trending/term/terminal/blob/20588130d8ef2ba40eb56bdae88e04cce7fc5b5d/doc/specs/?utm_source=gitcode_repo_files#5000 - Process Model 2.0)
0	Multiple Tabs per instance（每实例多标签页）	每个 Terminal 实例必须支持一个或多个独立标签页——社区第一诉求	标签页与内容组织见 src/cascadia/TerminalApp/Tabs（TerminalPage/TerminalTab）与 src/cascadia/TerminalApp/ContentManager.cpp
0	Configurability & Customization（可配置性与定制）	现代化的灵活设置机制，持久化到用户 AppData（或可经 OneDrive 跨机同步）下的 JSON 文件；v1.0 中没有设置 UI（设置 UI 属后续版本特性）	JSON 配置校验依赖 doc/cascadia/profiles.schema.json（1909 里程碑引入，用于 VSCode IntelliSense）；级联/默认值见 src/cascadia/TerminalSettingsModel/defaults.json；后续的设置 UI（TerminalSettingsEditor）正是"未来版本特性"的落地：src/cascadia/TerminalSettingsEditor
0	Accessibility (A11y)（无障碍）	Terminal 必须高度可访问、包容：通过 UIA 暴露内容以支持 Windows Narrator、UI 自动化工具（含 WinAppDriver）	控件层自动化实现：src/cascadia/TerminalControl/TermControlAutomationPeer.cpp、src/cascadia/TerminalControl/HwndTerminalAutomationPeer.cpp；文本范围抽象：src/types/UiaTextRangeBase.cpp、src/types/TermControlUiaProvider.cpp；仓库内置 WinAppDriver 依赖目录 dep/WinAppDriver 与 UIA 测试工程 src/cascadia/WindowsTerminal_UIATests
1	Color Theming & Styling（颜色主题与样式）	遵循用户的 Windows 深色/浅色主题及强调色设置；背景/文字颜色高度可配置，并可经设置文件导入/导出	主题处理见 src/cascadia/TerminalSettingsModel/Theme.cpp；外观配置模型 src/cascadia/TerminalSettingsModel/AppearanceConfig.cpp
1	Background transparency（背景透明）	对许多命令行用户很有价值；可选支持透明背景，但文本内容本身保持不透明（区别于 Windows Console 因 GDI 限制导致整体变透明的做法）	渲染后端对透明/背景位图的处理见 src/renderer/atlas/BackendD3D.cpp（_drawBackground/_recreateBackgroundColorBitmap 流程，见 src/renderer/atlas/README.md）
1	Fluent "Acrylic" blurred backgrounds（亚克力毛玻璃）	完全透明可能分神，部分用户希望类似 Fluent Acrylic 的模糊半透明背景	从源码结构看，亚克力/模糊效果相关实现在应用窗口层（src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp 等窗口处理代码中可见 Acrylic 相关字样）
1	Customizable Key Bindings（可定制键位绑定）	提供让用户自定义键位绑定的方式，把特定按键和弦（chord）映射到特定 Terminal 操作	键位绑定解析见 src/cascadia/TerminalControl/KeyChord.cpp 与 src/cascadia/TerminalApp/AppKeyBindings.cpp；键名/修饰键的合法格式甚至固化在 JSON Schema 的 KeyChordSegment 模式校验里（doc/cascadia/profiles.schema.json 第 6-9 行）
1	Mouse Support（鼠标支持）	支持鼠标输入，把鼠标移动与操作传递给命令行应用程序	终端控件的交互（鼠标/滚轮）入口见 src/cascadia/TerminalControl/ControlInteractivity.cpp 与 src/cascadia/TerminalControl/IMouseWheelListener.idl
2	Azure Cloud Shell	允许用户注册 Azure 账户/订阅，Terminal 自动枚举并配置到用户 Cloud Shell 的连接	对应 v0.3 里程碑"Azure Cloud Shell connection"的交付；连接层实现在 src/cascadia/TerminalConnection
2	Multiple panes（多窗格）	开发者常需同屏查看多个文件/日志；Terminal 应支持把"页面"拆分为"窗格"，各自运行独立的命令/Shell，类似 *NIX/macOS 上的 tmux	分屏动作处理见 src/cascadia/TerminalApp/AppActionHandlers.cpp 的 _HandleSplitPane（约第 268 行，支持 Automatic/水平/垂直方向与 0.5f 初始比例），命令行 wt split-pane 子命令解析见 src/cascadia/TerminalApp/AppCommandlineArgs.cpp 的 _buildSplitPaneParser；相关规格文档 [doc/specs/#532 - Panes and Split Windows.md](https://gitcode.com/GitHub_Trending/term/terminal/blob/20588130d8ef2ba40eb56bdae88e04cce7fc5b5d/doc/specs/?utm_source=gitcode_repo_files#532 - Panes and Split Windows.md) 与 [doc/specs/#2871 - Pane Navigation/](https://gitcode.com/GitHub_Trending/term/terminal/blob/20588130d8ef2ba40eb56bdae88e04cce7fc5b5d/doc/specs/?utm_source=gitcode_repo_files#2871 - Pane Navigation)

Windows Terminal 的窗格（Panes）布局：把单个页面拆分为多个窗格，各自运行独立 Shell——即路线图中 Pri-2 场景 "Multiple panes" 的产品形态。

七、源码纵深：v1.0 三大"必须项"的工程实现

上述表格中，有三项 Mandatory 场景的仓库证据值得单独展开，它们是理解 v1.0 技术底座的关键。

7.1 富现代文本渲染器：atlas 引擎

路线图要求"DirectWrite 布局与渲染、字体回退、可定制文本布局、GPU 加速"，对应实现位于 src/renderer/atlas/。根据 src/renderer/atlas/README.md 的架构说明：

• Renderer（基类层）把文本缓冲拆解为 GDI 风格的图形原语，经 RenderEngineBase 分发到具体引擎；
• AtlasEngine 负责把这些原语进一步转化为 DWRITE_GLYPH_RUN，并拥有两个后端：
  • BackendD2D.cpp——纯 Direct2D 文本渲染器，面向低延迟远程桌面与老机器/无 GPU 场景；
  • BackendD3D.cpp——自研的高性能文本渲染器，带独立 GPU 字形缓存（glyph atlas）。

BackendD3D 的渲染主流程按序执行 _handleSettingsUpdate → _drawBackground → _drawCursorPart1/2 → _drawText → _drawSelection。其中 _drawText 对每一行、每一字体面、每一字形做"字体/字形对的缓存哈希表查找（_glyphAtlasMap）→ _appendQuad 排队 → 缓存缺失时 _drawGlyph 现渲染"的处理；缓存满时还会 _flushQuads 提交当前画面、重建 GPU 实例缓冲并视情况扩容字形贴图。这一整套机制正是"输入延迟尽可能消除、内存高效"（Performance & Efficiency 场景）的具体工程手段。该 README 还坦率指出现有"拆成 GDI 原语再重建 DirectWrite 结构"的做法"颇为浪费且极易出 Bug"，说明路线图的质量目标也体现在持续的内部重构上。

7.2 可托管终端控件：从 UWP 到 WPF/HWND

"Terminal Reuse"场景在当前仓库中呈现为三个形态并存的控件层：

• UWP/XAML 控件：src/cascadia/TerminalControl/TermControl.cpp（配合 TermControl.idl），是 Terminal 应用自身的核心 UI 单元；
• WPF 封装：src/cascadia/WpfTerminalControl（C# 封装，含 .xaml 示例），直接回应路线图中"perhaps WPF"的表述；
• HWND 托管：src/cascadia/TerminalControl/HwndTerminal.cpp，把终端内容嵌入传统 Win32 HWND。

此外，src/cascadia/TerminalCore 提供与具体 UI 框架解耦的核心逻辑，从目录结构看（TerminalCore + 各 UI 壳分别成库），这正是"复用 Console 组件、降低维护成本"（Code Reuse）在架构上的投影。

7.3 无障碍（UIA）暴露

v1.0 对 A11y 的要求是"通过 UIA 暴露内容，支持 Narrator 与 WinAppDriver"。仓库中这条链路完整可见：控件层自动化对等体（src/cascadia/TerminalControl/TermControlAutomationPeer.cpp、src/cascadia/TerminalControl/InteractivityAutomationPeer.cpp）→ 类型层文本范围抽象（src/types/UiaTextRangeBase.cpp、src/types/TermControlUiaTextRange.cpp）→ 渲染层 UIA 提供者（src/renderer/uia/）→ 测试（src/cascadia/WindowsTerminal_UIATests、src/host/ft_uia）。同时 dep/WinAppDriver 目录内置了 WinAppDriver 运行时依赖，与路线图"包括 WinAppDriver 的 UI 自动化工具"的表述直接对应。

八、v1.0 之后的伏笔

路线图还留下几条值得注意的"边界声明"，它们划定了 v1.0 的能力上限并指明了后续方向：

1. 无设置 UI："There will be no settings UI in Terminal v1 - this is a feature for a future Terminal release." 当前仓库中 src/cascadia/TerminalSettingsEditor（含 GlobalAppearance、Profile 视图模型等）即为该"未来特性"的实现；
2. 组合字符/grapheme cluster 不在 v1.0 范围（Unicode 场景条目中的 Note），留待后续版本；
3. v2.0 规划：未列入 v1.0 的"很多其他特性"将在 v2.0 重新评估与排期，规划文档计划于 2020 年初发布——仓库中 doc/terminal-v2-roadmap.md 即为承接该承诺的文档；
4. 配置校验前置：1909 里程碑为 profiles.json 引入的 JSON Schema（现位于 doc/cascadia/profiles.schema.json）使 VSCode 等编辑器具备 IntelliSense，其内定义的 KeyChordSegment、Color、BellStyle、DynamicProfileSource 等模式，是"可配置性与定制"场景在机器可读层面的固化。

九、小结：这份路线图的方法论价值

综合来看，doc/terminal-v1-roadmap.md 提供了一套可复用的产品交付方法：

• 固定节奏：2 周开发 + 1 周质量 + 1 周发布的 4 周循环，每轮都有明确对外产出（内部自托管版 → Store → 正式发布）；
• 缺陷收敛曲线：Beta 1 → Beta 2 → RC 逐次收窄允许修复的优先级（0/1/2 → 0/1 → 0）；
• 需求全量落位：P0 立即处理、P1/P2 挂当前/未来里程碑、其余进 Backlog，任何需求都有归属；
• 场景驱动：用 17 个带优先级的用户场景（而非抽象特性）定义"v1.0 是什么"，且当前仓库源码（atlas 渲染器、多形态托管控件、UIA 链路、分屏与键位绑定、JSON Schema）可以逐条对应验证。

对读者而言，这份路线图与其说是一份历史记录，不如说是一张"特性 → 源码"的索引图：想理解 Windows Terminal 某个核心能力的工程实现，先从本文第六节的场景表定位到对应模块目录，再深入具体文件，是一条高效路径。