简介：面向刚接触 Windows 桌面开发的 .NET 程序员与在校学生，这份 PDF 针对界面设计与业务逻辑耦合、控件体系庞杂难以入手的问题，提供一条从概念到控件的入门路径。正文先说明 WPF 作为 .NET Framework 3.0 组成部分的统一编程模型，再拆解 PresentationFramework、PresentationCore、milcore 三大核心组件与文档服务、用户界面服务、多媒体服务的架构分层；随后用 XAML 与等价 C# 代码对照，讲清声明式写法如何实现 UI 与逻辑分离，并按 Editing、List、Action、Layout、Navigation、Documents 等类别梳理常用控件集，示例与表格相辅，便于边读边对照实践。整份文档为 1 个 PDF 文件，大小约 1.42MB，单文件便于离线阅读与打印。目前已有 1597 人学习，适合在动手写第一个窗口前建立整体认知，也可作为查阅控件分类与架构分层的速查材料。
1. 从一个反直觉现象说起
写过 WinForms 的人转到 WPF（Windows Presentation Foundation），第一件事往往是去找OnPaint，结果找不到。XAML 里写下的一个 Button 在运行时是一个真实活着的对象，你改它的某个属性，屏幕自己就变了，没人喊“重绘”。这个反直觉的差异，是理解 WPF 的入口：它把“描述界面”和“渲染界面”彻底拆成了两件事，你只负责维护一棵对象树，取像素是下层合成引擎按帧去做的事。顺着这条线往下走，XAML 为什么会被编译成 BAML、普通属性为什么要换成依赖属性、数据绑定凭什么能自动刷新、ObservableCollection和INotifyPropertyChanged为什么缺一不可，全部能串成一条因果链，而不是一堆需要背下来的 API。
2. 三层组件：milcore 为什么必须是非托管代码
WPF 最容易被忽略的一点，是它的核心组件并不是全托管代码。PresentationFramework、PresentationCore、milcore 这三个组件里，前两个跑在 CLR 上，第三个偏偏是原生的、和 DirectX 打交道的一层。这个切法并非随意决定，它决定了 WPF 的性能上限，也决定了你遇到某些问题时的排查方向。
2.1 PresentationFramework、PresentationCore、milcore 的分工
从职责上分，这三层是“表达层 → 图元层 → 合成层”的递进关系：
| 组件 | 是否托管 | 主要职责 | 出问题时典型表现 |
|---|---|---|---|
| PresentationFramework | 是 | 控件、布局、样式与模板、数据绑定、命令、文档 | 绑定不刷新、布局错乱、模板找不到 |
| PresentationCore | 是 | Visual 树、DrawingContext、几何与媒体图元、动画时钟 | 自定义绘制不生效、动画中断 |
| milcore | 否 | 与 DirectX 交互、Composition 合成引擎、渲染数据树 | 整窗白屏、渲染线程异常、驱动相关问题 |
PresentationFramework 是日常接触最多的，Window、Grid、Button、Binding都在这一层；PresentationCore 提供的是更接近底层的东西，比如Visual、DrawingVisual、Geometry、MediaPlayer，自定义控件绘制时用的OnRender(DrawingContext)就在这一层；milcore 则几乎不会出现在代码里，但它在运行时一直在跑。
分界线画在这里的原因，是帧预算。界面要流畅，一帧的窗口大约只有十几毫秒，这段时间里要做的事包括把脏区重绘、把多个图层合成、再交给图形驱动。托管代码有 GC，GC 一停顿，帧就掉了。于是设计上把“每帧都要跑的合成”放到非托管层，用自定义内存管理，不需要的对象不复用、不做复杂的对象生命周期，让这块的延迟可预测。代价是这一层拿不到 CLR 的便利，所有数据结构都要自己写，出问题时也没有托管调试器那么好用——这也是为什么纯粹的渲染异常往往只能看到“整个窗口变白”，而看不到有用的调用栈。
理解这条边界，在排查时很有用：控件层的表现去 PresentationFramework 里找，图形和动画时序错乱多半在 PresentationCore，而“分辨率变化后花屏”“远程桌面下渲染异常”这类问题，基本可以往上归到合成层和图形驱动。
2.2 一帧是怎么合成的：保留模式与合成引擎
WinForms 采用的是立即模式：窗口收到重绘消息，事件处理器里拿着一个 Graphics 对象往设备上下文上刷像素，刷完就结束。这种模型下，界面状态存在程序员脑子里，系统只记得最后一次画出来的位图。窗口被遮挡后再露出来、最小化再恢复，只能整片重画。
WPF 换成了保留模式。你创建的每个元素，最终都会对应渲染数据树里的一个节点；每个节点保存的是“怎么画”（绘制指令、几何、画刷、变换），不是“画完的像素”。当属性发生变化，框架只把受影响的那部分标记为脏，重新生成对应的绘制指令，然后交给合成引擎去合成为一张 Surface，最终统一提交显示。
这个机制带来三个直接结果：
第一，动画可以被“离线”计算。常见的实现思路是把动画插值放在合成阶段，而不是在 UI 线程上每个 tick 改一次属性值。用DispatcherTimer手写动画之所以卡，原因就在这里。
// 手写动画：每 16ms 在 UI 线程上改一次值，UI 线程一忙就掉帧 var timer = new DispatcherTimer { Interval = TimeSpan.FromMilliseconds(16) }; timer.Tick += (s, e) => box.Width = box.Width + 1; timer.Start(); // WPF 的做法：把"从 100 到 300、耗时 1 秒"这个意图交给动画时钟， // 插值由渲染侧驱动，UI 线程被占用时动画依然在推进 box.BeginAnimation(WidthProperty, new DoubleAnimation(100, 300, TimeSpan.FromSeconds(1)));想验证这一点很简单：在按钮事件里Thread.Sleep(3000)把 UI 线程占死，此时手写的定时器动画会完全停住，而BeginAnimation驱动的动画通常还在走。这个现象就是“UI 线程与渲染线程分离”最直接的证据，也是很多人第一次意识到 WPF 内部有两条线程的时刻。
第二，重绘是局部的。改一个按钮的背景色，不会导致整个窗口重新构造绘制指令。脏区机制让界面在元素多的时候仍然可控。
第三，代价是内存。每个窗口至少对应一张 Surface，高分辨率下这张 Surface 的字节数相当可观；半透明、动画、多图层会进一步放大。这也是为什么老机器上跑 WPF 应用，任务管理器里的内存曲线总是不太好看——那是保留模式在替即时模式还债。
2.3 User32 与桌面窗口管理：为什么窗口还是一个句柄
即使渲染路径改成了 DirectX，WPF 的顶层窗口依然是一个真正的窗口句柄，消息循环依然存在，只是被Dispatcher包了一层。窗口的创建、拖动、最大化、输入法、拖放，还是走系统那套窗口管理；而窗口内容的呈现，则先合成到 Surface，再交给桌面窗口管理器做最终合成，透明、阴影、缩放动画都在这一步完成。
这层关系解释了一个让很多人头疼的现象：在 WPF 里嵌入一个原生子窗口控件，那个控件永远盖在所有 WPF 元素上面，既压不住也透不过去。原因是它真的是一个子窗口，合成顺序由桌面窗口管理器决定，WPF 的元素树根本管不到它。常见的实现思路是用D3DImage把原生渲染结果当纹理贴进来，把子窗口变成“图像”，这样它才重新回到 WPF 的合成体系里。这个坑的根因在第 2.2 节就已经埋下了——WPF 走的是自己的一套渲染管线，可窗口边界和原生控件仍然属于系统那一套，两套体系的交界处就是麻烦的来源。
3. 两套 API：XAML 为什么最后要编译成 BAML
关于 XAML 最常见的误解，是把它当成“WPF 的编程语言”。它其实更接近一种对象图的序列化格式：每个元素对应一个 CLR 类，每个属性对应一个 CLR 属性，仅此而已。想清楚这一点，XAML 里那些看起来奇怪的语法就都有了着落。
3.1 XAML 与 C# 是同一套对象模型的两种写法
同一段界面，两种写法完全等价：
<Button Name="bt1" Background="Blue" Foreground="Red"> This is a button </Button>Button bt1 = new Button(); bt1.Content = "This is a button"; bt1.Background = Brushes.Blue; bt1.Foreground = Brushes.Red;两段代码执行完得到的是同一棵对象树。差异只在于表达方式：XAML 偏声明，适合描述静态结构和层级；C# 偏过程，适合写逻辑、循环、条件。因此把 XAML 理解成“另一种语言”会带来一连串误判，比如以为可以在 XAML 里写 for 循环。XAML 里没有控制流，因为它是对象图的字面表示，不是程序。
3.2 xmlns、属性与子元素：三条语法映射规则
XAML 用得最多的 XML 特性有三个：命名空间、属性和子元素，每一个都对应一个具体机制。
命名空间负责把 XML 的 URI 映射到 CLR 命名空间集合。框架通过XmlnsDefinitionAttribute把一组 CLR 命名空间挂到同一个 URI 上，所以http://schemas.microsoft.com/winfx/2006/xaml/presentation这一个 URI 背后其实是一大堆命名空间，所有常用控件都能在里面找到。而x:前缀指向的是语言层面的东西，跟控件无关：x:Class指定后台代码类，x:Name生成字段，x:Key给资源起名字，x:Static引用静态成员。
属性和子元素是同一个东西的两种写法。当属性值是一个简单字符串时，直接写成特性；当属性值是一个复杂对象时，用“属性元素”语法展开：
<Button Width="120"> <Button.Background> <LinearGradientBrush StartPoint="0,0" EndPoint="1,1"> <GradientStop Color="White" Offset="0" /> <GradientStop Color="#FF3366" Offset="1" /> </LinearGradientBrush> </Button.Background> </Button>这里Width="120"是字符串，Button.Background里塞的是一个对象。字符串怎么变成对象？靠类型转换器。"Blue"能变成SolidColorBrush，是因为登记了对应的转换器；写一个不认识的字符串就会在解析阶段直接抛异常。
还有一种东西比转换器更灵活，就是标记扩展。{Binding ...}在解析时不会被当成字符串，而是实例化一个Binding对象并挂到目标属性上——这本质上是一次方法调用而不是一次赋值。{StaticResource}、{RelativeSource}、{x:Static}都是同样的机制。分清“转换器”和“标记扩展”，能省下不少调试时间：转换失败通常报错很直接，标记扩展失败则往往静默，资源键找不到时表现尤其隐蔽。
3.3 BAML 与 .g.cs：编译期到底做了什么
XAML 文件在编译时并没有被原样打包。构建过程会解析 XAML，把它转成一种预分词的二进制格式 BAML，嵌入程序集资源；同时生成一个配套的后台代码文件，通常叫*.g.cs。
生成的代码大致长这样：
public partial class MainWindow : Window { // x:Name 声明的元素会变成字段 internal System.Windows.Controls.Button bt1; public MainWindow() { this.InitializeComponent(); // 在这里才真正把 BAML 读成对象树 } private void InitializeComponent() { // 加载编译期嵌入的 BAML 资源，并按 x:Name 给字段赋值 System.Windows.Application.LoadComponent( this, new Uri("/App;component/MainWindow.xaml", UriKind.Relative)); } }这段代码解释了三个日常现象。
其一，为什么界面描述在编译期就被固化。BAML 是预分词的，加载时不需要重新做 XML 语法分析、不需要反复做类型转换、不需要反射查找类型，因此启动明显更快，体积也更小。如果把 XAML 保留成文本形式在运行时解释，每开一个窗口就要交一次解析成本，这对启动速度是实打实的损耗。
其二，为什么构造函数里访问控件会拿到空引用。字段是靠InitializeComponent()赋值的，在这行之前调用，字段就是null。这不是时序玄学，而是字段初始化的自然顺序。
其三，为什么运行时加载 XAML 的场景慢一截。用XamlReader.Load动态解析字符串，等于把编译期该做的事搬到了运行时，图省事的代价是解析开销和类型安全都丢了。插件式界面常见这种写法，值得知道代价在哪。
3.4 控件集分类背后的继承骨架
控件列表确实长：编辑类、列表类、信息展示类、动作类、外观类、对话框、容器、布局、导航、文档。逐个记是没有尽头的，但这些控件背后其实只有少数几个基类。
| 分类 | 代表控件 | 共同基类 | 关键扩展点 |
|---|---|---|---|
| 动作 / 编辑 | Button、CheckBox、RadioButton、TextBox | ContentControl / ButtonBase | Content、Command、模板 |
| 列表 | ListBox、ListView、TreeView、ComboBox | ItemsControl | ItemsSource、ItemTemplate |
| 布局 | Grid、StackPanel、DockPanel、WrapPanel、Canvas | Panel | Children、测量与排列 |
| 外观 | Border、Image、Viewbox | Decorator / FrameworkElement | Child、拉伸方式 |
| 导航 / 文档 | Frame、DocumentViewer | ContentControl / FrameworkElement | Source、文档内容 |
做到“看见一个陌生控件，能猜出它继承自谁”，比背控件名有用得多。Button和CheckBox都是ButtonBase分支，所以它们共享Click和命令支持；ListBox、TreeView、ComboBox都是ItemsControl分支，所以它们共享ItemsSource和数据模板逻辑；所有布局容器都是Panel，所以它们共享测量与排列两段流程。控件的“能力”基本由基类决定，控件自身的差异主要体现在默认模板和少量属性和行为上。
4. 依赖属性与数据绑定：属性系统怎么撑起绑定
数据绑定是 WPF 最被低估的部分。表面上看它只是“把两个值关联起来”，但真正让它能工作的，是一套完全重写过的属性系统。理解这套系统，才能解释为什么“样式设了没生效”“动画结束值回退了”“本地值盖住了触发器”这些现象。
4.1 普通 CLR 属性撑不住的三笔账
假设所有属性都是普通的自动属性，会立刻遇到三个问题。
第一笔是内存。一个控件动辄几十上百个属性，每个属性都要占一个字段。控件实例一多，光是存这些默认值就是一笔可观的开销，而其中绝大多数属性从来没被改过。
第二笔是值来源。同一个属性可能同时被默认值、从父元素继承下来的值、样式里的 Setter、模板触发器、本地赋值、动画所影响。普通属性只能记住“最后一个写进去的值”，没法表达“这个值现在是从哪一层来的”，也就没法在某一层失效时回退到上一层。
第三笔是通知。属性变了要驱动重绘、触发布局、通知绑定目标，普通属性没有统一的挂钩点，只能靠每个类自己写事件，写漏一个就是“界面不刷新”的 bug。
依赖属性就是针对这三点重新设计的。
4.2 注册表结构与值优先级
依赖属性不是实例字段，而是一个静态注册的元数据描述符，所有实例共享同一份定义；每个实例只额外保存“被改动过”的那些值，没改过的读默认值。
public class Camera : DependencyObject { // 静态注册一次，全进程共享；注册表以"名称 + 宿主类型"为键 public static readonly DependencyProperty ZoomProperty = DependencyProperty.Register( "Zoom", // 属性名 typeof(double), // 值类型 typeof(Camera), // 宿主类型 new FrameworkPropertyMetadata( 1.0, // 默认值 FrameworkPropertyMetadataOptions.AffectsRender, // 变化后要重画 OnZoomChanged)); // 变更回调 public double Zoom { get { return (double)GetValue(ZoomProperty); } set { SetValue(ZoomProperty, value); } } private static void OnZoomChanged(DependencyObject d, DependencyPropertyChangedEventArgs e) { // 只在这里做副作用：通知、标记脏区、联动其它状态 // 不要在这里再 SetValue 同一个属性，容易递归 } }GetValue/SetValue看起来像装箱拆箱，实际内部走的是按优先级求值：从默认值开始，一层层往上找，找到最高优先级的那个来源就用它。层级从低到高大致是：默认值、继承值、样式 Setter、模板触发器、本地值、动画。
这个顺序能直接解释几个高频现象：
- 在样式里设了
Background，但元素上写过一次Background="Red"，样式就再也不生效了——本地值优先级更高。想保留样式的响应能力，用SetCurrentValue而不是SetValue。 - 动画跑完后值“弹回去”了——动画在动画时钟期间持有最高优先级，时钟结束，这一层来源消失，值自然回退到下一层。想留住终值，就在
Completed里改基值。 Trigger改不动某个属性——大概率是被本地值压住了。
依赖属性还带来了附加属性这个能力：Grid.Row、Canvas.Left这类属性定义在别的类上，但可以挂在任意元素上，本质上是“用一个静态键往任意实例的值表里写一项”。布局容器就是靠这个机制做布局参数传递的。
4.3 Binding 的四个要素与 DataContext 继承
Binding在 XAML 里是标记扩展，在 C# 里就是一个普通对象。它的核心要素只有四个：数据源、路径、方向、转换器。
var binding = new Binding("Zoom") { Source = camera, // 数据源：显式指定 Mode = BindingMode.TwoWay, // 双向 UpdateSourceTrigger = UpdateSourceTrigger.PropertyChanged, // 每次输入都回写 Converter = new ZoomToTextConverter(), // 可选：值转换 FallbackValue = "N/A" // 源取不到值时的兜底 }; // 挂到目标属性上，内部生成一个 BindingExpression 负责实际的同步 view.SetBinding(Camera.ZoomProperty, binding);路径的解析走的是反射或ICustomTypeDescriptor，解析结果会被缓存成属性描述符，所以绑定本身并不像看起来那么重。但缓存也意味着：如果一个对象在运行时换了类型，或者属性是动态生成的，绑定可能拿不到你想要的值。
指定数据源有三种方式：Source直接给对象，ElementName按名字指向另一个元素，RelativeSource按树关系找（模板里常用TemplatedParent和AncestorType）。这三种之外，还有第四种也是最常用的：什么都不写，交给DataContext。
DataContext的关键在于继承。它沿着逻辑树向下传播，父元素设一次，子元素全部能拿到；一旦某个子元素自己设了DataContext，这条继承链就在它这里断开，它的子树都用新值。所以“给窗口设了 DataContext，某个面板里的绑定却不生效”，基本都是中间某一层被截断了。
优先级上，Source高于DataContext：只有当Source不存在，或者在Source上找不到对应属性时，才会回头去查DataContext。基于这一点，实践中更推荐显式写Source或ElementName，因为绑定出错时能一眼看出源是谁；DataContext的优势是省事和继承，代价是排查时得顺着树往上找。
4.4 INotifyPropertyChanged 与 ObservableCollection 的分工
绑定建立了通道，但通道要有人推数据。WPF 支持四类数据源：任意 CLR 对象、XML 节点、数据表、依赖对象。其中 CLR 对象最常用，也最容易踩坑——不是随便一个类都能当绑定源。
原因在于通知。绑定目标要知道“源变了”，而普通 CLR 对象不会主动说。WPF 把这件事抽象成了INotifyPropertyChanged接口，类实现它，就有了通知能力：
public class Camera : INotifyPropertyChanged { private double _zoom = 1.0; public event PropertyChangedEventHandler PropertyChanged; public double Zoom { get { return _zoom; } set { // 相等就直接返回：避免双向绑定形成回环，反复触发 if (Math.Abs(value - _zoom) < double.Epsilon) return; _zoom = value; // 参数必须是属性名，写错不会报错，绑定会静默失效 PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(Zoom))); } } }这段代码里有两个细节值得强调。一是相等判断，双向绑定场景下如果不判等，源更新目标、目标又回写源，很容易形成循环触发。二是属性名的字符串，写错了编译器不会管，运行时也不会抛异常，只是绑定悄悄不更新——这是最难查的一类问题，后面还会提到。
单个对象的属性有通知了，集合呢？ObservableCollection<T>解决的是“集合成员发生变化”这件事：增删、清空、整体重置时会发出CollectionChanged，绑定到ItemsSource的列表会自动跟着变。
// 集合本身的变化由 ObservableCollection 负责通知 public class CameraList : ObservableCollection<Camera> { public CameraList() { Add(new Camera { Zoom = 1.0 }); Add(new Camera { Zoom = 2.5 }); } }<ListBox ItemsSource="{Binding CameraList}"> <ListBox.ItemTemplate> <DataTemplate> <!-- 注意：这里的 Zoom 变化能不能刷新，取决于 Camera 有没有实现通知 --> <TextBlock Text="{Binding Zoom}" /> </DataTemplate> </ListBox.ItemTemplate> </ListBox>这里有个极常见的认知偏差：以为用了ObservableCollection就万事大吉。它只管集合容器的增删，不管元素内部属性的变化。元素自己的属性要刷新，元素类型仍然必须实现INotifyPropertyChanged。两件事、两个接口，缺一不可。
5. 排查现场：五类反复出现的翻车记录
下面这五条都来自实际调试，共同点是“代码没错、编译通过、运行不报错，但界面就是不对”。WPF 的很多问题属于这一类，靠断点找不到，得知道它内部在做什么才有方向。
5.1 绑定静默失效：三种不报错的写法
现象：界面一片空白或者数值永远是初始值，输出窗口没有任何异常。
原因：绑定失败默认不抛异常，只写跟踪日志。常见三种写法有问题：Path里的属性名拼错（大小写敏感）；属性不是public（绑定只认公开属性）；INotifyPropertyChanged的事件参数里属性名写成了字符串而且写错了。
解决：给可疑的绑定挂上跟踪级别，让它把失败原因打到输出窗口。
<TextBlock Text="{Binding Zoom, diag:PresentationTraceSources.TraceLevel=High}" />配上xmlns:diag="clr-namespace:System.Diagnostics;assembly=WindowsBase"之后，源找不到、属性不存在、转换器抛异常都会详细打出来。排查绑定问题的第一动作应该是这个，而不是改代码试。
5.2 初始化顺序：构造函数里的空引用
现象：构造函数里访问x:Name声明的控件，直接NullReferenceException。
原因：这些控件不是字段初始化出来的，而是在InitializeComponent()里由 BAML 加载过程赋值的。写在它前面，字段当然是null。
解决：把依赖控件实例的逻辑挪到Loaded事件里；确实要在构造函数里做的，必须放在InitializeComponent()之后。顺带一提，Loaded触发时布局已经完成，需要读取实际尺寸（ActualWidth）的逻辑只能放在这里，构造函数里读到的一定是 0。
5.3 输入不实时：UpdateSourceTrigger 的默认值
现象：在 TextBox 里打字，绑定的源对象属性没有跟着变，切走焦点才更新。
原因：TextBox.Text的UpdateSourceTrigger默认是LostFocus，不是PropertyChanged。这是有意的设计——每次按键都回写源，校验和转换的开销会翻倍，而且用户输入到一半的中间态往往是非法值。
解决：需要实时联动时显式改成PropertyChanged；如果同时有校验逻辑，配合Delay使用，避免每敲一个字符就触发一次。这个默认值不是 bug，是取舍，知道它存在就不会绕远路。
5.4 集合刷新：容器变了和元素变了是两回事
现象：往列表里Add一项，界面不动；或者列表项显示了，但改了某一项的属性，那一行文字不更新。
原因：前者是用了List<T>而不是ObservableCollection<T>，容器变化没人通知；后者是集合元素类型没实现INotifyPropertyChanged，元素内部变化没人通知。两种现象看起来一样，根因完全不同。
解决：容器用ObservableCollection<T>，元素类型实现INotifyPropertyChanged。还有一个隐蔽变体：集合在后台线程被修改，会抛“不允许跨线程访问集合”的异常，因为集合变更通知必须回到创建它的线程上发出。
5.5 动画结束值回退：优先级在起作用
现象：动画播完，属性值唰地弹回动画前的值，视觉上很突兀。
原因：动画这一层值来源的优先级高于本地值，动画时钟结束时这层来源消失，属性回退到下一层。FillBehavior默认是HoldEnd，但只要动画被移除或者时钟停止，回退照样发生。
解决：在Completed回调里把终值写进基值，或者用SetCurrentValue写入，避免覆盖动画层。另一个相关坑是：动画进行中用SetValue改同一个属性，视觉上毫无反应，因为动画层优先级更高——这时候该用SetCurrentValue或先BeginAnimation(prop, null)清掉动画。
6. 设计取舍：把复杂度放在哪一层
回头看这三层组件、依赖属性、绑定引擎，会发现它们共享同一个取舍思路：把复杂度前移到框架内部，换取上层表达力的提升。XAML 编译成 BAML，是用可读性换启动速度和体积；依赖属性替换普通属性，是用“属性就是字段”的直觉换值来源的可组合；绑定引擎替换显式赋值，是用“出错时静默”换“不用手写同步代码”。这些交换都不是免费的，代价最终会以某类 bug 的形式回到开发者身上——绑定不生效、动画回退、模板找不到，本质都是在为这些取舍还债。
下面这张表把两类写法放到一起，方便判断什么时候该用哪一边：
| 维度 | 显式赋值（C# 直接改属性） | 声明式（XAML + 绑定） |
|---|---|---|
| 出错表现 | 编译期报错、断点可查 | 运行时静默失效，需开跟踪 |
| 值来源 | 只有一处，覆盖即生效 | 多层优先级，需判断当前谁在起作用 |
| 改动成本 | 改逻辑要改代码 | 换皮肤、换模板不动逻辑 |
| 适合场景 | 一次性、命令式、时序敏感 | 状态驱动、需要复用和主题化 |
判断标准其实很简单：这个值会不会被外部状态反复改写？会，就走绑定和依赖属性，让属性系统去管优先级；不会，就直接赋值，别为了“统一风格”把简单问题复杂化。我见过不少项目把一切都包进绑定，结果调试成本比手写同步还高。
验证方式也有讲究。界面行为不对时，先分清楚问题属于哪一层：是数据没过来（绑定层），还是过来了但没画对（渲染层），还是画对了但时序不对（动画层）。绑定层用跟踪日志，渲染层看可视化树，布局问题看测量与排列的中间值。按层定位比逐行读代码快得多。
说个自己的教训。早年做一个图像处理的演示程序，界面上有个滑动条控制预览缩放，怎么拖预览都不动，代码翻了三遍没找出问题，最后发现是属性名里有个字母大小写和绑定路径对不上——整整一个下午栽在一个字符串上。从那以后我每次新建绑定，第一件事就是把跟踪级别开成 High，跑一遍看输出窗口干不干净，再往下写业务逻辑。这个习惯看着笨，但省下来的时间远比它多。希望帮到你。
本文还有配套的精品资源，点击获取
