.NET 10 WPF 开发效率增强技术栈¶

归档日期：2026-08-25
基础方案：2026-08-25-NET10-WPF推荐技术栈闭环.md
目标：在不改变 .NET 10 LTS + WPF + CommunityToolkit.Mvvm + WPF Fluent Theme 主干的前提下，缩短编码、预览、调试、测试和发布反馈周期。

结论¶

有必要增加一层“开发效率技术栈”，但不应再引入一个大型 UI/MVVM 框架。推荐组合是：

Visual Studio 2026
├─ XAML Hot Reload / Live Preview
├─ Live Visual Tree / Live Property Explorer
├─ XAML Binding Failures
└─ Code Cleanup on Save

WPF 开发
├─ CommunityToolkit.Mvvm Source Generators
├─ XAML 设计时数据 d:
├─ Microsoft.Xaml.Behaviors.Wpf（中型以上 UI）
├─ Product.DesignLab 控件与状态样例库
└─ 公司级 dotnet new 项目/功能模板

工程自动化
├─ .config/dotnet-tools.json
├─ Nerdbank.GitVersioning
├─ OpenAPI 客户端生成：Kiota 或 NSwag，二选一
└─ 显式强类型映射（构造函数 / Factory / 扩展方法）

测试与调试
├─ TimeProvider + Microsoft.Extensions.TimeProvider.Testing
├─ WireMock.Net（HTTP 场景）
├─ Testcontainers（需要真实数据库一致性时）
├─ MSTest STATestMethod（WPF 资源/控件测试）
└─ Snoop WPF

可选增效
├─ GitHub Copilot + 仓库指令
├─ ResX Resource Manager（多语言）
├─ EF Core Power Tools（Database First）
└─ 一套商业控件库（只有复杂控件需求出现时）

最值得优先实施的不是安装更多 NuGet 包，而是以下六项：

用好 Visual Studio 的 XAML 实时工具和绑定错误窗口。
建立 Product.DesignLab，集中展示全部设计令牌、控件和页面状态。
把 ViewModel、Command、属性通知交给 MVVM Toolkit 源生成器。
建立内部 dotnet new 项目模板和功能模板。
用 Fake Time、HTTP Stub 和真实数据库测试构成分层反馈回路。
自动生成版本号和客户端代码；映射由 IDE/Copilot 起草为普通 C#，再审查、测试并提交。

一、增效技术栈分级¶

技术或工具	建议级别	解决的问题	引入条件
XAML Hot Reload / Live Preview	默认启用	修改 XAML 后频繁重启	所有项目
Live Visual Tree / Live Property Explorer	默认启用	查找模板层级、属性来源和布局问题	所有项目
XAML Binding Failures	默认启用	绑定错误只出现在调试输出中、难以定位	所有项目
`d:` 设计时数据	默认规范	Designer 空白、列表和长文本无法预览	所有数据页面
Code Cleanup on Save	默认启用	手工格式化和风格争议	与 `.editorconfig` 配套
MVVM Toolkit Source Generators	默认使用	属性、通知、Command 样板代码	所有 ViewModel
`Product.DesignLab`	默认建立	样式回归、状态遗漏、组件发现困难	从第一个正式页面开始
内部 `dotnet new` 模板	默认建立	每个项目重复搭 Host、MVVM、日志和测试	第一套基线稳定后
本地 .NET Tool Manifest	默认建立	开发机和 CI 的工具版本不一致	使用任意 dotnet tool 时
Nerdbank.GitVersioning	推荐	手工改版本、包和程序集版本不一致	正式发布项目
Snoop WPF	推荐开发工具	运行时视觉树、触发器、DataContext 难查	不便附加调试器或复杂模板时
Microsoft.Xaml.Behaviors.Wpf	中型项目推荐	Event-to-Command、可复用交互行为	出现重复 View 交互时
`TimeProvider` / FakeTimeProvider	按业务必选	时间、延时、超时测试慢且不稳定	有到期、重试、轮询、定时逻辑时
OpenAPI 客户端生成	按联网需求	DTO、URL、序列化和错误处理重复手写	API 有稳定 OpenAPI 契约时
显式强类型映射	默认规范	区分初始化、用户修改和领域转换	所有 DTO、模型和 ViewModel 边界
Mapster	严格按需 POC	纯数据 DTO/模型之间的超大规模机械映射	不进入 Presentation/ViewModel 层
WireMock.Net	按联网测试需求	外部 API 不稳定、错误场景难构造	typed client 或第三方 API 较多时
Testcontainers	按后端需求	SQLite/Mock 无法代表生产数据库	SQL Server 等 provider 特性重要时
ResX Resource Manager	按多语言需求	多语言资源遗漏和横向编辑困难	支持两种及以上语言时
EF Core Power Tools	按数据来源	现有数据库反向工程耗时	Database First 或旧库接入时
GitHub Copilot	团队策略允许时	重复编码、测试草稿、代码解释	完成隐私、许可和审查策略后
商业 WPF 控件套件	严格按需	Grid、Scheduler、Docking、报表等成本过高	自研成本明显高于许可和锁定成本时

二、XAML 与 UI 开发效率¶

1. 把 Visual Studio 的 WPF 工具作为默认工作流¶

每个开发者都应掌握并默认打开：

XAML Hot Reload / Live Preview：在运行数据、认证状态和真实页面上下文中调整 XAML。
Live Visual Tree：定位实际渲染出来的视觉树和模板内部元素。
Live Property Explorer：查看依赖属性当前值以及值的来源。
XAML Binding Failures：把路径错误、DataContext 错误和转换失败当作待修缺陷。
WPF Trace Settings：诊断资源、绑定、动画和数据源问题。

Visual Studio 已支持 WPF 的 XAML Hot Reload；Live Visual Tree 和 Live Property Explorer 可以实时检查运行中元素及其属性。绑定错误窗口对现代 .NET WPF 还能跳转到 XAML 源位置。Microsoft：XAML Hot Reload；Microsoft：XAML 属性实时检查；Microsoft：XAML 数据绑定诊断

团队规则建议：

Debug 会话结束前清空一次 XAML Binding Failures
新增页面不能带有可复现的 Binding Error
不要用 FallbackValue 长期遮蔽绑定路径错误
Hot Reload 不支持的结构性变化，直接重启调试，不绕过设计

2. 统一使用设计时数据¶

使用 d: 命名空间为 Designer 提供数据，设计时内容不会编译进运行时应用。Microsoft：XAML 设计时数据

<UserControl
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="720"
    d:DesignWidth="1280">

    <TextBlock Text="{Binding Title}"
               d:Text="设备运行状态与异常趋势分析" />
</UserControl>

设计时数据至少覆盖：

空列表、1 条、典型数量和大量数据。
中文、英文、超长文本和缺失值。
正常、警告、错误、离线、只读和无权限。
图片加载成功与占位图。

不要让 Designer 直接连接数据库、HTTP 服务或启动后台任务。

3. 建立 `Product.DesignLab`¶

建议新增一个仅用于开发和验收的 WPF 项目：

src/Product.DesignLab/
├─ Tokens/
│  ├─ ColorsPage.xaml
│  ├─ TypographyPage.xaml
│  ├─ SpacingPage.xaml
│  └─ IconsPage.xaml
├─ Controls/
│  ├─ ButtonsPage.xaml
│  ├─ InputsPage.xaml
│  ├─ DataGridPage.xaml
│  └─ DialogsPage.xaml
├─ States/
│  ├─ LoadingEmptyErrorPage.xaml
│  ├─ ValidationPage.xaml
│  └─ DisabledReadOnlyPage.xaml
└─ Accessibility/
   ├─ KeyboardPage.xaml
   └─ HighContrastPage.xaml

它的作用不是再做一个 Demo，而是充当：

设计令牌和组件的可执行文档。
Light、Dark、High Contrast 的集中验收入口。
Hot Reload 调整样式的最短运行路径。
开发者查找组件用法和复制最小示例的目录。
商业控件主题适配和版本升级的回归场。

每个公共组件只有在 DesignLab 中覆盖 Normal / Hover / Pressed / Disabled / Focus / Validation 后，才允许被业务页面使用。

4. 充分使用 MVVM Toolkit 源生成器¶

CommunityToolkit.Mvvm 自带 Roslyn 源生成器，可生成 observable property 和 relay command，减少手工实现 INotifyPropertyChanged 和 ICommand。Microsoft：MVVM Toolkit Source Generators

public partial class OrdersViewModel : ObservableValidator
{
    [ObservableProperty]
    [NotifyCanExecuteChangedFor(nameof(SaveCommand))]
    private string? searchText;

    [ObservableProperty]
    private bool isBusy;

    [RelayCommand(CanExecute = nameof(CanSave), IncludeCancelCommand = true)]
    private async Task SaveAsync(CancellationToken cancellationToken)
    {
        // 调用用例服务
    }

    private bool CanSave() => !IsBusy && !HasErrors;
}

约定：

ViewModel 必须是 partial。
属性变化联动优先使用生成器提供的通知特性和 partial hooks。
异步操作使用生成的 AsyncRelayCommand、CancellationToken 和取消命令。
不要一边使用源生成属性，一边再手写重复属性包装器。
生成代码属于编译产物，不提交、不编辑。

5. `Microsoft.Xaml.Behaviors.Wpf`¶

XAML Behaviors 适合把可复用的 View 交互声明在 XAML 中，例如 Event-to-Command、焦点、选择同步、拖放和滚动到底部。微软维护的项目通过 Microsoft.Xaml.Behaviors.Wpf NuGet 包提供。XamlBehaviorsWpf 官方项目

使用边界：

复用两次以上、与视觉交互有关的逻辑可以做 Behavior。
简单且只属于 View 的事件处理，可以留在 code-behind。
业务规则不能藏进 Behavior。
不要把每一个控件事件都强行转为 Command，导致 XAML 难读。

三、脚手架、模板与仓库工具¶

1. 公司级 `dotnet new` 模板¶

.NET 模板引擎可以将已有的可运行项目或文件打包为项目模板和 item template，并从 NuGet 源统一安装。Microsoft：自定义 dotnet new 模板

推荐维护四个模板：

company-wpf-app
  生成 Host、DI、配置、日志、Fluent Theme、Design Tokens、测试和 CI 基线

company-wpf-feature
  生成 Feature View、ViewModel、状态模型、DI 注册和 ViewModel 测试

company-wpf-control
  生成组件、默认 Style、DesignLab 样例和资源加载测试

company-service
  生成接口、实现、Options、日志和测试文件

模板管理规则：

模板本身必须有构建和冒烟测试。
只有在至少两个项目验证过的模式才回收进模板。
模板版本使用 NuGet 包管理，不通过共享文件夹复制。
新建项目后应能直接执行 restore → build → test → run。
模板负责最佳默认值，不预装所有“未来可能用到”的包。

2. 仓库级本地工具清单¶

把 dotnet-ef、Kiota/NSwag CLI、版本或其他生成工具固定在 .config/dotnet-tools.json，团队和 CI 统一执行 dotnet tool restore。本地工具清单允许不同仓库使用不同工具版本。Microsoft：.NET 本地工具

dotnet new tool-manifest
dotnet tool install dotnet-ef
dotnet tool restore

不要依赖开发机上不可见的 global tool 版本。第三方 .NET Tool 以完全信任方式运行，只安装已审核来源。

3. 自动版本化¶

正式项目可使用 Nerdbank.GitVersioning：用一个 version.json 生成程序集、包和构建版本，并为非正式构建加入 Git commit 标识。该项目位于 dotnet GitHub 组织并受 .NET Foundation 支持。Nerdbank.GitVersioning 官方项目

收益：

用户“关于”页面、日志、安装包、符号和遥测使用同一版本来源。
任意诊断信息可以回查到确切 commit。
CI 不再通过脚本手工修改 .csproj 版本。

版本规则应在 ADR 中写清：正式版、预览版、分支构建、Hotfix 和 MSIX 四段版本如何映射。

4. 大型解决方案加速¶

只有解决方案明显变大后，再按功能建立 .slnf Solution Filter，例如 Client.slnf、Server.slnf、Design.slnf。加载少量项目可以缩短打开、构建和测试时间。Microsoft：Solution Filters

构建异常或速度异常时临时生成 MSBuild 二进制日志：

dotnet build Product.sln -bl:artifacts/logs/build.binlog

二进制日志可能包含路径、属性和导入内容，只作为受控诊断文件保存，不公开上传。Microsoft：MSBuild Binary Log

四、重复代码生成¶

1. OpenAPI 客户端：Kiota 或 NSwag 二选一¶

OpenAPI 契约
→ CI 校验契约
→ 生成 C# Client/DTO
→ 手写一层业务 Facade
→ WPF 只依赖 Facade

选择建议：

场景	建议
标准 OpenAPI、希望使用微软生成器和抽象	Kiota
自有 ASP.NET Core API、已有 NSwag 工作流	NSwag
API 很小且变化少	手写 typed `HttpClient` 反而更清晰

Kiota 可从 OpenAPI 文档生成 C# API 客户端；NSwag 可以从 ASP.NET Core/OpenAPI 生成规范和 C# 客户端。Microsoft：Kiota .NET Client；NSwag 官方项目

规则：

两者只选一个，不在同一客户端混用。
生成命令和配置文件提交仓库，生成器版本固定。
生成结果不得手改；定制放在 partial class、delegating handler 或 facade。
CI 重新生成并检查 Git diff，防止契约和客户端漂移。
认证、重试、correlation ID、遥测和错误归一化由外层处理。

2. 显式强类型映射：默认替代 Mapperly¶

本项目不再默认安装对象映射器：

DTO ↔ Application/Domain Model 使用普通 C# 扩展方法和参数化构造函数。
Model → ViewModel 使用显式构造函数或按用例命名的 Factory。
ViewModel 保留字段式 [ObservableProperty]，构造期间可直接给 backing field 赋值，避免初始化触发通知、验证和 partial hooks。
Visual Studio/GitHub Copilot 可以生成机械映射的普通 .cs 草稿；生成结果必须提交、审查和测试。
不定义全局通用 IMapper，避免把重要转换隐藏成约定。

运行时映射器虽然能看到 MVVM Toolkit 最终生成的属性，但映射 ViewModel 时仍会调用 setter，因此不能解决初始化副作用。Mapster 只允许作为纯 DTO/纯数据模型大规模映射的隔离 POC，禁止以 ViewModel 为目标，并必须用严格配置和 Compile() 做 fail-fast 验证。Mapster 官方项目；Mapster 配置验证

完整决策、代码示例和落地规则见 WPF 项目用显式映射替代 Mapperly。

五、测试反馈速度¶

1. 测试金字塔按反馈时间分层¶

每次保存/本地快速运行
  Domain + Application + ViewModel
  Fake service + Fake TimeProvider + Stub HttpMessageHandler

每次 PR
  上述全部
  SQLite 集成测试
  WireMock HTTP 测试
  资源字典/主题加载测试

Main / Nightly / Release
  Testcontainers 真实数据库
  API Contract
  少量 UI Automation
  安装、升级和启动冒烟

2. `TimeProvider` 和 `FakeTimeProvider`¶

业务代码注入 .NET 的 TimeProvider，测试项目按需引用：

Microsoft.Extensions.TimeProvider.Testing

FakeTimeProvider 可以立即推进时间，稳定测试午夜、夏令时、超时、缓存过期、轮询和重试，不需要真实 Task.Delay。Microsoft：FakeTimeProvider

规则：

业务层不直接散落 DateTime.Now / UtcNow。
内部逻辑使用 UTC，显示层才转换时区。
测试不使用 Thread.Sleep 等待定时行为。

3. WireMock.Net¶

当应用调用多个 HTTP API 时，用 WireMock.Net 在进程内或独立进程模拟真实 HTTP 行为，包括请求匹配、动态响应、延迟、故障和有状态场景。WireMock.Net 官方文档

适合验证：

Header、Token、JSON、查询参数是否符合契约。
429、500、超时、断开、无效 JSON 和慢响应。
重试次数、熔断和取消是否正确。

只有简单 typed client 时，先写自定义 HttpMessageHandler Stub；场景复杂后再引入 WireMock。

4. Testcontainers¶

如果生产环境使用 SQL Server 特性、事务、排序规则、计算列、存储过程或 provider 特有 SQL，SQLite 测试不能完全代表生产环境。Testcontainers for .NET 可以为测试启动临时容器，并要求开发机或 CI 有兼容 Docker API 的容器运行时。Testcontainers for .NET 官方文档

采用策略：

普通开发循环仍保留快速测试。
Testcontainers 放在 Integration 分类，可独立运行。
PR 只运行关键数据库用例；完整集合放 Main/Nightly。
容器镜像版本固定，不使用浮动 latest。
每个测试有独立数据库或可靠的数据清理策略。

5. WPF 资源和组件测试¶

MSTest 4.1 及以后提供 STATestMethod，并可通过 UseSTASynchronizationContext = true 让异步 continuation 回到同一 STA 线程，适合 WPF 资源与控件测试。Microsoft：MSTest 执行控制

建议自动检查：

Light、Dark、High Contrast 资源字典都能加载。
所有语义 token 在每个主题中存在。
公共 Style Key 可以解析。
组件默认模板可以创建并 ApplyTemplate。
关键控件 AutomationProperties 不为空。

[STATestMethod(UseSTASynchronizationContext = true)]
public void DarkTheme_ShouldLoadAllRequiredTokens()
{
    var dictionary = new ResourceDictionary
    {
        Source = new Uri(
            "pack://application:,,,/Product.Themes;component/Theme.Dark.xaml")
    };

    Assert.IsTrue(dictionary.Contains("AppSurfaceBrush"));
    Assert.IsTrue(dictionary.Contains("TextPrimaryBrush"));
    Assert.IsTrue(dictionary.Contains("AccentBrush"));
}

截图测试可作为少量高价值补充，不作为 WPF UI 的主要测试方式；字体、DPI、显卡和系统主题差异会使像素测试变脆弱。

六、运行时 UI 调试¶

Visual Studio 工具不够或无法附加调试器时，可使用 Snoop WPF。它可以浏览运行中 WPF 应用的 visual、logical 和 automation tree，查看/修改属性、触发器和 DataContext；项目声明支持 .NET 6—10。Snoop WPF 官方项目

适合：

Popup、ContextMenu、ControlTemplate 内部元素难以定位。
第三方控件或深层资源覆盖问题。
用户环境可以复现，但开发环境附加调试困难。
检查 UI Automation tree。

Snoop 仅作为开发/诊断工具，不随正式应用一起分发。对生产或高权限进程注入前应遵循组织安全策略。

七、数据库与本地化增效¶

1. EF Core Power Tools¶

现有 SQL Server/Azure SQL 数据库采用 Database First 时，可以按需安装 EF Core Power Tools。它提供 Visual Studio/CLI 反向工程、迁移和模型可视化；项目当前要求可安装 .NET 8 或 .NET 10 runtime。EF Core Power Tools 官方项目

不应把它用于绕过数据库变更流程。反向工程配置需要提交仓库，重新生成结果需要代码审查。

2. ResX Resource Manager¶

多语言项目继续使用 .resx 和强类型资源，使用 ResX Resource Manager 横向查看所有语言、查找未翻译和孤立资源，并可用脚本导出或检查资源。该项目受 .NET Foundation 支持并支持 WPF。ResX Resource Manager 官方项目

只支持一种语言的项目不需要提前引入完整本地化工具链，但 UI 文本仍应尽量集中，避免散落硬编码。

八、控件库如何真正提高效率¶

基础按钮、输入框、导航、卡片和普通 DataGrid 继续使用 WPF + 内置 Fluent Theme。只有出现以下需求才评估第三方控件：

Excel 级 DataGrid、百万行虚拟化、复杂分组/汇总/导出。
Scheduler、Gantt、Docking、Diagram、PivotGrid。
PDF/Office 文档查看、编辑、打印和导出。
最终用户报表设计器或仪表盘。
高性能实时图表。

推荐评估路径：

需求	首选评估
单一高性能科学/工业图表	`ScottPlot.WPF`
动画、MVVM 友好的常规业务图表	`LiveChartsCore.SkiaSharpView.WPF`
完整企业控件套件	DevExpress、Telerik、Syncfusion 三选一做 POC
普通按钮、文本框、主题	不引入第三方主题库

ScottPlot 和 LiveCharts2 均提供 WPF 包；DevExpress、Telerik 和 Syncfusion 提供 Grid、Chart、Scheduler、Docking、文档或报表等不同组合。ScottPlot WPF；LiveCharts2 WPF；DevExpress WPF；Telerik UI for WPF；Syncfusion WPF

POC 验收必须包含：

.NET 10 正式支持
Light / Dark / High Contrast
Design Tokens 适配成本
MVVM 和异步数据加载
键盘、Narrator、UI Automation
100%–200% DPI 和多显示器
目标数据量和更新频率
MSIX、单文件或自包含发布
许可、离线构建、升级和长期支持

只选一套企业控件库。把第三方控件放在 Product.Presentation.Controls 的薄适配层后，不让业务层依赖厂商类型。不要为了获得几个控件而替换整个 Fluent Theme。

九、AI 辅助开发¶

Visual Studio 2026 的 GitHub Copilot 可以做多文件修改、运行命令、生成测试和迭代修复；仓库可通过 .github/copilot-instructions.md 提供统一上下文。Microsoft：Visual Studio Copilot Agent Mode；GitHub：仓库自定义指令

建议仓库指令至少写明：

目标框架为 .NET 10 WPF，使用 C# 14 和 Nullable。
ViewModel 使用 CommunityToolkit.Mvvm 源生成器。
UI 基于内置 WPF Fluent Theme 和现有 Design Tokens。
禁止另加整套主题/MVVM 框架，除非 ADR 已批准。
业务逻辑不能进入 code-behind、Behavior 或 converter。
生成代码禁止手改。
提交前执行指定 restore、format、build 和 test 命令。
日志不得包含 token、密码、个人信息和业务敏感正文。

AI 使用边界：

AI 生成的是候选修改，不是审查结论。
必须由人检查 diff、依赖、许可、安全和 UI 状态。
必须经过编译、测试、Analyzer 和可访问性检查。
不向未经批准的模型输入源代码、密钥、日志或客户数据。
不允许 AI 自动合并、签名或直接推送生产发布。

Copilot 测试功能可以基于 C# 代码生成并运行测试，但仍需检查测试是否验证了真实业务行为，而不是只迎合当前实现。Microsoft：Copilot .NET 测试

十、推荐的解决方案结构补充¶

在原有结构上增加以下内容：

Product/
├─ .config/
│  └─ dotnet-tools.json
├─ .github/
│  ├─ copilot-instructions.md       # 采用 Copilot 时
│  └─ workflows/                    # 或 Azure Pipelines
├─ eng/
│  ├─ templates/                    # dotnet new 模板源码
│  ├─ scripts/                      # 跨环境构建/验证入口
│  └─ package/                      # 打包配置
├─ src/
│  ├─ Product.App/
│  ├─ Product.Core/
│  ├─ Product.Infrastructure/
│  ├─ Product.Themes/               # 多应用共享主题时
│  └─ Product.DesignLab/            # 可执行组件目录
├─ tests/
│  ├─ Product.Core.Tests/
│  ├─ Product.Infrastructure.Tests/
│  ├─ Product.ContractTests/
│  ├─ Product.ThemeTests/
│  └─ Product.UiTests/
├─ Directory.Build.props
├─ Directory.Packages.props
├─ global.json
├─ version.json
└─ Product.sln

十一、推荐包和工具清单¶

不要一次全部安装。以下是在原闭环技术栈基础上的增量清单。

中型以上 WPF UI¶

Microsoft.Xaml.Behaviors.Wpf

测试¶

Microsoft.Extensions.TimeProvider.Testing  # 存在时间逻辑时
WireMock.Net                               # HTTP 场景复杂时
Testcontainers.MsSql                      # SQL Server 集成测试时

代码生成与显式映射¶

Microsoft.OpenApi.Kiota                   # 选择 Kiota 时，通常作为本地工具
NSwag.MSBuild 或 NSwag.ConsoleCore         # 选择 NSwag 时
普通 C# 构造函数/Factory/扩展方法             # 映射默认方案，无新增包
Mapster                                   # 仅纯数据模型大规模映射 POC

工程工具¶

Nerdbank.GitVersioning                    # 正式版本自动化
dotnet-ef                                 # 仓库级本地工具

开发机工具¶

Snoop WPF
ResX Resource Manager                     # 多语言时
EF Core Power Tools                       # Database First 时
GitHub Copilot                            # 团队策略允许时

可选 Analyzer¶

.NET 10 SDK 已内置 Roslyn 代码质量和代码风格 Analyzer，先使用 latest-recommended 并通过 .editorconfig 调整。只有团队确认新增规则信噪比足够时，再评估 Meziantou.Analyzer 等第三方 Analyzer；不要叠加多套高度重合的规则。Microsoft：.NET Code Analysis

十二、不建议为了“效率”默认引入的技术¶

技术类别	不默认引入的原因	何时再考虑
Prism 等完整 WPF 应用框架	与 Toolkit、Host、导航抽象重叠，学习和约束增加	真正存在模块化、插件、Region 导航等需求
ReactiveUI / DynamicData	引入新的响应式编程范式	高频数据流、复杂派生集合已难用普通 MVVM 表达
MediatR 式进程内总线	简单桌面用例会被包装成大量 handler	用例数量大且跨切面管线价值明确
自动映射到 ViewModel	会触发通知、验证和 hook，并隐藏初始化语义	使用显式构造函数/Factory
全局通用 `IMapper`	依赖关系和用例语义被统一入口隐藏	使用按类型和用途命名的映射方法
全套第三方主题库	与 .NET 10 Fluent Theme 和自己的 tokens 冲突	不采用内置 Fluent Theme 的项目另行决策
多套企业控件库	主题、许可、包体、升级和人才成本叠加	不建议；统一选一套
大量截图测试	DPI、字体、GPU 和系统主题导致脆弱	仅用于少量稳定的高价值视觉基线
全局安装未固定版本的 CLI	开发机和 CI 结果漂移	改为本地 tool manifest
AI 自动接受/自动合并	容易引入错误依赖、虚假测试和安全问题	始终保留人工审查和质量门禁

十三、落地顺序¶

第 1 步：当天完成¶

启用 XAML Hot Reload、Live Visual Tree 和 Binding Failures
启用 Code Cleanup on Save
统一 d: 设计时数据规范
确认 MVVM Toolkit 全部使用源生成写法

第 2 步：1—2 天¶

建立 Product.DesignLab
增加 ThemeTests 和核心 ViewModel 测试
引入 TimeProvider 测试基线
建立 .config/dotnet-tools.json

第 3 步：基线稳定后¶

打包 company-wpf-app / feature / control 模板
接入 Nerdbank.GitVersioning
把模板创建、构建和测试加入 CI

第 4 步：按真实需求¶

联网多 → Kiota/NSwag + WireMock
映射多 → 先用 IDE/Copilot 生成显式映射；仅纯数据边界再 POC Mapster
生产数据库特性多 → Testcontainers
旧数据库 → EF Core Power Tools
多语言 → ResX Resource Manager
复杂 Grid/Chart/Report → 一套控件库 POC
团队允许 AI → Copilot + 仓库指令 + 人工门禁

十四、开发效率闭环¶

flowchart LR
    A[内部模板创建功能骨架] --> B[DesignLab / d: 数据快速预览]
    B --> C[Hot Reload 开发 UI]
    C --> D[MVVM / API / Mapping 源生成]
    D --> E[Fake Time / Stub / WireMock 快速测试]
    E --> F[Analyzer / Format / Build]
    F --> G[真实 DB / UI / 安装分层验证]
    G --> H[Git 版本自动化与发布]
    H --> I[日志、遥测和用户反馈]
    I --> J[补回归测试、规则或模板]
    J --> A

闭环的关键是：线上发现的重复缺陷不能只修一次。应根据问题性质回写为以下一种资产：

可复现的自动化测试。
Analyzer / .editorconfig 规则。
DesignLab 中的状态样例。
项目或功能模板改进。
API 契约检查。
开发文档和 ADR。

这样，后续功能和后续项目会自动继承这次修复带来的效率收益。

最终推荐组合¶

对于典型中型联网 WPF 企业应用，推荐在原闭环上实际增加：

必做
├─ VS XAML Hot Reload / Live Visual Tree / Binding Failures
├─ d: Design-time Data
├─ CommunityToolkit.Mvvm Source Generators
├─ Product.DesignLab
├─ company-wpf-app / feature / control 模板
├─ .NET local tool manifest
├─ Nerdbank.GitVersioning
├─ TimeProvider + FakeTimeProvider
└─ Snoop WPF

出现需求再加
├─ Microsoft.Xaml.Behaviors.Wpf
├─ Kiota 或 NSwag
├─ Mapster（仅纯数据模型边界 POC）
├─ WireMock.Net
├─ Testcontainers
├─ EF Core Power Tools
├─ ResX Resource Manager
├─ GitHub Copilot
└─ 一套图表或企业控件库

这套增效层不会破坏原有技术栈边界：WPF 仍负责 View，CommunityToolkit.Mvvm 仍负责 ViewModel，Generic Host 仍负责应用基础设施，Fluent Theme 和 Design Tokens 仍是唯一视觉基线；新增工具只负责减少机械工作并缩短反馈时间。