依赖属性是WPF为实现数据绑定、样式、动画等高级功能而设计的特殊属性，其值存储在DependencyObject的全局字典中并支持优先级解析和自动通知，而普通CLR属性仅存储在对象字段中且无内置通知机制；依赖属性适用于UI相关、需绑定或样式的场景，普通属性适用于数据模型和内部状态管理。
WPF中的依赖属性（Dependency Property，简称DP）与我们平时在C#类中使用的普通CLR属性，核心区别在于它们的存储机制、功能扩展性和所处的生态系统。简单来说，依赖属性是WPF为了构建其强大而灵活的UI框架而特别设计的一种属性，它提供了普通CLR属性无法比拟的特性，例如数据绑定、样式、模板、动画以及值继承等。如果你要深入理解WPF的工作方式，理解这两者的差异是绕不过去的坎。
解决方案
依赖属性和普通CLR属性在表象上看起来很相似，都是通过get/set访问值，但它们内在的实现和功能范畴却大相径庭。普通CLR属性的值直接存储在对象实例的字段中，每次访问都直接读写这个字段。这很直接，也很高效，但它缺乏一种机制来通知外部系统值的变化，也无法参与到WPF复杂的属性系统运算中。
依赖属性则不同。它的值并不直接存储在定义它的对象实例中，而是在
DependencyObject内部维护的一个字典里。当你访问一个依赖属性时，WPF会根据一个复杂的优先级规则（值源优先级）来决定最终返回哪个值。这个优先级系统考虑了本地值、样式、模板、动画、继承值，甚至是默认值等多种来源。这种间接的存储和复杂的解析机制，正是依赖属性能够支持WPF诸多高级功能的基础。
想象一下，一个普通CLR属性要实现数据绑定，你得手动实现
INotifyPropertyChanged接口，并在set访问器中调用
PropertyChanged事件。而依赖属性天生就支持数据绑定，它内部有一套高效的通知机制，当值改变时，所有绑定到该属性的UI元素都会自动更新。同样，样式和模板可以直接针对依赖属性设置值，动画可以直接修改依赖属性的值，并且这些修改都可以在运行时动态生效、撤销，甚至叠加。值继承更是依赖属性独有的特性，比如一个父容器设置了
FontSize，其内部的子元素如果没有明确设置，就会自动继承父元素的
FontSize，这大大简化了UI的布局和样式管理。
从性能角度看，依赖属性的访问和解析确实会比普通CLR属性多一些开销，毕竟它要查询内部字典，并根据优先级规则计算最终值。但这种开销在大多数WPF应用中是微不足道的，而且它带来的功能强大性远远弥补了这一点。WPF的设计哲学就是用这种稍微复杂但功能强大的属性系统，来构建一个声明式、高度可定制的UI框架。
为什么WPF需要依赖属性，普通属性不够用吗？
这个问题其实触及了WPF框架设计的核心。如果WPF仅仅依赖普通CLR属性，它将无法实现我们今天所熟知的那些强大且灵活的UI特性。普通属性的“不够用”体现在几个关键点上：
首先，缺乏统一的通知机制。普通属性要实现数据绑定，必须依赖
INotifyPropertyChanged接口。这虽然可行，但要求每个需要绑定的属性都手动实现，增加了代码的重复性，而且对于框架层面来说，它无法提供一个统一的、高效的机制来监听所有属性的变化。依赖属性则内置了这种通知能力，所有依赖属性的变化都会通过
DependencyPropertyDescriptor或
PropertyChangedCallback等机制被WPF系统感知到。
其次，无法实现值来源的优先级和冲突解决。在WPF中，一个UI元素的某个属性值可能同时受到多种因素的影响：本地设置、样式、模板、动画、继承、默认值等等。如果都是普通属性，你如何优雅地处理这些冲突？谁说了算？依赖属性通过其内部的“值源优先级”系统，完美地解决了这个问题。它定义了一套严格的规则，确保在任何时候都能确定一个属性的最终有效值，并且这个过程是可预测、可控制的。
再者，缺乏对元数据的支持。普通属性通常只有类型和名称这些基本信息。而依赖属性可以附加丰富的元数据，比如默认值、属性改变回调、值强制回调、是否影响布局等。这些元数据对于WPF的布局系统、渲染系统以及其他高级功能至关重要。例如，一个
Width属性的元数据可以告诉布局系统，当这个属性改变时，需要重新测量和排列UI元素。
最后，无法支持样式、模板和动画。这些WPF的标志性功能，都建立在依赖属性之上。样式和模板本质上就是一套可以应用于依赖属性的setter集合。动画则是通过修改依赖属性的值，并在特定时间段内平滑过渡。如果属性只是一个简单的CLR字段，这些动态、声明式的UI行为根本无从谈起。可以说，没有依赖属性，WPF就无法成为一个富客户端UI框架，它会退化成一个功能有限、开发效率低下的系统。
如何自定义依赖属性，有哪些最佳实践？
自定义依赖属性是扩展WPF控件功能、创建可重用组件的关键一步。这个过程涉及几个核心步骤和一些值得注意的最佳实践。
首先，你需要在一个继承自
DependencyObject的类中定义你的依赖属性。这通常通过调用
DependencyProperty.Register方法来完成。
public static readonly DependencyProperty MyCustomProperty =
DependencyProperty.Register(
"MyCustom", // 属性名称
typeof(string), // 属性类型
typeof(MyCustomControl), // 声明该属性的类型
new PropertyMetadata("Default Value", OnMyCustomPropertyChanged)); // 属性元数据这里的
PropertyMetadata非常重要，它允许你设置默认值、属性改变回调 (
PropertyChangedCallback) 和值强制回调 (
CoerceValueCallback)。
最佳实践：
-
提供CLR包装器： 虽然依赖属性是WPF的核心，但为了方便开发者使用，你必须提供一个标准的CLR属性包装器。这个包装器只是简单地调用
GetValue
和SetValue
方法。public string MyCustom { get { return (string)GetValue(MyCustomProperty); } set { SetValue(MyCustomProperty, value); } }这个包装器让你的依赖属性看起来和用起来都像一个普通的CLR属性，但它背后是依赖属性的强大机制。
-
实现
PropertyChangedCallback
： 如果你的属性值改变时需要执行一些逻辑（例如更新UI状态、触发其他计算），在PropertyMetadata
中指定PropertyChangedCallback
。private static void OnMyCustomPropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e) { MyCustomControl control = d as MyCustomControl; if (control != null) { // 在这里处理属性值变化后的逻辑 // 例如：control.UpdateInternalState((string)e.NewValue); } }请注意，这个回调是静态的，因此你需要将
d
参数转换为你的控件实例来访问其实例成员。 -
使用
CoerceValueCallback
进行值强制： 如果你的属性值需要在特定条件下被限制或调整，可以使用CoerceValueCallback
。例如，一个Value
属性可能需要在0到100之间。private static object CoerceMyCustomValue(DependencyObject d, object baseValue) { // 假设MyCustom是一个int类型 int value = (int)baseValue; if (value < 0) return 0; if (value > 100) return 100; return value; } // 在Register时传入：new PropertyMetadata(50, OnMyCustomPropertyChanged, CoerceMyCustomValue)CoerceValueCallback
在属性值被设置（或重新计算）后，但在实际应用到属性之前被调用，它有机会修改或强制该值。 考虑
FrameworkPropertyMetadata
： 对于影响布局、测量、排列或渲染的属性，使用FrameworkPropertyMetadata
代替PropertyMetadata
。它提供了额外的标志，可以告诉WPF框架你的属性变化会如何影响UI的呈现。例如，FrameworkPropertyMetadataOptions.AffectsMeasure
。附加属性（Attached Properties）： 如果你希望为不拥有该属性的元素添加属性（例如，
Grid.Row
），你需要使用DependencyProperty.RegisterAttached
。这允许你在XAML中以OwnerType.PropertyName="Value"
的形式使用它们。
遵循这些最佳实践，可以确保你自定义的依赖属性能够很好地融入WPF框架，提供强大的功能，并保持代码的清晰和可维护性。
依赖属性与CLR属性的实际应用场景对比分析
理解依赖属性和CLR属性的区别，最终还是要落实到实际开发中，知道何时该用哪一个。这并不是一个非此即彼的选择，而是根据具体需求来权衡。
何时优先使用依赖属性：
-
UI相关的属性： 任何直接影响UI外观或行为的属性，如
Width
、Height
、Background
、Text
、IsEnabled
等，都应该设计为依赖属性。它们需要参与到WPF的布局、渲染、样式、模板和动画系统中。 -
需要数据绑定的属性： 如果你的属性需要与数据源进行双向或单向绑定，依赖属性是首选。它提供了高效的通知机制，无需额外实现
INotifyPropertyChanged
。 - 需要被样式或模板控制的属性： 任何需要在XAML样式或控件模板中设置或修改的属性，都必须是依赖属性。
- 需要动画效果的属性： 如果你希望某个属性的值能够平滑地从一个状态过渡到另一个状态，依赖属性是实现动画的基础。
-
需要值继承的属性： 像
FontSize
、DataContext
这样的属性，它们的值可以从父元素自动传递给子元素，这正是依赖属性的强大功能之一。 - 自定义控件的公共API： 当你开发一个可重用的自定义控件时，其对外暴露的、可供用户在XAML中设置的属性，几乎都应该是依赖属性。
何时优先使用普通CLR属性：
-
数据模型（Model）中的属性： 在MVVM模式中，你的ViewModel或Model层中的数据属性，如果它们不直接参与WPF的UI系统（即不需要被样式、模板、动画直接操作），通常设计为普通的CLR属性。当然，如果这些属性需要被绑定到UI上，它们所在的类需要实现
INotifyPropertyChanged
接口。 - 内部逻辑或私有状态： 控件或类的内部私有状态，不打算暴露给外部进行绑定、样式或动画操作的属性，使用普通CLR属性即可。这能减少不必要的依赖属性开销。
- 性能敏感的非UI数据： 对于那些访问频率极高、对性能有严格要求的非UI数据，普通CLR属性的直接字段访问通常会比依赖属性的字典查找更快。
- 不需要WPF高级特性的属性： 如果一个属性仅仅是存储一个值，不需要任何绑定、样式、动画、继承等WPF特有的功能，那么使用普通CLR属性是最简单、最直接的选择。
总的来说，依赖属性是WPF特有的“超级属性”，它为WPF带来了强大的声明式UI能力。而普通CLR属性则更像是C#语言本身提供的一种通用数据封装机制。在WPF开发中，我们常常是两者结合使用：UI层面的交互和展示逻辑依赖于依赖属性，而业务数据和内部状态则更多地通过普通CLR属性来管理。理解并恰当地运用它们，是编写高效、可维护WPF应用的关键。
