Windows Terminal 2023 路线图季度发布节奏、Preview 到 Stable 的演进机制与 1.19 特性落地【免费下载链接】terminalThe new Windows Terminal and the original Windows console host, all in the same place!项目地址: https://gitcode.com/GitHub_Trending/term/terminal本文基于 Windows Terminal 仓库中的 Terminal 2023 Roadmap 展开完整梳理 2023 年 Windows Terminal 的季度发布节奏、Preview 与 Stable 双通道流转规则以及 1.19 里程碑中六大特性Canary 构建、Terminal AI、Suggestions UI、cmd.exe Unicode 输入、性能改进与 Broadcast Input 广播输入各自的规划意图与在仓库源码中的落点帮助读者理解该项目的发布工程方法论并学会通过特性开关文件自行验证某个实验特性处于哪个发布阶段。一、文档定位从 2022 到 2023 的规划演进2023 年路线图doc/roadmap-2023.md是 2022 年路线图 的继任文档用于反映规划方式的变化。回顾 2022 年文档可以看到团队当时放弃了最初设想的“Terminal v2”大版本目标转而采用持续增量更新的方式“在过去 18 个月里团队已经清楚我们并不需要一个严格的 2.0 版本。通过持续、增量的更新我们依然可以很好地服务社区。如果未来某个版本值得 2.0 的名号我们届时再重新评估。” —— doc/roadmap-2022.md2022 年的里程碑管理采用与内部截止日期对齐的“学期”22H1 / 22H2划分并配套一套 Issue 分级机制P0严重崩溃、数据丢失等排入当前发布里程碑尽快处理P1通常排入当前或下一个发布里程碑P2 / P3通常排入当年第二个学期需要随 Windows 操作系统一同合入的无障碍与 Console 问题排入当前学期与现有学期无关的需求进入 Backlog 等待后续分级与排期。2023 年路线图在此基础上进一步简化为大约每季度一次的发布周期这是理解本文后续所有内容的基线。二、发布节奏季度化与 Preview/Stable 双通道2.1 2023 年发布时间表路线图给出的 2023 年季度发布计划如下时间表原文标注为粗略估计而非硬性规则例如 1.18 的发布曾为配合 Build 2023 而略有推迟季度日期发布版本状态说明CY23 Q12023-01-24Terminal 1.17已发布PreviewCY23 Q22023-05-23Terminal 1.18已发布PreviewCY23 Q32023 年 9 月下旬目标Terminal 1.19规划中CY23 Q42024 年 1 月初预期Terminal 1.20规划中2.2 单个里程碑内部的时间分配路线图使用 Mermaid 甘特图描述了一个典型里程碑以 1.18/1.19 为例的时间切分其中每个里程碑的最后一个月被保留为 “bake time”用于打磨 bugfix、稳定main分支期间通常会放缓对社区 PR 的合入速度。原文档明确注明该图为 “informative, not normative”仅供参考非规范性约束从甘特图可以看出一个季度的典型节奏特性开发约 10 周 → 修复期约 4 周 → 锁定烘焙期 2 周 → 发布随后该 Preview 版本晋升为 Stable 版本。2.3 Preview 先行Stable 滞后一个版本新特性的流转规则是理解 Windows Terminal 版本能力的核心新特性先进入Windows Terminal Preview通道通常在 Preview 中出现一个版本之后特性才会进入Windows TerminalStable通道对于风险较高或实验性的特性团队可能让其在 Preview 通道中停留更长时间甚至长期仅存在于 Preview/Canary 构建。路线图脚注指出一份关于哪些特性处于何种实验状态的具体清单可以从 src/features.xml 中查到并特别说明该文件是“用于点亮代码库特定部分的原始 XML 文档并非为人类阅读而撰写”。下一节将展开说明这套机制。三、特性分阶段机制从 features.xml 到编译期开关脚注提到的 src/features.xml 是 Windows Terminal 特性分阶段feature staging的单一事实来源。其工作机制在 doc/feature_flags.md 中有完整说明构建期由 tools/Generate-FeatureStagingHeader.ps1 解析该 XML 并生成编译期头文件。3.1 XML 结构要素每个feature节点包含以下关键元素元素作用name特性名如Feature_ShellCompletions将生成Feature_XYZ::IsEnabled()接口与TIL_FEATURE_XYZ_ENABLED预处理宏description特性说明id关联的 GitHub deliverableissue/PR编号可选stage默认状态AlwaysEnabled或AlwaysDisabledalwaysDisabledBranchTokens/alwaysEnabledBranchTokens按分支通配符禁用/启用特性alwaysDisabledBrandingTokens/alwaysEnabledBrandingTokens按品牌Branding禁用/启用特性合法取值为Dev、Preview、Release、WindowsInboxalwaysDisabledReleaseTokens /空标签表示该特性在 Release 构建中无条件禁用优先级最高判定优先级从高到低为alwaysDisabledReleaseTokens→ 启用分支 → 禁用分支匹配的分支 token 越长优先级越高→ 启用品牌 → 禁用品牌 → 特性默认状态。生成脚本 tools/Generate-FeatureStagingHeader.ps1 支持通过-Branding参数在Dev、Canary、Preview、Release、WindowsInbox五种品牌中选择构建目标——这里可以清楚看到Canary 与 Dev、Preview、Release、WindowsInbox 并列为一等构建品牌这正是路线图所述“Canary builds”在构建体系中的落点。3.2 用特性开关验证 1.19 特性的发布阶段当前仓库版本的 src/features.xml 内容与路线图高度呼应可以拿几个 1.19 特性逐一对照Shell 补全 / Suggestions UIFeature_ShellCompletionsid3121/id对应路线图中的 [#3121]描述为“一个供客户端应用请求终端显示建议列表的实验性转义序列”stage为AlwaysEnabled且带alwaysDisabledReleaseTokens——即默认对所有品牌启用但无条件从 ReleaseStable构建中编译排除。这精确对应了“新特性先进 Preview、滞后一版再进 Stable”的流转规则。非终端面板实验Feature_ScratchpadPaneid 997与Feature_MarkdownPaneid 16495均为AlwaysDisabled仅在Dev与Canary品牌下启用——这正是路线图所说“实验性特性可能只在 Canary/Preview 中长期存在”的实际案例。面向 Windows 系统自带版本WindowsInbox的裁剪大量特性带alwaysDisabledBrandingTokensbrandingTokenWindowsInbox/brandingToken/alwaysDisabledBrandingTokens例如Feature_ReceiveIncomingHandoffOpenConsole 接收连接、Feature_AdjustIndistinguishableText前景色自动调整、Feature_ScrollbarMarks滚动条标记等。这说明同一份main代码库同时支撑独立商店版 Terminal 与随 Windows 系统分发的 conhost二者通过品牌 token 精细地区分特性面。因此读者在仓库中判断“某实验特性当前处于哪个阶段”时只需三步找到src/features.xml中对应特性节点 → 查看stage与各 token 配置 → 结合优先级规则推断其在 Dev / Canary / Preview / Release / WindowsInbox 五个品牌下的启停状态。四、Terminal 1.19 特性清单与仓库落点路线图列出的 1.19 特性共六项下面逐项说明其规划意图并标注仓库中可查证的相关位置。4.1 Canary builds来自 main 的每日构建“Canary builds。来自main的 Terminal 每日构建。更不稳定但能更快获得实验特性。”Canary 是比 Preview 更前置的通道。从源码结构看Canary 构建由仓库中的 CI 管道支持build/pipelines/ob-nightly.yml 等夜间构建流水线中配置了environment: production-canary部署环境且如前文所述Canary是特性开关生成脚本认可的一等品牌。结合Feature_ScratchpadPane、Feature_MarkdownPane等仅在Dev/Canary下启用的特性可以推断团队将 Canary 定位为实验特性的第一落地通道先在 Canary 上积累稳定性证据再进入 Preview最终按双通道规则进入 Stable。注意区分术语仓库中 src/host/ft_host/CanaryTests.cpp 的 “Canary” 指的是“金丝雀测试”——验证控制台激活仍能正常启动 cmd.exe 的简单启动测试与 Canary 构建通道是同一词的两层含义不要混淆。4.2 Terminal AI仅随 Canary 发布的 v0“Terminal AI。虽然它最初只会随 Canary 构建发布但 v0 实现大约会与 1.19 同时可用。”这是六项特性中发布限制最严格的一项路线图明确其 v0 只进入 Canary 构建。结合 3.2 节介绍的 staging 机制这类特性的典型形态就是AlwaysDisabled 仅Canary/Dev品牌启用的特性开关或干脆处于独立实验分支。路线图中还前瞻性地指出Suggestions UI “可能也是 Terminal AI 未来的基础”——这与 3.2 节中Feature_ShellCompletions作为通用建议展示通道的定位相吻合。4.3 Suggestions UI补全、任务与 AI 的统一入口“Suggestions UI。这是 shell 补全#3121、任务#1595以及未来可能 Terminal AI 的起点。”Suggestions UI 的完整设计规格位于 doc/specs/#1595 - Suggestions UI/Suggestions-UI.md其核心思想是终端内出现一处临时的、类 Intellisense 的 UI在文本插入点附近展示建议列表统一承载多类建议来源shell integration 驱动的历史命令、最近目录、shell 自身的补全结果、settings 中sendInput动作定义的任务tasks、基于缓冲区词汇的 Buffer Completions以及未来扩展extensions提供的来源形态上区分带过滤文本框的“palette”与纯列表的“menu”两种模式客户端应用可以通过新的 VT 转义序列主动唤起该 UI——对应src/features.xml中Feature_ShellCompletions的描述“An experimental escape sequence for client applications to request the Terminal display a list of suggestions”。规格文档按 Crawl / Walk / Run / Sprint 四级划分用户故事从“shell integration 提供最近命令”逐步演进到“扩展可以提供建议来源”与“内联inline模式”。这为路线图“Suggestions UI 是起点”的判断提供了依据它先服务补全场景再承载任务场景最终为 Terminal AI 的输出展示铺路。4.4 cmd.exe 的 Unicode 输入cooked reads“cmd.exe以及任何使用 cooked reads 的 console 应用的 Unicode 输入。见 #15567。”这条针对的是原始 Windows Console 一侧的能力使用“cooked”有状态行编辑方式读取输入的 console 应用cmd.exe是典型代表获得 Unicode 输入支持。从源码结构看cooked 读取路径的实现位于 src/host/readDataCooked.cpp配套头文件 src/host/readDataCooked.hpp该改动发生在 conhostconsole host侧而非 XAML 版的 Terminal 前端这也是路线图把“cmd.exe 的 Unicode 输入”与“Conhost 性能改进”放在同一版本的原因——二者都属于同一套 console host 代码库内的工程。4.5 其他性能改进Conhost 显著提速“其他性能改进。Conhost 现在应该快很多了。”这是对 1.19 中 console hostconhost即随 Windows 系统分发、负责所有传统控制台窗口的组件性能工程的总体描述。路线图未逐项列出具体优化点其收益主要惠及传统 console 应用与 Windows 系统自带终端体验而非仅商店版 Windows Terminal。4.6 Broadcast Input 广播输入模式“Broadcast input mode用于同时向多个 pane 发送文本。”Broadcast Input 的设计规格保存在 doc/specs/drafts/#2634 - Broadcast Input/#2634 - Broadcast Input.md。该规格借鉴 iTerm2 的成熟实现让用户能把同一份键盘输入同时发送到多个标签页/窗格从而在多个目录或多台服务器上执行相同命令。规格中比较了三种设计提案iTerm2 式模态广播、广播集合、以及二者的改良混合核心动作模型统一为{ action: toggleBroadcastInput, scope: window }, { action: toggleBroadcastInput, scope: tab }, { action: toggleBroadcastInput, scope: pane }, { action: disableBroadcastInput }其中scope决定广播粒度window级为“所有标签的所有窗格”tab级为“当前标签的所有窗格”pane级为“把当前窗格加入/移出广播集合”。规格还规划了视觉指示方案在被广播的标签/窗格上显示网络塔图标并考虑用强调色变体SystemAccentColorLight*/SystemAccentColorDark*高亮广播目标窗格的边框同时预留了跨窗口广播需与 Monarch 单实例架构协调、广播分组scope: tab, group: 1、将广播状态暴露给像素着色器等后续扩展方向。在仓库代码侧可以验证该特性已经落进默认设置src/cascadia/TerminalSettingsModel/defaults.json 中登记了命令toggleBroadcastInputid 为Terminal.ToggleBroadcastInput说明广播输入已作为一等 keybinding 命令进入 Terminal 的动作体系用户可将其绑定到任意按键。五、North Stars路线图之外的团队长期目标路线图还专门留了一节指向团队每位成员的“North Stars”北极星清单那是一份更灵活、更长期的个人目标列表列出了团队各成员正在推进的方向但不属于已承诺交付的工作。理解这一点有助于区分三类文档的信息性质路线图roadmap-2023.md季度节奏 已承诺进入某版本的核心特性时间线仅供参考informative, not normative规格文档doc/specs/ 下各 issue 规格特性的设计方案与实施计划反映“怎么做”与决策权衡特性开关src/features.xml doc/feature_flags.md特性在五个构建品牌下的实际启停状态反映“现在代码里是什么阶段”。三者互为印证路线图中提到的每一个带 issue 编号的特性都能在doc/specs/下找到对应规格在src/features.xml中找到对应开关及其 stage 配置。六、小结回到 doc/roadmap-2023.md 本身可以提炼出 Windows Terminal 2023 年的三条工程主线节奏季度发布 里程碑末月 bake time Preview 领先 Stable 一个版本的固定流转使版本时间线可预期、又保留了对社区 PR 合入速度的调节空间通道分层Canary每日构建实验特性首发→ Preview正式发布候选→ Stable滞后一版高风险特性在低层通道多停留这一分层由src/features.xml的品牌 token 机制在编译期精确执行特性落地1.19 的六项特性——Canary 构建、Terminal AI v0、Suggestions UI、cmd.exe Unicode 输入、conhost 性能改进、Broadcast Input——分别从构建体系、实验特性开关、统一建议 UI、console host 输入路径、console host 性能、动作体系toggleBroadcastInput命令六个不同层面得到仓库内的落点印证。对贡献者或深度用户而言阅读这份路线图的实用方法是以版本表为时间基线以 1.19 特性清单为关注焦点遇到任何特性时按“specs 规格 → features.xml 开关 → 默认设置/命令登记”的顺序在仓库内追踪其真实状态即可在不依赖外部渠道的情况下完整还原该特性的设计与阶段。【免费下载链接】terminalThe new Windows Terminal and the original Windows console host, all in the same place!项目地址: https://gitcode.com/GitHub_Trending/term/terminal创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Windows Terminal 2023 路线图：季度发布节奏、Preview 到 Stable 的演进机制与 1.19 特性落地
Windows Terminal 2023 路线图季度发布节奏、Preview 到 Stable 的演进机制与 1.19 特性落地【免费下载链接】terminalThe new Windows Terminal and the original Windows console host, all in the same place!项目地址: https://gitcode.com/GitHub_Trending/term/terminal本文基于 Windows Terminal 仓库中的 Terminal 2023 Roadmap 展开完整梳理 2023 年 Windows Terminal 的季度发布节奏、Preview 与 Stable 双通道流转规则以及 1.19 里程碑中六大特性Canary 构建、Terminal AI、Suggestions UI、cmd.exe Unicode 输入、性能改进与 Broadcast Input 广播输入各自的规划意图与在仓库源码中的落点帮助读者理解该项目的发布工程方法论并学会通过特性开关文件自行验证某个实验特性处于哪个发布阶段。一、文档定位从 2022 到 2023 的规划演进2023 年路线图doc/roadmap-2023.md是 2022 年路线图 的继任文档用于反映规划方式的变化。回顾 2022 年文档可以看到团队当时放弃了最初设想的“Terminal v2”大版本目标转而采用持续增量更新的方式“在过去 18 个月里团队已经清楚我们并不需要一个严格的 2.0 版本。通过持续、增量的更新我们依然可以很好地服务社区。如果未来某个版本值得 2.0 的名号我们届时再重新评估。” —— doc/roadmap-2022.md2022 年的里程碑管理采用与内部截止日期对齐的“学期”22H1 / 22H2划分并配套一套 Issue 分级机制P0严重崩溃、数据丢失等排入当前发布里程碑尽快处理P1通常排入当前或下一个发布里程碑P2 / P3通常排入当年第二个学期需要随 Windows 操作系统一同合入的无障碍与 Console 问题排入当前学期与现有学期无关的需求进入 Backlog 等待后续分级与排期。2023 年路线图在此基础上进一步简化为大约每季度一次的发布周期这是理解本文后续所有内容的基线。二、发布节奏季度化与 Preview/Stable 双通道2.1 2023 年发布时间表路线图给出的 2023 年季度发布计划如下时间表原文标注为粗略估计而非硬性规则例如 1.18 的发布曾为配合 Build 2023 而略有推迟季度日期发布版本状态说明CY23 Q12023-01-24Terminal 1.17已发布PreviewCY23 Q22023-05-23Terminal 1.18已发布PreviewCY23 Q32023 年 9 月下旬目标Terminal 1.19规划中CY23 Q42024 年 1 月初预期Terminal 1.20规划中2.2 单个里程碑内部的时间分配路线图使用 Mermaid 甘特图描述了一个典型里程碑以 1.18/1.19 为例的时间切分其中每个里程碑的最后一个月被保留为 “bake time”用于打磨 bugfix、稳定main分支期间通常会放缓对社区 PR 的合入速度。原文档明确注明该图为 “informative, not normative”仅供参考非规范性约束从甘特图可以看出一个季度的典型节奏特性开发约 10 周 → 修复期约 4 周 → 锁定烘焙期 2 周 → 发布随后该 Preview 版本晋升为 Stable 版本。2.3 Preview 先行Stable 滞后一个版本新特性的流转规则是理解 Windows Terminal 版本能力的核心新特性先进入Windows Terminal Preview通道通常在 Preview 中出现一个版本之后特性才会进入Windows TerminalStable通道对于风险较高或实验性的特性团队可能让其在 Preview 通道中停留更长时间甚至长期仅存在于 Preview/Canary 构建。路线图脚注指出一份关于哪些特性处于何种实验状态的具体清单可以从 src/features.xml 中查到并特别说明该文件是“用于点亮代码库特定部分的原始 XML 文档并非为人类阅读而撰写”。下一节将展开说明这套机制。三、特性分阶段机制从 features.xml 到编译期开关脚注提到的 src/features.xml 是 Windows Terminal 特性分阶段feature staging的单一事实来源。其工作机制在 doc/feature_flags.md 中有完整说明构建期由 tools/Generate-FeatureStagingHeader.ps1 解析该 XML 并生成编译期头文件。3.1 XML 结构要素每个feature节点包含以下关键元素元素作用name特性名如Feature_ShellCompletions将生成Feature_XYZ::IsEnabled()接口与TIL_FEATURE_XYZ_ENABLED预处理宏description特性说明id关联的 GitHub deliverableissue/PR编号可选stage默认状态AlwaysEnabled或AlwaysDisabledalwaysDisabledBranchTokens/alwaysEnabledBranchTokens按分支通配符禁用/启用特性alwaysDisabledBrandingTokens/alwaysEnabledBrandingTokens按品牌Branding禁用/启用特性合法取值为Dev、Preview、Release、WindowsInboxalwaysDisabledReleaseTokens /空标签表示该特性在 Release 构建中无条件禁用优先级最高判定优先级从高到低为alwaysDisabledReleaseTokens→ 启用分支 → 禁用分支匹配的分支 token 越长优先级越高→ 启用品牌 → 禁用品牌 → 特性默认状态。生成脚本 tools/Generate-FeatureStagingHeader.ps1 支持通过-Branding参数在Dev、Canary、Preview、Release、WindowsInbox五种品牌中选择构建目标——这里可以清楚看到Canary 与 Dev、Preview、Release、WindowsInbox 并列为一等构建品牌这正是路线图所述“Canary builds”在构建体系中的落点。3.2 用特性开关验证 1.19 特性的发布阶段当前仓库版本的 src/features.xml 内容与路线图高度呼应可以拿几个 1.19 特性逐一对照Shell 补全 / Suggestions UIFeature_ShellCompletionsid3121/id对应路线图中的 [#3121]描述为“一个供客户端应用请求终端显示建议列表的实验性转义序列”stage为AlwaysEnabled且带alwaysDisabledReleaseTokens——即默认对所有品牌启用但无条件从 ReleaseStable构建中编译排除。这精确对应了“新特性先进 Preview、滞后一版再进 Stable”的流转规则。非终端面板实验Feature_ScratchpadPaneid 997与Feature_MarkdownPaneid 16495均为AlwaysDisabled仅在Dev与Canary品牌下启用——这正是路线图所说“实验性特性可能只在 Canary/Preview 中长期存在”的实际案例。面向 Windows 系统自带版本WindowsInbox的裁剪大量特性带alwaysDisabledBrandingTokensbrandingTokenWindowsInbox/brandingToken/alwaysDisabledBrandingTokens例如Feature_ReceiveIncomingHandoffOpenConsole 接收连接、Feature_AdjustIndistinguishableText前景色自动调整、Feature_ScrollbarMarks滚动条标记等。这说明同一份main代码库同时支撑独立商店版 Terminal 与随 Windows 系统分发的 conhost二者通过品牌 token 精细地区分特性面。因此读者在仓库中判断“某实验特性当前处于哪个阶段”时只需三步找到src/features.xml中对应特性节点 → 查看stage与各 token 配置 → 结合优先级规则推断其在 Dev / Canary / Preview / Release / WindowsInbox 五个品牌下的启停状态。四、Terminal 1.19 特性清单与仓库落点路线图列出的 1.19 特性共六项下面逐项说明其规划意图并标注仓库中可查证的相关位置。4.1 Canary builds来自 main 的每日构建“Canary builds。来自main的 Terminal 每日构建。更不稳定但能更快获得实验特性。”Canary 是比 Preview 更前置的通道。从源码结构看Canary 构建由仓库中的 CI 管道支持build/pipelines/ob-nightly.yml 等夜间构建流水线中配置了environment: production-canary部署环境且如前文所述Canary是特性开关生成脚本认可的一等品牌。结合Feature_ScratchpadPane、Feature_MarkdownPane等仅在Dev/Canary下启用的特性可以推断团队将 Canary 定位为实验特性的第一落地通道先在 Canary 上积累稳定性证据再进入 Preview最终按双通道规则进入 Stable。注意区分术语仓库中 src/host/ft_host/CanaryTests.cpp 的 “Canary” 指的是“金丝雀测试”——验证控制台激活仍能正常启动 cmd.exe 的简单启动测试与 Canary 构建通道是同一词的两层含义不要混淆。4.2 Terminal AI仅随 Canary 发布的 v0“Terminal AI。虽然它最初只会随 Canary 构建发布但 v0 实现大约会与 1.19 同时可用。”这是六项特性中发布限制最严格的一项路线图明确其 v0 只进入 Canary 构建。结合 3.2 节介绍的 staging 机制这类特性的典型形态就是AlwaysDisabled 仅Canary/Dev品牌启用的特性开关或干脆处于独立实验分支。路线图中还前瞻性地指出Suggestions UI “可能也是 Terminal AI 未来的基础”——这与 3.2 节中Feature_ShellCompletions作为通用建议展示通道的定位相吻合。4.3 Suggestions UI补全、任务与 AI 的统一入口“Suggestions UI。这是 shell 补全#3121、任务#1595以及未来可能 Terminal AI 的起点。”Suggestions UI 的完整设计规格位于 doc/specs/#1595 - Suggestions UI/Suggestions-UI.md其核心思想是终端内出现一处临时的、类 Intellisense 的 UI在文本插入点附近展示建议列表统一承载多类建议来源shell integration 驱动的历史命令、最近目录、shell 自身的补全结果、settings 中sendInput动作定义的任务tasks、基于缓冲区词汇的 Buffer Completions以及未来扩展extensions提供的来源形态上区分带过滤文本框的“palette”与纯列表的“menu”两种模式客户端应用可以通过新的 VT 转义序列主动唤起该 UI——对应src/features.xml中Feature_ShellCompletions的描述“An experimental escape sequence for client applications to request the Terminal display a list of suggestions”。规格文档按 Crawl / Walk / Run / Sprint 四级划分用户故事从“shell integration 提供最近命令”逐步演进到“扩展可以提供建议来源”与“内联inline模式”。这为路线图“Suggestions UI 是起点”的判断提供了依据它先服务补全场景再承载任务场景最终为 Terminal AI 的输出展示铺路。4.4 cmd.exe 的 Unicode 输入cooked reads“cmd.exe以及任何使用 cooked reads 的 console 应用的 Unicode 输入。见 #15567。”这条针对的是原始 Windows Console 一侧的能力使用“cooked”有状态行编辑方式读取输入的 console 应用cmd.exe是典型代表获得 Unicode 输入支持。从源码结构看cooked 读取路径的实现位于 src/host/readDataCooked.cpp配套头文件 src/host/readDataCooked.hpp该改动发生在 conhostconsole host侧而非 XAML 版的 Terminal 前端这也是路线图把“cmd.exe 的 Unicode 输入”与“Conhost 性能改进”放在同一版本的原因——二者都属于同一套 console host 代码库内的工程。4.5 其他性能改进Conhost 显著提速“其他性能改进。Conhost 现在应该快很多了。”这是对 1.19 中 console hostconhost即随 Windows 系统分发、负责所有传统控制台窗口的组件性能工程的总体描述。路线图未逐项列出具体优化点其收益主要惠及传统 console 应用与 Windows 系统自带终端体验而非仅商店版 Windows Terminal。4.6 Broadcast Input 广播输入模式“Broadcast input mode用于同时向多个 pane 发送文本。”Broadcast Input 的设计规格保存在 doc/specs/drafts/#2634 - Broadcast Input/#2634 - Broadcast Input.md。该规格借鉴 iTerm2 的成熟实现让用户能把同一份键盘输入同时发送到多个标签页/窗格从而在多个目录或多台服务器上执行相同命令。规格中比较了三种设计提案iTerm2 式模态广播、广播集合、以及二者的改良混合核心动作模型统一为{ action: toggleBroadcastInput, scope: window }, { action: toggleBroadcastInput, scope: tab }, { action: toggleBroadcastInput, scope: pane }, { action: disableBroadcastInput }其中scope决定广播粒度window级为“所有标签的所有窗格”tab级为“当前标签的所有窗格”pane级为“把当前窗格加入/移出广播集合”。规格还规划了视觉指示方案在被广播的标签/窗格上显示网络塔图标并考虑用强调色变体SystemAccentColorLight*/SystemAccentColorDark*高亮广播目标窗格的边框同时预留了跨窗口广播需与 Monarch 单实例架构协调、广播分组scope: tab, group: 1、将广播状态暴露给像素着色器等后续扩展方向。在仓库代码侧可以验证该特性已经落进默认设置src/cascadia/TerminalSettingsModel/defaults.json 中登记了命令toggleBroadcastInputid 为Terminal.ToggleBroadcastInput说明广播输入已作为一等 keybinding 命令进入 Terminal 的动作体系用户可将其绑定到任意按键。五、North Stars路线图之外的团队长期目标路线图还专门留了一节指向团队每位成员的“North Stars”北极星清单那是一份更灵活、更长期的个人目标列表列出了团队各成员正在推进的方向但不属于已承诺交付的工作。理解这一点有助于区分三类文档的信息性质路线图roadmap-2023.md季度节奏 已承诺进入某版本的核心特性时间线仅供参考informative, not normative规格文档doc/specs/ 下各 issue 规格特性的设计方案与实施计划反映“怎么做”与决策权衡特性开关src/features.xml doc/feature_flags.md特性在五个构建品牌下的实际启停状态反映“现在代码里是什么阶段”。三者互为印证路线图中提到的每一个带 issue 编号的特性都能在doc/specs/下找到对应规格在src/features.xml中找到对应开关及其 stage 配置。六、小结回到 doc/roadmap-2023.md 本身可以提炼出 Windows Terminal 2023 年的三条工程主线节奏季度发布 里程碑末月 bake time Preview 领先 Stable 一个版本的固定流转使版本时间线可预期、又保留了对社区 PR 合入速度的调节空间通道分层Canary每日构建实验特性首发→ Preview正式发布候选→ Stable滞后一版高风险特性在低层通道多停留这一分层由src/features.xml的品牌 token 机制在编译期精确执行特性落地1.19 的六项特性——Canary 构建、Terminal AI v0、Suggestions UI、cmd.exe Unicode 输入、conhost 性能改进、Broadcast Input——分别从构建体系、实验特性开关、统一建议 UI、console host 输入路径、console host 性能、动作体系toggleBroadcastInput命令六个不同层面得到仓库内的落点印证。对贡献者或深度用户而言阅读这份路线图的实用方法是以版本表为时间基线以 1.19 特性清单为关注焦点遇到任何特性时按“specs 规格 → features.xml 开关 → 默认设置/命令登记”的顺序在仓库内追踪其真实状态即可在不依赖外部渠道的情况下完整还原该特性的设计与阶段。【免费下载链接】terminalThe new Windows Terminal and the original Windows console host, all in the same place!项目地址: https://gitcode.com/GitHub_Trending/term/terminal创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考