有人对此有明确的答案吗？
该文档不承诺仅检索一次属性值。那么你must假设它可以多次检索它。
当然，实际上这种假设的行为可能永远不会发生。完全有道理的是，一旦检索到该属性，如果该属性从未发生过属性更改通知，则永远不会再次检索该属性，当然只读属性永远不会有属性更改通知。
所以你也许可以逃脱惩罚。但就我个人而言，我不会冒险。如果底层实现发生变化，或者您的假设由于任何原因是错误的，则同一命令的两个或多个实例将成为问题，至少如果该命令引发了CanExecuteChanged事件。我的意思是，我想如果CanExecute()状态永远不会改变，您可以拥有任意数量的对象副本，并且它们的工作方式完全相同。但如果它可以改变，那么您最终可能会在错误的命令对象上引发事件，而没有人在监听该事件。
这不仅仅是学术上的。 Microsoft 或您的代码有一天可能会使用的基于 XAML/MVVM 的 API 的其他一些实现者不仅可以选择放弃存储命令对象引用，而是指望能够始终从模型对象中检索它，而且从属性中检索命令对象是模型对象本身的常见做法。多次读取命令属性的情况是完全合理的并且值得担心。
更重要的是，我看不到背后的动机either选项。 “每次创建一个新的”对我来说显然是错误的，即使你可以逃脱它。延迟初始化似乎是过于复杂的代码，但没有任何好处。毕竟，在创建模型对象后，几乎总是会发生的下一件事是将属性绑定到 UI，因此此时将检索命令属性。延迟初始化最多会将底层字段的初始化延迟几毫秒（通常比这个时间短得多）。
如果你放弃惰性初始化，你可以使用自动属性：
public RelayCommand Command { get; } = new RelayCommand(CommandExecute);
没有明确的字段！好多了，恕我直言。
当然，请注意使用该语法CommandExecute()必须是一个static成员。大多数命令确实需要访问模型实例，因此上述命令不适用于这些命令。
惰性初始化模式流行的原因之一可能是它允许使用字段初始值设定项语法，这是通常的“不允许在字段初始值设定项中使用实例成员”规则的漏洞。
就我个人而言，对于使用当前实例的命令，我仍然会选择构造函数内初始化（这对于只读自动属性来说效果很好......您仍然不需要显式支持字段）。 Lazy-init 似乎还为时过早and在这种情况下错误优化。
