WPF中MarkupExtension赋值ComboBox ItemsSource时SelectedItem不同步

自定义MarkupExtension直接返回集合实例给ItemsSource属性属于一次性静态赋值，没有接入WPF原生绑定引擎的同步链路，会导致两个核心问题：

• 赋值时机不受绑定引擎管控，大概率早于SelectedItem绑定的求值完成时间，此时ComboBox拿到ItemsSource后找不到对应选中项，直接把SelectedItem置为null
• 不会自动订阅DataContext变更、集合更新等事件，后续源数据变化时也无法触发SelectedItem的重新匹配

标准Binding的全流程由WPF绑定引擎托管，会自动对齐控件生命周期、监听所有相关变更事件、按正确顺序完成ItemsSource赋值和SelectedItem匹配，因此不会出现该问题。

不要在MarkupExtension.ProvideValue方法中直接返回你构造的集合对象，而是在方法内部构造一个配置完全匹配需求的原生Binding实例，调用该Binding的ProvideValue方法返回结果，把后续全流程交给原生绑定引擎处理，就能获得和标准Binding完全一致的表现。
参考实现代码：

public class ItemsSourceExtension : MarkupExtension
{
    public Type ModelType { get; set; }

    public override object ProvideValue(IServiceProvider serviceProvider)
    {
        // 替换为你自己的ModelType到数据源路径的映射逻辑
        var sourcePath = ModelType switch
        {
            typeof(Category) => "DataContext.Categories",
            // 其余类型映射自行补充
            _ => throw new ArgumentException($"未配置类型{ModelType.Name}对应的数据源路径")
        };

        // 构造和你正常使用完全一致的Binding实例
        var binding = new Binding(sourcePath)
        {
            RelativeSource = new RelativeSource(RelativeSourceMode.FindAncestor, typeof(DetailView), 1)
        };

        // 直接返回原生Binding的求值结果，所有绑定逻辑由WPF引擎接管
        return binding.ProvideValue(serviceProvider);
    }
}

注意事项 #

• 不要尝试通过继承Binding类自定义逻辑，Binding的核心同步逻辑大量依赖内部sealed方法，重写后极易破坏原有的值同步顺序
• 如果需要做额外的集合处理逻辑（比如过滤、排序），把逻辑封装到绑定转换器IValueConverter中接入Binding流程，不要脱离绑定链路直接处理集合返回
• 该写法天然兼容DataTemplate、ControlTemplate等模板场景，不需要额外处理模板中标记扩展的占位返回逻辑。

使用该方案后，原XAML写法ItemsSource="{ex:ItemsSource ModelType=m:Category}"的表现会和你手写的标准Binding完全一致，SelectedItem可以正常匹配显示，不会出现null问题。

内容的提问来源于stack exchange，提问作者Avrohom