microsoft/terminal 是什么？

microsoft/terminal 同时承载 Windows Terminal 与经典控制台主机 conhost.exe 的源码。本文梳理其安装路径、构建方式、共享组件设计，并指出它在升级与兼容性上的真实边界。

microsoft/terminal 可以商用吗？

可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。

microsoft/terminal 还在维护吗？

在维护。仓库最近一次提交在 1 天前。

microsoft/terminal 是用什么编程语言写的？

主要是 C++（依据 GitHub 的语言统计）。

Windows Terminal 源码仓库解析：安装、构建与 conhost 共享组件

Q: microsoft/terminal 还在维护吗？

在维护。仓库最近一次提交在 1 天前。

秒懂

它是什么？: microsoft/terminal 同时承载 Windows Terminal 与经典控制台主机 conhost.exe 的源码。本文梳理其安装路径、构建方式、共享组件设计，并指出它在升级与兼容性上的真实边界。
适合谁用？: Windows Terminal 适合需要现代终端体验的 Windows 10 2004 及以上用户，尤其是愿意通过 Microsoft Store 自动更新或使用 winget 管理软件的开发者。不适合无法升级到 19041 的旧系统用户，也不适合追求最小依赖的极简主义者，因为官方推荐路径依赖 Store 或 MSIX 包。
能商用吗？: 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
还在维护吗？: 在维护。仓库最近一次提交在 1 天前。
用什么语言写的？: 主要是 C++（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年8月8日 · microsoft/terminal

一个仓库，两个面孔

microsoft/terminal 的 README 第一句就点明了它的双重身份：这里同时存放 Windows Terminal 和 Windows Terminal Preview 的源码，以及经典控制台主机 conhost.exe。很多人以为这个仓库只是新终端的家，实际上它还负责维护 Windows 上最古老的命令行宿主之一。这种安排不是巧合，而是因为两者共享大量底层组件。仓库里还有 ColorTool 和若干示例项目，用来演示如何调用 Windows Console API。对于想理解 Windows 命令行生态的人来说，这个仓库是唯一能同时看到新旧两条线的入口。

安装路径的优先级排序

README 明确把 Microsoft Store 列为推荐方式，理由是自动升级。对于无法使用 Store 的环境，GitHub Releases 页面提供 .msixbundle 文件，双击即可安装，失败时可以用 Add-AppxPackage 命令手动部署。winget 用户则可以直接执行 winget install --id Microsoft.WindowsTerminal -e，但要注意依赖支持需要 WinGet 1.6.2631 或更高版本，否则装不了 1.18 之后的稳定版。Chocolatey 和 Scoop 的包都是非官方的，README 特意标注了这一点，出了问题要去各自的包页面反馈，而不是找微软。这种排序透露出一个态度：官方希望大多数人走 Store，其他渠道只是备选。

Canary 分支的取舍

除了稳定版和 Preview，仓库还维护一个 Canary 渠道，直接基于 main 分支的每日构建。Canary 有两种分发形式：App Installer 版只支持 Windows 11，且会自动更新；Portable ZIP 版支持 Windows 10 19041 以上，但不会自动更新，也不会主动检查更新。README 直言 Canary 是最不稳定的版本，bug 可能比 Preview 还多。这个渠道适合想提前尝鲜的开发者，但不适合任何生产环境。值得注意的是，Portable ZIP 只提供 x64 架构，ARM 用户只能走 App Installer。

源码构建的硬性门槛

想从源码构建，README 给出了 PowerShell 和 Cmd 两种方式，但没有列出具体命令，只提到需要满足前置条件。文档要求 Windows 10 2004 或更高版本，这不仅是运行门槛，也是构建门槛。仓库使用 C++ 编写，依赖 Visual Studio 的 C++ 工具链和 Windows SDK，版本不匹配会直接导致编译失败。构建完成后，如果运行起来看起来像旧版控制台，README 的 FAQ 专门解释了这个现象，说明新终端的外观和旧 conhost 有本质区别，但某些配置下可能让人混淆。实际构建过程涉及大量共享代码，首次编译耗时较长，这点文档没有明说，但仓库规模摆在那里。

共享组件的双刃剑

仓库把 Terminal 和 conhost 的公共部分抽成了共享组件，这是设计上的核心决策。好处是修复一个 bug 可以同时惠及两个项目，坏处是改动一个底层组件可能影响两条产品线。比如修改控制台 API 的实现，既要保证新终端的渲染正常，又不能破坏 conhost 在旧系统上的行为。这种耦合让代码库的测试矩阵变得复杂，也解释了为什么发布节奏分成稳定版和 Preview 两个轨道。对于只想研究新终端渲染管线的开发者，这种结构意味着必须理解哪些代码属于共享层，哪些是 Terminal 独有的，否则很容易在错误的地方找答案。

升级维护的真实成本

如果你通过 GitHub 手动安装 .msixbundle，README 明确警告：不会自动更新，必须定期手动安装新版本才能获得修复。这意味着你承担了版本跟踪的负担。Store 和 winget 能缓解这个问题，但 winget 的依赖要求又增加了前置检查。Canary 的 Portable ZIP 更是完全脱离更新机制，适合临时测试。从维护角度看，稳定版走 Store 是成本最低的路径，手动安装适合离线或受限环境，但需要自己盯 Release 页面。仓库的活跃度很高，最近一次推送在 2026 年 7 月，稳定版和 Preview 几乎同步发布，说明项目仍在快速迭代，跟上节奏需要投入精力。

许可证与替代方案的对比

项目采用 MIT 许可证，这对想二次开发或嵌入代码的团队很友好，没有 GPL 那种传染性约束。但要注意，仓库里的 Cascadia Code 字体是独立仓库，许可证可能不同，使用时需单独确认。替代方案方面，最直接的是微软自家的经典 conhost，但它的功能远不如 Terminal，且不再有新特性。第三方终端如 Alacritty 或 WezTerm 走的是 GPU 渲染和跨平台路线，不依赖 Windows Console API，但也就无法享受 conhost 的兼容性。Windows Terminal 的优势在于它和系统深度集成，能处理传统控制台应用，而第三方终端往往需要额外配置才能模拟这种行为。

编辑结论

Windows Terminal 适合需要现代终端体验的 Windows 10 2004 及以上用户，尤其是愿意通过 Microsoft Store 自动更新或使用 winget 管理软件的开发者。不适合无法升级到 19041 的旧系统用户，也不适合追求最小依赖的极简主义者，因为官方推荐路径依赖 Store 或 MSIX 包。若你打算从源码构建，先确认 Visual Studio 版本与 Windows SDK 匹配，并准备好应对 conhost 与 Terminal 共享代码带来的编译复杂度。建议先通过 winget install --id Microsoft.WindowsTerminal -e 验证基础体验，再决定是否深入源码。

官方来源

社区笔记