IT之家 6 月 5 日消息，科技媒体 Windows Latest 昨日（6 月 4 日）发布博文，报道称在 2026 年 Build 开发者大会上，微软调整 Windows 11 的底层路线， 确认会用 WinUI 原生代码重写 Windows 11 shell 的核心部分，并减少系统里依赖网页技术的界面层。 微软在 Build 大会上表示，Windows 11 系统过去几年的界面调整，不少都建立在 Electron（跨平台桌面框架）、React Native（跨平台界面框架）和 WebView 方案上，带来内存占用偏高、启动偏慢、CPU 活动增加与动画卡顿等问题。 微软接下来的改进重心，明确 WinUI 成为 Windows 11 的长期 UI 开发框架。为了打消开发者对“WinUI 4 是否又要替代现有框架”的担忧，微软宣布今后不再强调“WinUI 3”，统一改称 WinUI。 微软在 Build 大会上透露，公司团队正加速推进 WinUI，目前重写 Windows 11 shell 的核心部分，且更多第一方功能会直接基于原生框架构建。 IT之家注：Windows 11 的 shell 指的是用户与操作系统交互的图形用户界面 (GUI)，主要由资源管理器管理，负责呈现桌面、任务栏、开始菜单和文件管理等核心元素。 微软目前的首个重写项目聚焦开始菜单，针对“推荐”信息流和“所有应用”列表部分，从原有的 React Native 渲染改为原生 WinUI。 微软还强调重新 shell 外，团队把性能、基础能力和质量放在更高优先级。微软称，近几个月已针对基础内存占用做大量优化，同时把框架切换到新的系统合成器，以改善复杂界面的流畅度。 微软承认 WinUI 目前也存在一些 Bug 和不足，比如照片等原生应用在调整窗口大小时会出现黑边和撕裂。 微软还补齐企业开发常用组件，包括 DataGrid 与 Charting，减少开发者对第三方库的依赖。 微软还同步推出实验性项目 Microsoft UI Reactor，计划用纯 C# 构建声明式 WinUI 界面，降低对 XAML 的依赖，也更适合 GitHub Copilot 等 AI 编码助手理解与生成代码。
在 Build 2026 开发者大会上微软宣布将 WinUI 3 框架重命名为 WinUI，同时微软开始鼓励开发者使用 WinUI 框架为 Windows 11 开发高性能原生应用，微软释放的信号似乎是不要再纵容基于 Web 技术的劣质应用继续拖累 Windows 11，当然原本微软也是制造 Web 垃圾的一员。 鼓励开发者开发原生应用： 目前 Windows 平台充斥着大量基于 Electron、React Native 或基于 WebView 2 Runtime 打包的应用，这些应用占用的内存比较高、启动速度慢、界面风格也存在差异，当然最重要的还是性能体验非常差。例如微软自家开发的基于 WebView2 Runtime 的 Outlook 体验就非常糟糕。 不过从今年开始微软已经决定在 Windows 11 中抛弃基于 Web 技术的应用，转而采用更加可靠的原生架构，例如开始菜单 (推荐部分)，所以微软也开始鼓励开发者也采用原生框架开发体验更好的原生应用，只不过对开发者而言采用 Electron 可以降低开发成本，开发者是否愿意遵从微软的建议开发原生应用还需要观察，毕竟微软的态度变化非常快。 为什么要将 WinUI 3 更名为 WinUI： 科技以更名为本，所以现在微软宣布将 Windows 应用生产级平台 WinUI 3 开发框架更名为 WinUI，更名的原因有可能是微软觉得以 2 3 4 这种版本号发布可能会让开发者担心，即微软不停地发布新框架，开发者需要不断地适配新框架，要是微软进行破坏性的大改动，那开发者适配成本就会大幅度增加。 所以微软强调基于长期稳定性考虑，WinUI 框架正式取消版本号，微软没有计划在未来开发新的 UI 框架，也不会进行破坏性的大改动，让开发者们可以安心专注于基于 WinUI 框架进行应用开发，为应用带来更好的使用体验。 微软还透露 Windows 11 更多系统级 Shell 组件将会陆续迁移到 WinUI，实现全平台界面风格和性能的一致性，但微软也不会排斥其他框架，只不过微软建议开发者使用 WinUI 而不是 Electron 等框架。 查看评论
IT之家 6 月 4 日消息，科技媒体 Windows Central 昨日（6 月 3 日）发布博文，报道称在 Build 2026 开发者大会上， 微软把 Windows 11 原生应用重新推到台前。 微软确认 WinUI 是 Windows 应用的最优生产平台，并放弃 WinUI 3 编号，改称 WinUI。 微软承诺不会再另起新框架，让开发者不用担心路线突然变化。 WinUI 3 界面示意图 这次表态关联微软内部正在推进的 Windows K2 计划，目标重建 Windows 11 系统。 微软此前承诺提升系统质量、性能和可靠性，并已组建新团队开发 Windows 11 原生应用，目前已着手推进开始菜单、文件管理器等相关组件改造。IT之家附上相关截图如下： 无推荐区域的开始菜单 为了补齐基础体验，微软把重点放在稳定性、内存占用和开发工具上。微软软件工程副总裁 Chris Anderson 表示，公司已投入资源改善内存使用，并切换到 System Compositor（系统合成器）。 WinUI 3 Gallery 界面 微软还邀请企业开发者共同推进 WinUI 生态建设，将推出 DataGrid 和 Charting 相关支持，这两类控件常见于财务应用、人力资源仪表盘、管理工具和计费软件，能让企业团队更容易用 WinUI 搭建数据密集型界面。 微软还透露 WinUI 正积极适配 AI 智能体开发，让 AI 工具帮助开发者规划、构建、优化 WinUI 应用。 微软 AI 工具辅助 WinUI 应用 微软称，新平台能力可用于创建新应用、改造现有应用，或把旧应用迁移到现代 Windows UI 技术栈。 AI Agent 辅助 WinUI 开发
Easy PDF 是一款基于 Windows 11 原生风格 WinUI 3 的 PDF 阅读器，目前正在微软商店限免。@Appinn 感谢小熊猫的推荐：https://meta.appinn.net/t/topic/85654 在微软商店里发现一款限免的 WinUI3 的 PDF 阅读器：Easy
最近做了一个 Windows 上的 Xray 客户端，名字叫 Orayo 。 我平时本地直接跑 Xray 裸核，但切换配置和日常操作还是不太方便，所以做了一个带现代界面的 Windows GUI 客户端。 亮色模式 暗色模式 项目地址： https://github.com/barkure/Orayo 目前已经支持这些功能： 基于 Xray-core TUN 模式 系统代理 节点导入、手动添加、编辑、删除 路由规则与 DNS 设置 Geo 数据文件更新 WinUI 3 桌面界面 提供 Setup 和 Portable 两种发布形式 最新版本下载： https://github.com/barkure/Orayo/releases/latest 如果你愿意试用，欢迎提 issue 或反馈建议。也欢迎 star 支持一下。
最近做了一个 Windows 上的 Xray 客户端，名字叫 Orayo 。 我平时本地直接跑 Xray 裸核，但切换配置和日常操作还是不太方便，所以做了一个带现代界面的 Windows GUI 客户端。 亮色模式 暗色模式 项目地址： https://github.com/barkure/Orayo 目前已经支持这些功能： 基于 Xray-core TUN 模式 系统代理 节点导入、手动添加、编辑、删除 路由规则与 DNS 设置 Geo 数据文件更新 WinUI 3 桌面界面 提供 Setup 和 Portable 两种发布形式 最新版本下载： https://github.com/barkure/Orayo/releases/latest 如果你愿意试用，欢迎提 issue 或反馈建议。也欢迎 star 支持一下。
最近做了一个 Windows 上的 Xray 客户端，名字叫 Orayo 。 我平时本地直接跑 Xray 裸核，但切换配置和日常操作还是不太方便，所以做了一个带现代界面的 Windows GUI 客户端。 亮色模式 暗色模式 项目地址： https://github.com/barkure/Orayo 目前已经支持这些功能： 基于 Xray-core TUN 模式 系统代理 节点导入、手动添加、编辑、删除 路由规则与 DNS 设置 Geo 数据文件更新 WinUI 3 桌面界面 提供 Setup 和 Portable 两种发布形式 最新版本下载： https://github.com/barkure/Orayo/releases/latest 如果你愿意试用，欢迎提 issue 或反馈建议。也欢迎 star 支持一下。
在用户对“网页应用臃肿（web app slop）”抱怨日益高涨的背景下，微软正式对外释放信号：将在 Windows 11 上全面回归原生界面技术，重点押注 WinUI 3 框架，削减系统和应用对 WebView2、Electron 等网页包装技术的依赖，借此大幅降低资源占用并改善响应速度。 微软表示，其目标是让 WinUI 3 成为“构建 Windows 体验和应用的最佳原生 UI 平台”，以重建开发者信任，并扭转 Windows 11 在性能和流畅度方面的负面口碑。 过去几年，出于跨平台和成本考虑，包括大型科技公司在内的众多开发者，逐渐从传统原生 Windows 应用转向 PWA 或 Electron 等“网页壳”解决方案，这类应用虽然开发效率高，却常常占用大量内存和电量，即便只呈现简单界面也显得极不经济。 伴随 Windows 11 推出的各种 WebView2 界面组件，一些系统核心模块也被批评存在细微但恼人的卡顿，令桌面体验沦为“浏览器套壳”。 根据微软工程团队在 GitHub 上发布的技术简报，WinUI 3 在性能方面取得了显著进展，尤其是在文件资源管理器（File Explorer）等核心应用的启动阶段。 官方给出的数据表明，在资源管理器启动过程中的 WinUI 部分，内存分配次数减少约 41%，瞬时（临时）分配减少约 63%，函数调用数量减少约 45%，整体停留在 WinUI 代码中的时间缩短约 25%。 这些改动意味着 UI 框架自身的开销大幅下降，界面可以更快完成渲染并变为可交互状态，为用户带来更敏捷的启动体验。 微软强调，这些指标并不意味着资源管理器整体启动时间会“同步减少 40%”，因为实际体验提升还取决于多个团队在文件系统、后台服务等层面的协同优化。 不过，从框架层面“瘦身”被视为长期性能规划中的必经步骤，尤其是当这类优化再叠加“低延迟配置”这样的硬件调度措施时，将形成“1+1>2”的复合效果，从而显著缩短应用真正进入可用状态的时间。 微软同时开始系统性地将 Windows 11 的核心 UI 从 WebView2/Web 技术迁回 WinUI 3 原生实现。 Windows Latest 此前报道称，开始菜单的 React/Web 组件正逐步被 WinUI 3 原生代码替代，类似方向也将拓展至更多系统组件，以消除因网页渲染引擎带来的额外抖动与延迟。 这被视为“清理系统中网页壳”的关键转折，标志着微软在架构层面正式为“原生优先”定调。 为了确保这些性能提升真正落地到开发生态，而不仅仅停留在微软自家应用层面，公司还对 WinUI 3 的开发流程进行了大幅“减负”。 传统原生 Windows 开发往往需要安装体量庞大的 Visual Studio，并深入理解复杂的 XAML 结构，对许多习惯用 Web 技术的开发者来说门槛极高。 为了拆除这道门槛，微软推出了一套面向 WinUI 的开源 dotnet new 项目与项模板，开发者可以在命令行中直接生成、构建并运行打包好的 WinUI 原生应用，无需开启 Visual Studio。 这些模板预设了现代 Windows 应用轮廓，包括符合 Fluent Design 的标题栏、导航视图、TabView 等，同时与 WinApp CLI 集成，自动处理过去常常令开发者头疼的 MSIX 打包及证书注册流程。 在命令行执行 dotnet new winui-navview 等指令后，开发者即可获得一个带有现代导航架构、支持明暗模式的原生应用骨架，大幅缩短从“空项目”到“可运行原型”的时间。 更具突破性的一步，是微软为 GitHub Copilot、Claude Code 等 AI 助手推出了专用的 WinUI Agent 插件。 开发者只需在命令行中以自然语言提出需求，例如“创建一个带缩略图和 EXIF 信息的 WinUI 3 照片查看器”，AI 代理就会自动选择合适模板、生成 MVVM 架构、编写 XAML 界面，并尝试修复编译错误，甚至还能调用集成的 UI 自动化测试能力，运行端到端 UI 测试以发现并修复功能问题。 微软称，通过赋予 AI 对 WinUI 与 Windows App SDK 的“深度领域知识”，原生开发的时间与成本将被显著压缩，从根本上削弱跨平台网页壳方案在“开发效率”上的优势。 与此同时，微软在 WinUI 3 的性能路径上也做出了一定的结构性取舍。 工程团队在 GitHub 更新中承认，要实现这些“刀尖上的性能”，需要对默认控件样式做出破坏性调整，一些严重依赖自定义容器和模板的旧应用可能会因此受影响。 出于兼容性考虑，相关性能优化暂时以“可选（opt‑in）”形式提供，供有需求的开发者主动开启；但微软的中长期规划是，在 WinAppSDK 3.0 或 4.0+ 之后，将这些高性能路径切换为默认开启、需要时再手动“退出（opt‑out）”，推动整个生态向更高效的原生实现迁移。 在更广泛的行业层面，内存价格走高、桌面应用普遍膨胀、聊天软件随便就占用 1GB 以上内存的现象，都让用户对“低效软件”愈发难以容忍。 Windows 11 此前频繁被批评“越来越像浏览器壳”和“现代应用反而比旧版更慢”，某些高层前任甚至透露微软曾经给每位工程师发过秒表，强调需要“真正在意用户等待了多久”。 如今，伴随 WinUI 3 在框架级减负、开始菜单等核心组件向原生迁移、2026 年 5 月补丁更新中对性能和体验的持续修补，以及一整套围绕命令行和 AI 的开发工具链，来自雷德蒙的信号愈发明确：微软希望让 Windows 11 真正回归一个高性能、强响应、深度原生的桌面操作系统，而非堆叠网页层的“壳中之壳”。 查看评论
IT之家 5 月 15 日消息，Windows Latest 今天（5 月 15 日）发布博文，报道称微软明确押注 WinUI 3， 希望借此改善 Windows 11 长期被批评的卡顿、臃肿与网页封装层过多等问题。 在 经历多年混乱 后，Windows 开发者针对跨平台开发，近年来转向 PWA（渐进式网页应用）和 Electron 封装方案，但也暴露出内存占用过高、续航影响更重，以及桌面界面交互卡顿等问题。 IT之家此前报道，微软 Windows 工程师在 GitHub 发布技术说明，称要把 WinUI 3 打造成 Windows 体验和应用的最佳原生界面平台。 微软团队为证明优化方向有效，以文件资源管理器和记事本的启动过程为基准，重点观察 WinUI 框架本身在启动链路中的负担变化。 指标 改善幅度 内存分配次数（Allocations） 减少 41% 临时内存分配（Transient allocations） 减少 63% 函数调用次数（Function calls） 减少 45% WinUI 代码执行时间 降低 25% 不过该媒体指出，上述指标更偏向工程术语，只覆盖启动过程中的 WinUI 代码段，而非端到端完整加载时间，在用户感知层面，并不等同于文件管理器整体启动速度直接快 40％。 在系统架构层面，微软也在减少网页技术对核心组件的渗透。报道提到，Windows 11 开始菜单正从基于 React 的网页组件转向纯原生 WinUI 3 代码。 需要注意的是，部分 WinUI 3 提速能力当前仍属“选择加入”。微软承认，这些优化伴随默认控件样式的破坏性改动，某些高度自定义旧应用可能受影响。 因此，相关高性能路径暂时不会默认开启，未来计划在 WinAppSDK（Windows 应用开发工具包）3.0 或 4.0 以上版本逐步转向“默认启用、按需退出”。 除了系统优化，微软也在补开发工具短板。它新发布了 WinUI 的开源 dotnet new 项目与条目模板，开发者不必先安装庞大的 Visual Studio，可直接通过命令行创建、构建、运行完整打包的原生应用。新模板还整合现代标题栏、响应式导航、浅色与深色模式，以及更简化的 MSIX 打包注册流程。 更关键的一步，是微软把 AI 引入原生开发。新推出的 WinUI 智能体插件可接入 GitHub Copilot、Claude Code 等助手，帮助开发者依据自然语言需求自动选择模板、生成 MVVM 架构、编写 XAML 布局，并修复编译错误，甚至借助界面自动化能力定位功能缺陷。
IT之家 5 月 12 日消息，微软正在持续推进“Windows K2”计划以改善 Win11 性能。目前微软已在 GitHub 的一篇文章中详解 WinUI 框架改进工作，可让系统响应速度更快。 微软工程师 Beth Pan 表示：“我们的使命是让 WinUI 3 成为 Windows 系统、应用的最佳原生 UI 平台，而性能正是其中的核心。为了实现这一目标，我们需要从多层面逐步推进，包括 WinUI 本身”。 微软正在重点优化 WinUI 3 的启动时间，并以文件资源管理器、记事本作为性能测试基准。其中，前者的响应速度已经得到明显改善。 同时，微软还在文中公布了文件资源管理器改善成果，IT之家附详情如下： 指标 改善幅度 内存分配次数（Allocations） 减少 41% 临时内存分配（Transient allocations） 减少 63% 函数调用次数（Function calls） 减少 45% WinUI 代码执行时间 降低 25% 此外，这些改进将很快进入开发分支，随后并入主线分支。微软目前还在使用 WinUI 重构 Win11 的开始菜单，以进一步提升系统响应速度。
微软正计划在 Windows 11 中淘汰沿用自 Windows 95 时代的文件资源管理器“属性”对话框，用一套基于 WinUI 3 的现代界面彻底替代这一几十年前的老组件，以配合其正在推进的性能与可靠性改造工程。目前的 Windows 11 表面上已经通过 WebView2 等新框架实现了相当统一、现代的视觉效果，但只要稍微深入系统，就会发现各种遗留界面依然随处可见，而文件资源管理器的属性窗口正是最典型的例子之一。 在 Windows 11 中，文件资源管理器本体已经获得多标签页、全新的地址栏以及带有平滑滚动体验的现代图库视图等更新，但当用户在文件上点击右键并选择“属性”时，弹出的仍然是一个风格停留在上世纪的旧对话框。尤其是在系统开启暗黑模式时，这个仍然保持纯白背景的传统 Win32 属性窗口在昏暗环境下几乎如同“闪光弹”，给习惯暗色界面的用户带来明显割裂感和不适。 来自 Windows 11 内测版本的新发现显示，微软正在积极开发一套完全现代化的、基于 WinUI 3 的文件属性对话框。知名 Windows 观察者“phantomofearth”在最新 Insider 预览构建中挖掘代码时注意到，MicrosoftWindows.Client.FileExp（即现代文件资源管理器框架）资源文件 resources.pri 中新增了多条“DeletedFileProperties”相关字符串。这些字符串与现有遗留“已删除文件属性”对话框中的文本完全一致，这一迁移动作为微软准备用现代组件替代旧属性窗口提供了强烈信号。 在与 Windows Latest 的进一步交流中，phantomofearth 表示，结合当前文件资源管理器中地址栏、搜索框、命令栏、详细信息窗格、主页和图库等部分都已采用 WinUI 3 的事实，他“几乎可以肯定”微软正在打造的正是一套 WinUI 3 版的属性对话框。在他看来，如果微软最终上线的新属性窗口不是基于 WinUI 3，反而会令人感到意外，因为在已经大规模使用该技术栈的前提下再选用其他方案并不合理。他还指出，如果微软没有计划推进属性对话框的现代化，就没有必要特地将其相关字符串迁移到现代文件资源管理器资源包中。 属性对话框迟迟不支持暗黑模式的问题，也因此有了一个更具逻辑的解释。在 Windows 11 中，还有一些遗留组件已经通过简单的暗黑模式开关或视觉微调获得了更新，但文件属性菜单始终维持原样，这让不少高级用户多年都在追问原因。按照 phantomofearth 的说法，如果这一组件本身已经被列入替换计划，微软就没有动机在旧 Win32 对话框上再投入精力进行暗黑模式适配，而是直接在新的 WinUI 3 原生版本中一并解决。Windows Latest 此前也曾证实，微软正在逐步替换 Windows 11 中残留的 Windows 8 时代界面元素，如今属性对话框相关字符串被迁移到现代框架中，则进一步表明公司正在系统性清理操作系统的历史遗留 UI。 从架构层面看，用 WinUI 3 重写属性对话框有助于缓解当前文件资源管理器代码混杂带来的性能问题。目前的资源管理器仍然在旧 Win32 基础之上叠加了 XAML 和 WinUI 等现代组件，这种混合渲染模式被认为是导致应用偶尔出现卡顿、白屏闪烁等体验问题的原因之一。此前报道显示，微软正在通过 2026 年内的一系列更新兑现“修好 Windows 11”的承诺，其中一项重要工作就是对资源管理器进行深层架构优化，并以递进方式引入更多 WinUI 3 元素，带来持续可感知的性能提升。将遗留属性对话框替换为原生 WinUI 3 版本，正好与 Windows Insider 负责人 Marcus Ash 近期提到的“性能、可靠性和打磨质量的实际改进”承诺相呼应。 在视觉层面上，用户或许也能从近期的其他更新中提前一窥新属性对话框的大致风格。例如，Windows 11 中隐藏的现代版“运行”对话框（Win+R）已经在 Insider 中出现，其整体设计更加轻盈纤细，更贴近系统其余 WinUI 3 界面的流畅观感。如果微软延续这一设计语言，那么新的属性对话框也有望摆脱“老派工具窗口”的既视感，转而呈现更统一、柔和的现代化外观，同时原生支持暗黑模式。 目前，这一现代化属性对话框仍深藏在 Insider 预览版本的资源文件中，尚未正式向测试用户开放，但其存在意味着距离进入广泛测试阶段已经不远。报道推测，该组件有望与其他即将到来的界面改进一同，率先在实验频道（Experimental Channel）向部分用户推送，时间窗口可能落在今年晚些时候。对于长期被刺眼白色属性窗口困扰的用户而言，告别这块“Windows 95 遗产”的日子，正在一步步临近。 查看评论
这是一款使用 WinUI 3（C#、C++）原生开发的现代 Windows 播放器，支持在线和本地音乐播放。在拥有 WASAPI 独占输出、灵动词岛、窗口材质更改、Q弹动效等特色功能的同时，资源占用低，非常适合追求极致视听交互体验的用户。@Appinn 来自发现频道，开发者 @LanZhan 自荐：
IT之家 4 月 29 日消息，微软昨晚发布了最新的 PowerToys 0.99 版本。感兴趣的用户可通过微软商店或 GitHub 下载，也可直接在 PowerToys 内检查更新。 PowerToys 0.99 带来了两项全新预览功能：Grab And Move（抓取并移动）与 Power Display（显示器控制），同时命令面板（Command Palette）、Dock 等多项实用功能获得改进。 Grab And Move：无需对准标题栏即可拖动或缩放窗口 正如其名，GAM 是一款窗口拖拽与缩放工具，允许用户在不点击标题栏或窗口边缘的情况下直接移动和调整窗口大小。 用户只需按住 Alt + 鼠标左键即可拖动窗口，Alt + 鼠标右键可在光标当前位置缩放窗口（IT之家注：对于已将 Alt 键用作系统热键的用户可改为 Win 键）。 该功能支持组策略配置，设有新手指南页面，适合在大屏幕或窗口移出屏幕范围内使用。 Power Display：系统托盘直接控制显示器 该功能启用后，用户可直接从系统托盘或通过快捷键打开显示器控件，快速调整音量、亮度、对比度和色彩配置文件。 该功能支持创建多组配置文件，一键切换不同显示设置，还可与 Light Switch 联动，根据系统亮色 / 暗色主题自动切换显示器配置。 Command Palette 与 Dock：紧凑模式、计算器历史与可靠性提升 Command Palette 和 Dock 获得大规模 Bug 修复与增强。 Dock 窗口新增“始终置顶”选项；当 Dock 位于屏幕顶部或底部时，可启用紧凑模式（28 像素高，隐藏副标题）。 另外，用户在使用固定命令时也可通过新增的对话框进行自定义调整，可控制命令在 Dock 中的显示位置及是否显示标题 / 副标题。 计算器扩展新增持久化历史记录，支持保存、重用、删除和清除条目。扩展加载逻辑已强化，单个扩展故障不再导致整个列表崩溃。 此外，索引器搜索支持文件名自动扩展和 Windows Search 可用性指示，Windows Terminal 配置文件现可固定至 Dock 并显示独立图标。 Keyboard Manager：手动调整映射键、支持“禁用”动作 Keyboard Manager 编辑器现允许手动调整已录制的键映射，每个键变为下拉菜单，还可选择实体键盘上不存在的键。 新增“禁用”动作，可快速禁用特定按键或快捷键。同时修复了多行文本替换在聊天应用和纯文本编辑器中的可靠性问题。 ZoomIt：支持滚动截图与文本提取 ZoomIt 新增滚动截图功能，方便截取长页面或超出屏幕可见范围的内容。截图时可直接提取图中的文字。休息计时器增加屏幕保护模式，帮助用户更有效地休息。 其他值得注意的更新 Image Resizer 界面从 WPF 迁移至 WinUI 3，外观更现代并与 PowerToys 整体风格一致。 Advanced Paste 修复了在 Electron / Chromium 应用（如 Teams、VS Code）中自动复制失败的问题。 设置界面多处 UI 与可用性改进。 默认模块状态精简，新安装用户将获得更轻量的初始体验。 系统托盘图标更新为单色样式，有可用更新时显示角标。 PowerToys 0.99 完整更新日志包含超过 200 项提交，涉及 Command Palette 扩展 SDK、索引器搜索、辅助功能、遥测与测试等多个方面。
AriaX 已经登陆苹果商店和微软商店。macOS 版本使用 SwiftUI 开发，Windows 版本使用 WinUI3 开发。 下载地址 Windows 版本: https://apps.microsoft.com/store/detail/9P8H0PT2L04Z?cid=DevShareMCLPCS macOS 版本: https://apps.apple.com/app/aria2x/id6763280346 侧载版本下载 https://github.com/saltpi/Aria.X