Prism导航核心机制详解：注册、参数、生命周期与模块化实践

1. Prism 导航的设计思路：它解决的不只是“换个页面”

我用 Prism 写过几个 WPF 项目，说实话，最早接触导航这块的时候，第一反应是“这不就是换 UserControl 吗，为什么搞这么复杂”。但真刀真枪啃完源码、跑完几个 Demo 之后，我改变看法了：Prism 的导航不是“换个内容”，而是一套完整的 UI 流程管理机制，它把“显示哪个页面”“怎么传数据”“页面离开时做什么”“能不能回到上一个页面”这些琐碎问题全部收纳到一个统一框架里，我只需要关注业务，不用每次手写一堆耦合极高的切换逻辑。

对 WPF 开发者来说，传统做法通常是ContentControl.Content直接赋值，或者搞一个Window一堆Visibility切换。这种写法在小项目里跑得很欢快，但一旦页面数量增长到十几个、或者由多个团队各自维护模块时，问题马上就暴露了：页面之间互相持有对方的 View 实例，改一个页面很容易影响另一个页面的初始化逻辑。

Prism 导航的核心理念是把“目标页面”抽象成可注册的视图，由统一的IRegionManager来调度。我要去哪个页面、带什么参数、导航过程中哪个对象需要被通知、能否确认离开，这些行为都被接口化、生命周期化了。也就是说，导航不再是一行赋值代码，而是整个模块化前端架构的“交通系统”。

这套机制特别适合以下几类场景：

• 多模块解决方案，每一个模块独立维护自己的页面和 ViewModel，但需要通过导航串联在一起。
• 需要频繁在列表页和详情页之间跳转、且要保留上次操作上下文的业务系统。
• 需要统一处理页面切换前后的业务逻辑，比如离开前校验、切回时刷新数据的场景。
• 需要用对话框（Dialog）完成轻量交互、并且对话框本身也想复用导航参数的项目。

我见过不少人把 Prism 导航拿来和网页端路由做类比，这个思路其实挺准的。WPF 里的 Region 相当于路由出口，RequestNavigate相当于Navigate，NavigationParameters相当于 URL 查询参数，INavigationAware相当于路由守卫。如果你带着这层理解去看 Prism 的 API，上手难度会低很多。

接下来的内容，我会把 Prism 导航的核心机制、模块化开发、模块间通信、对话服务这几块拆开讲透，所有代码示例都用精简版，方便你直接拿去改。最后还会专门讲测试怎么写，以及我这些年踩过的坑。

2. 核心机制拆解：注册、请求、参数、生命周期

2.1 先把导航目标注册好：RegisterForNavigation

Prism 里想让一个 View 能作为导航目标，不是直接把它扔进 Region 就能用的。最正统的做法是在模块初始化阶段调用RegisterForNavigation，把 View 注册到容器里。这个注册动作有两个作用：第一，让容器知道这个 View 的存在，后续通过名字解析；第二，建立 View 和 ViewModel 的绑定关系，导航过去时可以自动组装实例。

举个例子。假设我有一个主窗口，主窗口的MainWindow.xaml里放了一个ContentControl，给它一个 Region 名字：

<ContentControl prism:RegionManager.RegionName="MainContentRegion" />

然后在模块的RegisterTypes或者Initialize方法里，把两个页面注册成导航目标：

public class MainModule : IModule { public void OnInitialized(IContainerProvider containerProvider) { var regionManager = containerProvider.Resolve<IRegionManager>(); regionManager.RegisterViewWithRegion("MainContentRegion", typeof(HomeView)); } public void RegisterTypes(IContainerRegistry containerRegistry) { containerRegistry.RegisterForNavigation<HomeView>(); containerRegistry.RegisterForNavigation<DetailView>(); containerRegistry.RegisterForNavigation<SettingsView>(); } }

这里有个细节值得注意：RegisterViewWithRegion是区域创建时立刻往 Region 里装一个默认视图，而RegisterForNavigation只是注册“导航预案”，真正被导航过去时才构造实例。我在实际项目中的习惯是：启动时要显示的默认页用RegisterViewWithRegion，其余页面全部走RegisterForNavigation，这样职责清晰，也不会在启动时把一堆页面全部实例化导致内存浪费。

2.2 发起导航：RequestNavigate 的常规用法和位置选择

导航动作的核心调用长这样：

regionManager.RequestNavigate("MainContentRegion", "DetailView");

第一参数是 Region 名字，第二参数是注册时用的目标页面名字。如果目标页面需要接收参数，就再加第三个参数：

var parameters = new NavigationParameters { { "userId", 1001 }, { "from", "list" } }; regionManager.RequestNavigate("MainContentRegion", "DetailView", parameters);

参数NavigationParameters本质上是一个 key-value 的集合，传进去之后，目标页面的 ViewModel 可以在OnNavigatedTo里取出来。使用上非常轻量。

实际做项目时，请求导航的代码通常不是直接散落在 View 的 CodeBehind 里，而是在 ViewModel 里用IRegionManager。为此需要把IRegionManager通过构造函数注进去：

public class HomeViewModel : BindableBase { private readonly IRegionManager _regionManager; public HomeViewModel(IRegionManager regionManager) { _regionManager = regionManager; NavigateCommand = new DelegateCommand(ExecuteNavigate); } public DelegateCommand NavigateCommand { get; } private void ExecuteNavigate() { _regionManager.RequestNavigate("MainContentRegion", "DetailView", new NavigationParameters { { "userId", 1001 } }); } }

还有一个容易踩坑的点：如果你在 View 的 CodeBehind 里拿RegionManager，尤其是给 Button 绑定了点击事件再调用RegionManager.RequestNavigate，必须确认这个 View 的RegionManager实例确实是当前 Region 所属的那个。最稳妥的做法是让 ViewModel 通过构造注入拿IRegionManager，工具会自动帮你解析到正确实例。

2.3 导航参数传递：NavigationParameters 的完整用法

很多刚上手的朋友会问：为啥不用普通的方法参数或属性直接传值？答案其实简洁——导航参数必须满足“一次导航携带、目标页面取出、返回时可重置”这样的生命周期要求，普通属性做不到这类标准流程。

NavigationParameters常用用法有三种：基本 key-value、嵌套参数、全局参数。

基本用法上面已经写了。嵌套参数的场景适合传复杂对象，比如列表页点了一行，要把整个商品对象带过去：

var parameters = new NavigationParameters(); parameters.Add("product", new Product { Id = 88, Name = "机械键盘", Price = 699 });

目标页面的 ViewModel 里取的时候，直接反序列化：

public void OnNavigatedTo(NavigationContext navigationContext) { if (navigationContext.Parameters.TryGetValue("product", out Product product)) { // 把 product 塞给界面上绑定的属性 CurrentProduct = product; } }

TryGetValue这个方法很实用，不用先ContainsKey再取，一步到位。

还有一种场景：导航到目标页之后，目标页里可能又发起一次子导航，但想把最外层带来的参数继续往下传。Prism 提供了一个简便写法：

var parameters = navigationContext.Parameters; var childParameters = new NavigationParameters(); foreach (var kvp in parameters) { childParameters.Add(kvp.Key, kvp.Value); } _regionManager.RequestNavigate("ChildRegion", "ChildView", childParameters);

这种“参数接力”在联动页面里非常常见。当然你也可以在目标页面里先把参数存成属性，再在OnNavigatedTo中带入子区域，但我个人更习惯上述写法，语义直接。

2.4 生命周期感知：INavigationAware 的三个关键时刻

INavigationAware是 Prism 导航最核心的接口之一。它定义了导航前后目标对象需要响应的方法，主要用于维持页面状态和上下文。

接口长这样：

public interface INavigationAware { void OnNavigatedTo(NavigationContext navigationContext); void OnNavigatedFrom(NavigationContext navigationContext); bool IsNavigationTarget(NavigationContext navigationContext); }

三个方法的职责不同：

• OnNavigatedTo：导航到当前页面时触发。首次进入和从其他页面返回时都会触发。适合在这里做数据加载、参数解析、界面初始化。
• OnNavigatedFrom：离开当前页面时触发。适合保存草稿、清理资源、通知其他模块。
• IsNavigationTarget：Prism 内部判断“这个页面的实例是否可以被复用来接收导航”。如果返回true，导航到这个页面时可能复用之前的实例，而不是新建一个；返回false则每次导航都新建。

第三个方法很多人容易忽略，但它恰恰决定了页面的“单例性”。举个例子：列表页点每一行进详情页，如果你希望每次进来都是全新详情页，那IsNavigationTarget返回false就行；如果希望详情页始终保持同一个实例、只刷新数据，“返回true并更新数据”就是你想要的效果。

对于页面是否重建这件事，我实际项目的处理习惯也很直接：详情页一般每次重建，因为数据不同；设置页或者状态型页面，就保留单实例，避免用户改了一半配置，切出去再切回来，配置全丢了。

2.5 导航确认机制：IConfirmNavigationRequest

有一种场景是“弹窗问用户是否离开”。比如在填写表单的页面点返回，页面需要先弹确认框，用户选“确定”才能导航走，选“取消”则留在当前页。这就要用到IConfirmNavigationRequest。

public class FormViewModel : BindableBase, IConfirmNavigationRequest { public void ConfirmNavigationRequest(NavigationContext navigationContext, Action<bool> continuationCallback) { bool result = true; if (HasUnsavedChanges) { // 弹一个对话框让用户确认 result = MessageBox.Show("有未保存的修改，确定离开吗？", "确认", MessageBoxButton.YesNo) == MessageBoxResult.Yes; } continuationCallback(result); } }

这个接口的设计值得多说一句：它没有用同步阻塞的方式等待用户选择，而是提供了一个continuationCallback回调，目的是让实现方可以选择真正的异步操作（比如等待用户异步点击）再回调结果。如果直接在ConfirmNavigationRequest里MessageBox.Show，其实是同步的，但接口允许你插入任何异步弹窗逻辑，比如 Prism 的IDialogService。

我在实际项目里，凡是涉及“长表单”“关键操作确认”“编辑未保存状态”的页面，都会实现这个接口，否则用户不小心点错导航，数据就白白丢失。

3. 模块化开发与模块间通信

3.1 模块化开发：如何划分模块，以及模块和导航的关系

Prism 的模块化开发核心是IModule。每个模块可以单独定义自己的 View、ViewModel、服务、配置，在应用启动时按需加载。这样做最大的好处就是职责边界清楚，多人协作时互不干扰。

一个典型模块的定义：

public class OrderModule : IModule { public void RegisterTypes(IContainerRegistry containerRegistry) { containerRegistry.RegisterForNavigation<OrderListView>(); containerRegistry.RegisterForNavigation<OrderDetailView>(); containerRegistry.RegisterDialog<EditOrderDialog, EditOrderDialogViewModel>(); } public void OnInitialized(IContainerProvider containerProvider) { // 可以在初始化时定位到某个 Region 放默认页 var regionManager = containerProvider.Resolve<IRegionManager>(); regionManager.RegisterViewWithRegion("OrderRegion", typeof(OrderListView)); } }

在实际项目里，我习惯把每个业务线拆成一个独立模块。比如订单模块、客户模块、报表模块、系统设置模块。每个模块自己负责导航注册、对话服务注册、模块内部服务注册。这样做最大的收益是：删掉某个模块时，只要去掉加载配置，模块相关的页面对话框就会全部失效，但不会影响其他模块编译和运行。

导航在模块化开发里的角色，说直白点就是“模块之间的粘合剂”：订单模块的列表页，导航跳转到客户模块的详情页，是不需要直接引用客户模块页面的，只需要知道对方注册的导航名字，通过RegionManager请求即可。这样耦合度很低，后续替换某个页面实现或者调整命名，影响面都可以控制住。

3.2 模块间通信的三条主路径

模块之间需要互相传数据、发通知，最常用的三条路径分别是：

• 事件聚合器（IEventAggregator）：松耦合的发布/订阅模式，适合“我不知道谁关心这件事，但我要发出去”的场景。
• 共享服务：在容器里注册单例服务，模块 A 写入数据，模块 B 读取数据，适合状态共享场景。
• 导航参数：通过RequestNavigate传递参数，适合页面跳转时直接传值的场景。

这三条路径各有适合的场景，我画个表方便大家理解：

3.3 事件聚合器实战细节

事件聚合器的用法很经典。先在某个公共位置定义事件类，或者放在模块内再被其他模块引用（这就是模块间“仅依赖事件类型，不依赖对方模块”的关键）：

public class UserLoggedInEvent : PubSubEvent<UserInfo> { }

发送方发布事件：

public class LoginViewModel : BindableBase { private readonly IEventAggregator _eventAggregator; public LoginViewModel(IEventAggregator eventAggregator) { _eventAggregator = eventAggregator; } public void Login() { // 登录成功后 _eventAggregator.GetEvent<UserLoggedInEvent>().Publish(currentUser); } }

订阅方接收：

public class HeaderViewModel : BindableBase, IDisposable { private readonly SubscriptionToken _token; public HeaderViewModel(IEventAggregator eventAggregator) { _token = eventAggregator.GetEvent<UserLoggedInEvent>() .Subscribe(OnUserLoggedIn, ThreadOption.UIThread); } private void OnUserLoggedIn(UserInfo user) { // 更新界面 } public void Dispose() { _token.Dispose(); } }

这里的几个细节值得强调：

• ThreadOption.UIThread：如果订阅方要更新 UI，必须指定这个参数，否则事件可能在后台线程发布，UI 更新会抛异常。
• SubscriptionToken：订阅时会返回一个 token，用完之后调用Dispose()退订。如果 ViewModel 要释放，但在释放时忘了退订，事件聚合器一直持有订阅引用，被订阅的对象就永远无法被垃圾回收，这在长生命周期页面里就是致命的内存泄漏。
• 使用弱引用：Subscribe方法有一个keepSubscriberReferenceAlive参数，默认是false也就是弱引用。如果你显式传了true，就一定要负责退订，否则泄漏概率非常高。

在实际项目里，我最常用事件聚合器的场景是：用户登录/退出后全应用刷新用户状态、数据保存成功后通知列表页刷新、权限变化后通知各模块重置界面按钮可用性。

3.4 用导航参数做模块间通信：什么时候适合、什么时候别硬上

导航参数最大的特点是“跟着页面走”，它的生命周期就是一次导航过程。目标页面OnNavigatedTo拿到参数后，如果你不手动保存，参数就完成了使命。

适合用导航参数的场景：

• 列表页 → 详情页，传递 ID 或实体对象。
• 主页面 → 子模块页面，告诉模块当前上下文。
• 步骤向导，上一步收集的数据通过参数传到下一步。

不适合用导航参数的场景：

• 全局状态（比如用户信息、权限集合），这些更合适放入共享服务。
• 跨模块的长期数据同步（比如库存数量被多个页面同时引用），更应该用共享服务加事件通知。

我见过一个项目，把用户对象每个页面都通过导航参数传来传去，结果权限一改，所有页面都要跟着改签名，改到想哭。后来重构，把用户信息注册成共享单例服务，导航参数里只留一个userId，瞬间清爽了很多。

4. 对话服务（DialogService）的实战用法

4.1 对话服务解决的痛点和适用场景

WPF 原生弹窗用起来有点别扭：如果要弹一个带数据、带逻辑的编辑器，你得先 new 一个 Window，设置 Owner，初始化数据，ShowDialog()，然后在主窗口里再读取弹窗的结果。这套流程代码分散、高度耦合，弹窗的 ViewModel 没法做测试。

Prism 的IDialogService把弹窗抽象为“对话服务 + 可注册的对话窗口 + 统一的对话框生命周期回调”，弹出的内容本身也是一个 View + ViewModel，注册方式与导航页面类似。

适用场景：

• 新增/编辑表单弹窗。
• 删除确认。
• 选择器弹窗（比如选择部门、选择人员、选择商品）。
• 全局提示窗口。

我自己用得最多的就是表单弹窗和选择器弹窗。特别是“从列表弹窗选一条数据回填”这类场景，如果没有对话服务，代码会重复得让人怀疑人生。

4.2 注册与调用：RegisterDialog + ShowDialog

注册方式在模块的RegisterTypes里：

containerRegistry.RegisterDialog<EditOrderDialog, EditOrderDialogViewModel>();

RegisterDialog有两个泛型参数，第一个是 View，第二个是 ViewModel。Prism 会把二者绑定到Dialog区域，并自动完成DataContext装配。调用方式：

public class OrderListViewModel : BindableBase { private readonly IDialogService _dialogService; public OrderListViewModel(IDialogService dialogService) { _dialogService = dialogService; } public void OpenEditDialog(Order order) { var parameters = new DialogParameters(); parameters.Add("order", order); parameters.Add("title", "编辑订单"); _dialogService.ShowDialog("EditOrderDialog", parameters, callback => { if (callback.Parameters.TryGetValue("result", out bool result) && result) { // 用户点了保存，刷新列表 LoadOrders(); } }); } }

ShowDialog第一个参数是注册时使用的对话框名字EditOrderDialog，这个名字默认是 View 的类型名，你也可以在注册时用重载版本指定别名。第二个参数是DialogParameters，和NavigationParameters类型很像，结构一样，用法也一致。第三个参数是关闭后的回调，在对话框关闭时触发。

顺带提一句：ShowDialog可以传IDialogParameters，回调里的IDialogResult包含Parameters，拿到的result就是在对话框 ViewModel 里放进来的结果。这是标准的双向数据返回通道。

4.3 自定义对话框 ViewModel 的规范写法

对话框的 ViewModel 需要实现IDialogAware接口。这个接口既包含了导航感知的类似方法，还多了两个关键成员：Title和RequestClose。

标准写法：

public class EditOrderDialogViewModel : BindableBase, IDialogAware { private string _title; private Order _currentOrder; public EditOrderDialogViewModel() { SaveCommand = new DelegateCommand(ExecuteSave); CancelCommand = new DelegateCommand(ExecuteCancel); } public string Title { get => _title; set => SetProperty(ref _title, value); } public DelegateCommand SaveCommand { get; private set; } public DelegateCommand CancelCommand { get; private set; } public bool CanCloseDialog() { // 如果需要拦截关闭，可以在这里判断 return true; } public void OnDialogClosed() { // 清理工作，退出订阅等 } public void OnDialogOpened(IDialogParameters parameters) { if (parameters.TryGetValue("order", out Order order)) { _currentOrder = order; } if (parameters.TryGetValue("title", out string title)) { Title = title; } } private void ExecuteSave() { var result = new DialogResult(ButtonResult.OK) { Parameters = new DialogParameters { { "result", true } } }; RequestClose?.Invoke(result); } private void ExecuteCancel() { RequestClose?.Invoke(new DialogResult(ButtonResult.Cancel)); } public event Action<IDialogResult> RequestClose; }

这里有几个容易忽略的要点：

• RequestClose是一个事件，View 在内部订阅它，调用时就执行关闭；你需要在合适的业务时机触发它。
• DialogResult构造函数传ButtonResult.OK或ButtonResult.Cancel，但在回调里判断结果，我还是更推荐通过Parameters传一个自定义布尔值，因为有些场景“OK 但取消”并存。
• OnDialogOpened是真正拿到参数的地方，和导航参数的取法完全一致。

4.4 对话服务返回结果后的常见处理套路

对话框关闭后的回调里，经常要区分“保存成功”“取消”“删除成功”等不同结果。

我是这么处理的：约定每种结果向Parameters里放一个result键和一个可选的message键。回调里先判断result，再按分支执行。

_dialogService.ShowDialog("ConfirmDeleteDialog", parameters, callback => { if (callback.Result == ButtonResult.OK) { bool confirmed = callback.Parameters.GetValue<bool>("confirmed"); if (confirmed) { DeleteOrder(orderId); } } });

关于对话框关闭后刷新数据这个问题，我在这里提前提醒一下：如果关闭对话框后你需要刷新所属页面，不要在对话框的 ViewModel 里直接通过事件去通知列表页，而是利用回调或者在对话框内触发一个全局事件，由列表页自己订阅处理。这样列表页的刷新逻辑才能保持内聚，不至于出现“对话框把列表页状态改掉一半”的诡异局面。

5. 测试代码：导航逻辑、通信和对话服务怎么测

5.1 为什么 Prism 应用更适合写测试

Prism 这套设计天然对测试友好。因为导航、通信、数据绑定都是通过接口或注册机制完成的，测试时只要把真实实现换成一个 Mock，就能把 ViewModel 隔离出来测。这在原生 WPF 的 CodeBehind 代码里几乎不可能做到。

我做项目时，对 ViewModel 的测试原则很简单：不启动界面、不依赖真实 RegionManager、不依赖真实 DialogService，凡是外部依赖全部注入 Fake 或者 Mock。测什么？主要测导航方法是否被正确调用、参数是否正确传递、收到事件后属性是否更新。

5.2 导航逻辑的单元测试套路

先准备一个假的IRegionManager。Prism 里RegionManager本身是个具体类，但它实现了接口，我们在测试中可以直接用 Mock 库动态伪造。

详细代码：

[Test] public void NavigateToDetail_WhenCommandExecuted_ShouldRequestNavigate() { // Arrange var mockRegionManager = new Mock<IRegionManager>(); var viewModel = new HomeViewModel(mockRegionManager.Object); var navigationParams = new NavigationParameters { { "userId", 1001 } }; // Act viewModel.NavigateCommand.Execute(); // Assert mockRegionManager.Verify( rm => rm.RequestNavigate( "MainContentRegion", "DetailView", It.IsAny<NavigationParameters>()), Times.Once); }

但这里有个细节：RequestNavigate有很多重载，验证时如果直接匹配"DetailView"可能因为参数重载导致验证失败。稳妥的做法是使用It.Is匹配那个NavigationParameters对象：

mockRegionManager.Verify( rm => rm.RequestNavigate( "MainContentRegion", "DetailView", It.Is<NavigationParameters>(p => p["userId"].ToString() == "1001")), Times.Once);

还要注意RequestNavigate的签名里有一个Action<NavigationResult>回调参数，通常我们传 null 或者空方法。验证时也要对这个回调做匹配，用It.IsAny<Action<NavigationResult>>()。

5.3 测试带参导航的目标页面

目标页面的 ViewModel 实现了INavigationAware，测试时直接调用它的OnNavigatedTo，把构造好的NavigationContext传进去，然后断言属性有没有被设置。

[Test] public void OnNavigatedTo_WhenUserIdProvided_ShouldSetCurrentUserId() { // Arrange var viewModel = new DetailViewModel(); var parameters = new NavigationParameters { { "userId", 1001 } }; var context = new NavigationContext(null, parameters); // Act viewModel.OnNavigatedTo(context); // Assert Assert.AreEqual(1001, viewModel.CurrentUserId); }

上面的NavigationContext构造函数第一个参数是导航目标，测试中传null完全没问题，因为我们只关心Parameters的读取。

一个经常会遇到的小坑是：NavigationContext的构造函数在当前版本的 Prism 中可能是 internal，未必能在测试程序集里直接访问。如果遇到这种情况，用Mock<IRegionNavigationService>生成一个假的导航服务，再用它构造NavigationContext。或者，直接通过RegionNavigationService的公开方法，引发一次真实的导航流程，再断言结果。不过后者对环境要求高，我更推荐 Mock 导航服务的方式。

5.4 模块间通信和对话服务的测试重点

事件聚合器的测试重点不在订阅/发布本身，而在“收到事件后 ViewModel 做了什么”。测试时直接实例化EventAggregator，发布事件，再断言订阅方的状态。

[Test] public void UserLoggedIn_ShouldUpdateDisplayName() { var eventAggregator = new EventAggregator(); var headerViewModel = new HeaderViewModel(eventAggregator); eventAggregator.GetEvent<UserLoggedInEvent>().Publish(new UserInfo { DisplayName = "小明" }); Assert.AreEqual("小明", headerViewModel.DisplayName); }

这个小测试验证了 ViewModel 对事件的响应，不需要真实启动 WPF 窗体。由于事件是在后台线程发布的，如果HeaderViewModel的订阅指定了ThreadOption.UIThread，单元测试环境没有Dispatcher，执行Publish时会抛异常。这一点需要特别注意：在单元测试里订阅事件尽量用ThreadOption.PublisherThread或者ThreadOption.BackgroundThread，也可以给测试项目注入一个假的IDispatcher。Prism 在较新版本中把 UI 调度抽象成了IDispatcher，相当于给了测试一个好出口。

对话服务的测试就更直接了。构造一个DialogService，注册一个假的对话框（或者用 Mock 的IDialogService），然后验证 ShowDialog 是否被调用、参数是否正确。

[Test] public void OpenEditDialog_ShouldPassOrderParameter() { var mockDialogService = new Mock<IDialogService>(); var viewModel = new OrderListViewModel(mockDialogService.Object); var order = new Order { Id = 88 }; viewModel.OpenEditDialog(order); mockDialogService.Verify( d => d.ShowDialog( "EditOrderDialog", It.Is<DialogParameters>(p => p.TryGetValue("order", out Order o) && o.Id == 88), It.IsAny<Action<IDialogResult>>()), Times.Once); }

对话服务本身不需要做真实弹窗，测试的目的是确保 ViewModel 在正确的时机、用正确的参数调用了正确的对话框。

6. 常见问题与排查技巧实录

6.1 导航不生效：先检查是不是这四种原因

第一种：Region 名字不一致。界面上RegionName="MainContentRegion"和代码里RequestNavigate("MainContentRegion", ...)必须严格一致。这个错误最常见，而且经常是改了 XAML 忘了改代码，或者反过来。排查方式很简单，在RequestNavigate外面加一个Debug.WriteLine，看传入的 Region 名是什么。

第二种：目标页面没有注册。导航目标页面必须被RegisterForNavigation注册过。如果漏注册，运行时 Prism 会抛一个异常，提示“找不到可导航的类型”。排查方式：查看模块的RegisterTypes方法里有没有对应的代码。

第三种：模块没有被加载。很多人把注册导航页面的代码写在模块里，但模块并没有配置到ModuleCatalog中。结果是运行时主窗口出来了，点了按钮导航，页面毫无反应，也没有异常。这个排查最耗时。可以在App.xaml.cs里打日志，看到底加载了哪些模块。

第四种：UserControl 里没有设 Region 或者设在了不合适的元素上。记住一点：Region 要挂在ContentControl上，而且要指定RegionName附加属性。挂在普通Grid上不是不行，但行为和你预期很可能不一致。

6.2 参数传递丢失：大部分情况出在取参时机

导航参数丢失，多数和OnNavigatedTo的拼写错误有关，或者干脆没实现INavigationAware。这两点都比较明显，还有一种相对隐蔽的情况：IsNavigationTarget返回true时页面实例被复用，你只在构造函数里做了一次参数解析，切回来时OnNavigatedTo确实触发了，但你认为“页面初始化过了”就没重新读参数，导致数据显示的还是旧值。

我的建议是：凡是接收参数的页面，一律把参数解析放在OnNavigatedTo里做，不要在构造函数里解析。构造函数只做命令初始化和依赖保存。

6.3 事件聚合器的内存泄漏：这是我最想说的一点

事件聚合器的订阅如果你用的是Subscribe的默认参数，实例是弱引用，理论上在页面关掉后会被回收，不造成泄漏。但如果显式用了killSubscriberReferenceAlive: true或者用了强引用订阅，而页面关闭时没有退订，泄漏风险非常高。

还有一点容易被忽略：PubSubEvent的Subscribe支持Predicate<T>过滤参数。如果过滤器内部引用了大的对象，即使订阅是弱引用，过滤器也一直存活。

我在项目中统一了几个约束：

• 订阅一律用弱引用默认值。
• 页面的 ViewModel 实现IDisposable，在OnNavigatedFrom或页面关闭时调用Dispose，把订阅 token 释放。
• 严禁在静态类或单例对象中订阅和页面生命周期相关的事件。
• 事件定义尽量保持简单的参数类型，避免传大对象引发持有链。

6.4 对话窗口关闭后数据不刷新：回调时机与生命周期

很多人写对话服务时遇到的问题是：弹窗保存了数据，但列表页不知道要刷新。这个问题的根源在于——列表页的刷新逻辑，不应该依赖弹窗来触发，而应该由列表页自己去订阅“数据已保存”这个事实。

我的标准做法是：弹窗保存成功后发布一个DataChangedEvent，列表页在OnNavigatedTo和事件订阅里都刷新一次。这样无论是从弹窗返回、从导航返回、还是数据被其他模块改动，列表页都能自动刷新，不用关心数据到底是从哪里变的。

有一个细节要提一下：弹窗关闭回调里要注意 UI 线程问题。某些情况下，弹窗关闭回调可能不在主线程，直接在里面操作ObservableCollection会抛异常。统一用IDispatcher.Invoke把刷新动作切到 UI 线程。

6.5 导航后界面空白：View 加载了但没有显示内容

还有一种情况，导航确实执行成功了，区域里也看得见 View 的实例，但界面上就是一片空白。这种问题绝大多数出在 View 的根元素上：UserControl没有设置Content以外的东西，或者 ViewModel 的数据绑定路径出错，造成可视化树里根本没有实际内容。

排查方法很简单：在 View 的构造函数里打日志，确认构造了；在 ViewModel 上打断点，确认OnNavigatedTo执行了；再看 XAML 输出窗口有没有绑定错误。我遇到过一个情况是 ViewModel 里抛异常，导致绑定静默失败，界面看起来就是白的。用 Debug 输出绑定错误信息，花了半天才定位到，后来我给View的根元素加了一个DataContext变更的断点，这种问题就好找多了。

6.6 从实操中沉淀下来的几条经验

最后分享几条我用 Prism 导航做项目沉淀下来的实操经验：

1. 给所有导航页面统一命名空间常量类。把导航目标的名字集中放在一个静态类里，比如NavTargets.HomeView = "HomeView"。这样既避免拼写错误，也方便全工程搜索引用。我踩过拼错导航名的坑，排查了半个多小时。

2. 导航尽量都在 ViewModel 层发起。不要在 View 的 CodeBehind 里写导航代码，尤其不要在事件处理器里直接操作 RegionManager。统一用命令绑定到 ViewModel，测试和维护都会舒服很多。

3. 凡是有表单的页面，都实现IConfirmNavigationRequest。未保存提醒这件事越早做越好，等用户真丢了数据再补，很难补得回来。

4. 每次导航尽量携带NavigationParameters而不是把数据塞到共享静态类里。虽然静态类传值方便，但会让页面之间的依赖关系变得极其隐蔽。参数方式至少让数据流在代码里可见。

5. 关注 Region 的导航日志。Prism 自带的 Region 调试视图在排查多 Region 嵌套问题时很好用，打开它可以看到当前区域内已加载的视图和导航历史，能少走很多弯路。

6. 对话服务注意控件的DataContext绑定。对话框的 View 根节点DataContext会被 Prism 自动设置为对应的 ViewModel，不要在手写的 XAML 里又手动设置一次DataContext，否则绑定会失效。

7. 模块之间不要互相引用对方的 ViewModel 类型。要让模块通信走事件聚合器或共享服务接口。一旦模块间开始引用具体 ViewModel，模块化的边界就名存实亡了，后续编译和维护都会很痛苦。

这些经验都是我在真实项目中一点点攒出来的。Prism 的导航、模块化、通信、对话服务，单独看每一个都不是特别复杂，但组合起来使用的时候，边界和约定远比 API 本身重要。你先从一个小模块入手，把注册和跳转跑通，再逐步引入参数、生命周期、事件通信，最后补上对话服务和测试，整个过程会顺畅得多。