目录
[结论：默认选 .NET 10](#结论：默认选 .NET 10)
[1. 官方支持](#1. 官方支持)
[2. 客户电脑不一定"天然都支持"](#2. 客户电脑不一定“天然都支持”)
[2.1 框架依赖发布](#2.1 框架依赖发布)
[2.2 自包含发布](#2.2 自包含发布)
[3. 各自特色](#3. 各自特色)
[4. WPF 程序升级时会碰到的变化](#4. WPF 程序升级时会碰到的变化)
[5. 场景与选型](#5. 场景与选型)
结论：默认选 .NET 10
截至 2026 年 10 月 2 日，凡是还要长期交付、还要接安全补丁的 WPF 程序，.NET 10 是当前应采用的长期版本 。.NET 8 的支持在 2026 年 11 月 10 日结束。
两者都是 WPF 可用的 Windows 桌面运行时，画界面的技术栈相同。差异在支持期限、补丁、两年间积累的运行时和 WPF 修复，以及程序和依赖迁移的工作量。
1. 官方支持
| .NET 8 | .NET 10 | |
|---|---|---|
| 发布 | 2023-11-14，LTS | 2025-11-11，LTS |
| 当前阶段 | 维护期，只修安全问题 | 主动支持期，功能和安全都还在更新 |
| 最新补丁 | 8.0.31（2026-09-08） | 10.0.12（2026-09-08） |
| 支持结束 | 2026-11-10 | 2028-11-14 |
| WPF 目标框架 | net8.0-windows |
net10.0-windows |
11 月 10 日之后，针对 .NET 8 的程序仍能启动，但不会再有安全更新，也不会再有技术支持。
.NET 9 不用单独考虑。它和 .NET 8 同一天结束支持，不是长期选择。
2. 电脑支持
Windows 不会像预装 .NET Framework 4.8 那样，预装 .NET 8 或 .NET 10。客户机器上有没有对应运行时，取决于发布方式。
2.1 框架依赖发布
程序较小，但目标电脑必须已经安装同一主版本的 .NET Desktop Runtime。WPF 需要的是 Desktop Runtime，而不只是基础运行时。
针对 8 生成的程序不会自动改用机器上的 10；针对 10 生成的程序也不会用 8 启动。8 和 10 可以同时安装，互不替代。
2.2 自包含发布
把对应版本的运行时打进程序，客户不必预先安装 .NET。代价是安装包明显变大，运行时的安全补丁要靠重新发布程序。
WPF 还带有几份本机图形库；要真正打成一个 exe，需要把它们一并打进去。无论 8 还是 10，自包含仍然依赖 Windows 本身和 Visual C++ 运行库（除非一起打包）。
"电脑是否支持"：
- 操作系统是否还在你愿意承担的范围内。
- 发布方式是否已经带上了正确的 Desktop Runtime。
操作系统范围
官方当前支持矩阵里，.NET 8 和 .NET 10 的 Windows 范围是同一类：Windows 11 的在服版本，以及 Windows 10 的 Enterprise、LTSC、IoT 若干版本（如 21H2 Enterprise/IoT、1809 Enterprise、1607 Enterprise）。
Windows 10 家庭版和专业版 22H2 的系统支持已在 2025 年 10 月 14 日结束，官方矩阵不再把它列为受支持系统。这不表示程序一定打不开，只表示微软不再为这个组合做测试和修复。现场工控机如果还是 Windows 10，应以那台机器的实际镜像试跑，不能用开发机上的 Windows 11 代替。
Windows 7、Windows 8.1：.NET 8 和 .NET 10 都不支持。
3. 各自特色
.NET 10 有、.NET 8 没有的
- 支持到 2028 年 11 月，中间持续有安全和功能修复。
- .NET 9 和 .NET 10 累计的运行时改进：JIT、内存分配、启动和部分库的性能。这些是运行时层面的改进，不是"WPF 画图会自动快一倍"。
- WPF 自身在 .NET 10 的改动：减少 UI 自动化、文件对话框、像素格式转换中的分配；字体加载改为托管实现；动态资源、输入法、XAML 解析和字体渲染路径有优化；Fluent 样式有后续修复；剪贴板与 WinForms 共用一套 API，并支持用 JSON 传递自定义数据。
- 语言和库更新到 C# 14 及这两年的 BCL。客户看不见，开发效率会有差别。
.NET 8 有、 .NET 10 没有的
- 现有工程、NuGet、CI 和已发出去的安装包如果已经锁在
net8.0-windows，它是一条已知能编译、能运行的基线。 - 迁移成本为零。继续用 8，不用处理 .NET 9 起移除的
BinaryFormatter，也不用处理 .NET 10 对剪贴板旧 API 的废弃。
4. WPF 程序升级时会碰到的变化
普通按钮、布局、绑定、WriteableBitmap，多数项目改一下 TargetFramework 就能编过。需要重新验证的是下面这些。
- 剪贴板、拖放、导航日记里的自定义类型。 .NET 9 起
BinaryFormatter不再可用。字符串、数值、日期等基础类型仍能用；自定义对象要改成 JSON 或字节数组。.NET 10 把旧的GetData标为过时，并提供TryGetData、SetDataAsJson。 - **空的
ColumnDefinition/RowDefinition，以及错误的DynamicResource用法。**在 .NET 10 里会从"以前能混过去"变成编译失败或运行崩溃。 - 同时引用 WPF 和 WinForms。
MenuItem、ContextMenu需要写清楚命名空间。 - 第三方控件、授权组件、硬件 SDK。 若厂商只声明支持到 net8.0-windows，以厂商说明为准（依赖老旧第三方库比较多时，要甚至使用.net 10，可能支持会受到限制）。多数 WPF 控件能多目标框架，但不能假设每一家都已跟上。
这些是兼容性成本，不是性能高低。
5. 场景与选型
| 选择 | 适用场景 |
|---|---|
| .NET 10 | 新程序；还要维护一年以上的程序；需要 2026 年 11 月之后的安全更新；依赖已支持 net10.0；可以升级 SDK 和编译环境。对当前时间点，这是默认选择。发布时用自包含，或在安装包里附带 .NET Desktop Runtime 10，这样不依赖客户是否已安装。 |
| 短期留在 .NET 8 | 已经发出去、且在 11 月 10 日前不再改目标框架的补丁；或某个关键组件明确还不能在 10 上加载，而又必须在短期内交货。这种停留要写成有截止日期的决定：11 月 10 日之后继续用 8，等于接受不再有安全补丁。 |
不要用"电脑新旧"来二选一。 旧电脑缺的是运行时安装和操作系统本身，不是".NET 8 比 .NET 10 更能在老 Windows 上跑"。两边都不能靠系统预装保证，自包含发布对两边同样适用。
