微软把Windows的“脸”开源了。但你要想伸手去改，还得再等等。
2026年8月29日，微软正式宣布WinUI主线开发已全面迁移至GitHub。全球开发者现在可以实时围观微软工程师如何在Windows的原生UI框架上创建分支、提交PR、审查代码、跑测试、合并变更。每一个工程决策的痕迹，都暴露在公众视野中。
但有一件事现在还做不了：提交你自己的PR。
微软的说法很坦率：目前PR暂限内部提交，团队正在验证端到端流程。等流程跑通了，再开放外部贡献。
这不是一个“昨天闭源、今天开源”的开关式操作。它是微软自2025年起按四阶段推进的开源计划的中间节点。而理解这个节点为什么重要，需要先搞明白一件事：WinUI和微软此前开源的VS Code、TypeScript、.NET有什么本质区别。
WinUI不是又一个开源项目
VS Code和TypeScript是微软的开源明星，但它们不绑定操作系统的核心体验。你可以在Mac、Linux上用VS Code，TypeScript更是跨平台到了骨子里。.NET开源后也在Linux和macOS上跑得风生水起。
WinUI不一样。它是Windows 11的原生UI框架，是微软推荐给Windows桌面应用开发者的首选方案。Windows Shell的一部分——Widgets面板、新的Run对话框、文件资源管理器的部分界面——用的就是WinUI 3。PowerToys这样的开源明星项目也跑在WinUI上。
说得直白一点：WinUI是Windows操作系统的“面子”。你打开Windows 11看到的每一个窗口、按钮、菜单背后，都站着WinUI。
把这条主线的开发流程搬到GitHub上，意味着微软第一次让外界实时看到Windows的“面子”是怎么被画出来的。这不是一个外围工具的开源。它触及了Windows作为产品的工程心脏。
四年铺垫，一个分阶段的透明度爬坡
回顾WinUI的开源历程，会发现这不是一个突然的决定，而是一个缓慢但坚定的透明度爬坡。
2018年12月，微软在Connect 2018上宣布了WPF、Windows Forms和WinUI的开源。但那更多是“源代码公开”而非“开发流程公开”——你看到的是成品快照，而不是生产线。
2021年，WinUI 3随Windows App SDK正式发布。源代码仍然可以查看，但每天的工程决策、分支策略、评审对话仍然锁在微软内部。
转折发生在2025年。微软启动了四阶段开源计划，核心目标是把WinUI的主线开发从内部仓库搬到GitHub上。
2026年8月29日的公告，是这一计划的里程碑节点。微软在GitHub上的WinUI仓库已经不再是“代码镜像”。它是工程师真正工作的主战场。在Windows Forum的报道中，微软的表述异常明确：
公开仓库现在是工程师真正干活的地方，而不是一个延迟同步的镜像。
这个区别，比“开源”两个字本身重要得多。
一个项目如果只在GitHub上放源代码，工程师的PR、评审、测试都在内部系统里跑，那这个仓库本质上只是一个“源码展示柜”。开发者可以看到成品，但看不到决策过程——为什么这个API改了？为什么这个bug关了又开？为什么这个性能优化等了两个月？
现在，这些问题不再需要猜测了。答案就在GitHub上。
为什么“看得到”比“能提交”更紧迫
微软把主线开发搬上GitHub，但社区还不能提交PR。这个设定听起来有点矛盾，但从软件工程的角度看，逻辑是成立的。
WinUI不是独立于Windows的框架。它深度依赖Windows底层的专有组件和API。在把代码从微软内部仓库分离到公开仓库的过程中，团队必须确保不把Windows内核的敏感代码一并带出来。WinUI工程师Beth Pan在去年的一次GitHub更新中已经解释过：团队必须先分离代码与Windows专有层，然后才能让仓库对外可构建、有用。
当前阶段限制内部PR提交，本质上是在跑通端到端流程——从分支到PR、代码审查、自动化测试、验证到合并的完整链路。这条链路在内部系统中跑了十几年，但在GitHub的公开环境下，工具链、权限管理、CI/CD配置、安全审查都需要重新适配。
如果微软现在就开放社区PR，而验证流程还没跑通，可能会出现什么局面？外部提交的PR进入队列后迟迟得不到处理，或者合并后引发Windows Shell的兼容性问题。那对WinUI社区信誉的伤害，远大于“暂时不开放外部PR”。微软选择先锁门，理顺流程，再开门。
Windows Forum的分析文章一针见血：
对评估WPF、Win32、Qt、Electron、React Native或Web-first栈的开发者来说，这是流程上的进步，而不是新的技术能力。
API没有变。性能没有变。部署模式没有变。变的只是你看到它的方式。但这个“变”对于选型决策中的开发者来说，可能比一次性能更新更关键。
透明度本身就是生产力
对于一个已经在用WinUI 3开发Windows桌面应用的团队来说，“流程上的进步”能解决一个真实的痛点。
想象一下：你的团队正在用WinUI 3开发一个重要应用。某天你发现了一个bug——某个控件的渲染行为不符合预期。在旧模式下，你在GitHub的Issues里提交了报告，然后等。你看到的是：微软工程师标记了“已确认”，然后这个issue就沉了。你不知道问题是否在修、什么时候能修、修的方案是什么。
在新模式下，你可以直接看到相关分支上是否有针对这个bug的PR，评审进度到哪里了，测试覆盖率够不够，有没有被阻塞。你能判断这个bug是被降了优先级，还是在紧急处理。
这种透明度的价值，无法用几行代码来衡量。它直接改变了开发者选型WinUI的风险感知——从“出了问题谁知道微软管不管”变成“至少我能看见他们在干嘛”。
从更宏观的视角看，WinUI是Windows App SDK的核心组件。而Windows App SDK是微软用来解耦操作系统发布周期的关键策略——API更新走NuGet包分发，不再等Windows大版本更新。WinUI的开发流程可视化，就是整个SDK生态透明度的风向标。
摆在台面上的三个问号
第一个问号：社区的信任时间表
微软说“后续将逐步开放外部贡献”，但没有给出具体时间线。社区PR功能的开放日期，将决定WinUI开源承诺的可信度。如果在2027年之前社区还不能提交PR，那“开源”就仍然是单向透明——你能看，但不能参与。这在开源社区里是一个非常微妙但极重要的界限。
第二个问号：WinUI的性能能否支撑更大的野心
微软自己在2026年5月的GitHub讨论中承认了WinUI的性能工作需要加强。他们公布了File Explorer中WinUI部分的数据：分配减少了41%，过渡减少了63%。这些数字看起来不错，但File Explorer只是一个样本。
2026年7月，微软宣布WinUI 3已扩展到Widgets面板和新的Run体验，Autoplay和更多文件与文件夹属性对话框也进入了Insider实验阶段。WinUI正在被推到更多Windows shell表面。如果这些表面的性能体验不能让人满意，开源的透明度反而会让问题暴露得更快。
第三个问号：Electron还剩多少戏份
微软现在同时走两条路。一边推WinUI 3作为原生UI框架，一边优化Chromium和WebView2组件在Windows上的效率。2026年7月的Windows质量更新中，微软明确提到了在Windows、WinUI 3、Chromium和WebView2上的效率优化工作。
这意味着微软并没有计划把所有Windows应用都用WinUI重写。Teams、New Outlook、Microsoft 365 Copilot——这些被广泛诟病WebView2体验的应用，目前没有任何迁移到WinUI的时间表。
WinUI开源并不是“Web应用终结”的信号。它是微软给原生应用开发者提供更好工具的承诺，刚刚兑现了一部分。
真正的信号：Windows正在被“组件化”
把WinUI开源并迁移主线开发到GitHub，放在微软过去六年的战略演变中看，释放了一个比“透明度”更深的信号。
从Windows App SDK的NuGet化发布，到WinUI与Windows OS的版本解耦，再到今天的完全开源和主线开发公开——微软正在把Windows从一个“整体发布的操作系统”拆解成一组可独立迭代的组件。
WinUI是这一组件化战略中最关键的部件。它是Windows的UI层，也是最容易被用户和开发者感知的部分。如果这一层的开发流程可以在GitHub上公开运行而不影响Windows整体的安全性和稳定性，那就证明组件化的路径是走得通的。
这对微软的意义，可能比让社区提交几个PR更加深远。把操作系统的开发流程向社区开放，是一家四十年平台公司能给出的最昂贵的信任信号。
微软把WinUI的主线开发搬上GitHub，打开了一扇曾经紧闭的门。你还不被允许走进房子，但已经可以看清房间里的每一个角落。对于一家把操作系统UI框架与内核代码一起锁了四十年的公司来说，这已经是历史性的一步。下一步——什么时候让你进来——才是真正定义这段历史的答案。
快报