在WPF桌面开发中，界面交互逻辑如果全部写在后台代码的事件处理器里，不仅控件与逻辑紧密耦合，还会让同一个功能在多个页面被重复实现。行为（Behaviors）是一种把交互封装成可复用单元的机制，它基于附加属性思路，让开发者把诸如自动获得焦点、限制输入字符、支持拖放等功能独立成类，再以声明方式挂到具体控件上。这种方式使XAML更清晰，也方便在Blend里可视化编辑。
行为的基本原理与运行环境准备
WPF行为最早由微软的System.Windows.Interactivity类库提供，后来在开源社区演变为Microsoft.Xaml.Behaviors.Wpf包。行为的核心是一个泛型抽象类Behavior<T>，其中T代表要附加的控件类型。当行为被附加到控件时，框架会调用OnAttached方法，开发者可以在这里订阅控件事件或设置属性；当行为被移除时，调用OnDetaching进行反订阅，避免内存泄漏。
要使用行为，首先需要通过NuGet安装Microsoft.Xaml.Behaviors.Wpf。安装完成后，在XAML文件里引入命名空间，例如写成xmlns:b="http://schemas.microsoft.com/xaml/behaviors"。这样就能在控件内部使用<b:Interaction.Behaviors>节点添加具体行为。与传统的附加属性相比，行为基类已经帮我们处理了关联生命周期，不需要自己写静态的Get/Set方法和属性变更回调。
需要注意的是，行为并不局限于UI事件。它也可以结合触发器（Trigger）使用，比如EventTrigger监听某个路由事件，再执行InvokeCommandAction把事件转发到ViewModel的命令。这种组合让MVVM模式下的视图与视图模型通信更自然，后台代码几乎可以完全消失。
自定义一个实用的行为类
假设我们希望文本框在加载后自动获得焦点，并且只允许输入数字。可以创建一个继承Behavior<TextBox>的类。在OnAttached里给AssociatedObject挂接Loaded事件和PreviewTextInput事件，在OnDetaching里解除挂接。通过这种封装，任何文本框只要添加这个行为就能具备相同能力。
下面给出一个完整的自定义行为示例，展示了如何限制输入并自动聚焦。代码中使用了转义字符来避免XAML解析问题，逻辑也保持简洁。
using Microsoft.Xaml.Behaviors;
using System.Windows;
using System.Windows.Controls;
public class NumericTextBoxBehavior : Behavior<TextBox>
{
protected override void OnAttached()
{
base.OnAttached();
AssociatedObject.Loaded += OnLoaded;
AssociatedObject.PreviewTextInput += OnPreviewTextInput;
}
protected override void OnDetaching()
{
base.OnDetaching();
AssociatedObject.Loaded -= OnLoaded;
AssociatedObject.PreviewTextInput -= OnPreviewTextInput;
}
private void OnLoaded(object sender, RoutedEventArgs e)
{
AssociatedObject.Focus();
}
private void OnPreviewTextInput(object sender, TextCompositionEventArgs e)
{
foreach (char c in e.Text)
{
if (!char.IsDigit(c))
{
e.Handled = true;
break;
}
}
}
}
在XAML中使用该行为时，只需在文本框内部放入交互节点。这样即使多个窗口都有数字输入框，也不用在每个后台写重复规则。如果后续要改成允许小数点，只需修改行为类一处，所有引用自动生效，维护成本显著降低。
行为类的另一个好处是可以通过依赖属性暴露参数。例如增加一个AllowDecimal依赖属性，在XAML中绑定或写死，行为内部根据它调整正则判断。这种可配置性让单个行为适应多种场景，而不必为细微差别写多个类。
行为与传统附加属性方案的对比
有些开发者习惯用附加属性实现类似功能，比如定义一个AttachHelper.EnableDrag属性，在属性变更回调里挂事件。这种做法没有额外类库依赖，编译体积小。但缺点在于：每个功能都要写一套静态属性加回调，缺少统一基类，难以在XAML中直观看到“这个控件挂了哪些交互”。
行为则提供了标准化结构，并且能被Blend等设计器识别，产品经理或设计师可以直接从工具面板拖拽行为到控件。此外，行为容易组合，一个控件可以同时拥有聚焦行为、拖拽行为和验证行为，彼此独立互不干扰。而附加属性若没设计好命名空间，很容易冲突或让代码散落各处。
当然，行为也不是银弹。由于逻辑被移到独立类，调试时调用栈会多一层，新手可能不知道事件是在哪个行为里处理的。因此建议团队对行为使用做规范：行为只放纯UI交互，不涉及业务接口调用；业务相关响应仍走命令或ViewModel。这样既能享受解耦便利，又不会让程序流变得不可追踪。
在MVVM中通过行为触发命令
最常见需求是把控件的事件（如SelectionChanged）转成ViewModel里的命令。过去要写后台代码调用viewModel.LoadCommand.Execute，现在用EventTrigger加InvokeCommandAction即可完成。下面演示列表选中变化通知ViewModel：
<ListBox ItemsSource="{Binding Items}">
<b:Interaction.Triggers>
<b:EventTrigger EventName="SelectionChanged">
<b:InvokeCommandAction Command="{Binding SelectionChangedCommand}" />
</b:EventTrigger>
</b:Interaction.Triggers>
</ListBox>
这段代码中，EventTrigger监听ListBox的SelectionChanged路由事件，一旦触发就执行绑定的命令。命令参数默认是事件参数，也可以借助CommandParameter绑定选中项。如此一来，View层彻底不含业务代码，单元测试也能直接测ViewModel命令而不依赖UI。
如果使用的是CommunityToolkit.Mvvm，还可以配合[RelayCommand]特性快速生成命令，进一步减少样板代码。行为加触发器加工具包命令，是当前WPF写干净界面的最佳组合之一。掌握这些用法后，面对复杂表单或仪表盘交互，都能以极低耦合度完成交付。