异步方法触发事件的C#事件处理器无法访问UI对象的解决方案咨询

我有一个类会运行异步方法，完成后触发事件：

public class PdfRenderer
{
    public Uri PdfUri { get; set; }
    public event EventHandler PdfCreated;

    protected virtual void onPdfCreated(EventArgs e)
    {
        PdfCreated?.Invoke(this, e);
    }

    public async Task renderPdfAsync()
    {
        PdfUri = await renderPdf();
        onPdfCreated(new EventArgs());
    }
}

在WPF窗体代码中，我订阅了这个事件。事件处理器有时候正常工作，有时候会报错，当访问窗体里的WebView2控件时出现以下错误：

"The calling thread cannot access this object because a different thread owns it."

窗体代码如下：

public PdfReport()
{
    InitializeComponent();
    // 在窗体构造函数中订阅渲染器，并让它们并发执行任务
    for (int i = 0; i < renderers.Count; i++)
    {
        renderers[i].PdfCreated += PdfReport_PdfCreated;
        renderers[i].renderPdfAsync();
    }
}

private void PdfReport_PdfCreated(object sender, System.EventArgs e)
{
    PdfRenderer renderer = sender as PdfRenderer;
    if (renderer is null) return;

    webView.Source = renderer.PdfUri; // 有时会报错
}

堆栈跟踪信息：

at System.Windows.Threading.Dispatcher.VerifyAccess()
at System.Windows.DependencyObject.SetValue(DependencyProperty dp, Object value)
at Microsoft.Web.WebView2.Wpf.WebView2.set_Source(Uri value)
at Lusas.DesignLib.UI.ReportView.showPDFForSelectedDesignCheck(Uri pdfUri) in E:\xxx\PdfReport.xaml.cs:line 133

有没有更好的方法将事件发送到UI线程，避免这个错误？

看起来你遇到了WPF里异步事件跨线程访问UI控件的经典问题，我来帮你拆解原因和解决办法：

问题根源 #

WPF的UI控件有线程亲和性——只能由创建它们的UI主线程访问。你的renderPdfAsync方法里，await renderPdf()之后的代码执行线程取决于异步操作完成时的上下文：如果renderPdf是在后台线程完成的，onPdfCreated就会在后台线程触发事件，此时事件处理器直接访问webView自然就会抛出线程访问错误。

解决方案 #

这里提供三种靠谱的处理方式，你可以根据自己的代码场景选择：

方案1：在事件处理器中主动切换到UI线程

这种方式无需修改PdfRenderer类，只需要在事件处理器里检查当前线程是否有权限访问UI控件，没有的话通过Dispatcher切换到UI线程执行操作：

private void PdfReport_PdfCreated(object sender, System.EventArgs e)
{
    PdfRenderer renderer = sender as PdfRenderer;
    if (renderer is null) return;

    // 检查当前线程是否能直接操作WebView2
    if (!webView.Dispatcher.CheckAccess())
    {
        // 切换到UI线程执行设置操作
        webView.Dispatcher.Invoke(() => 
        {
            webView.Source = renderer.PdfUri;
        });
        return;
    }

    // 已经在UI线程，直接操作
    webView.Source = renderer.PdfUri;
}

如果不想阻塞当前线程，也可以用Dispatcher.BeginInvoke异步执行，但设置Source是轻量操作，用Invoke同步执行更稳妥。

方案2：让PdfRenderer确保事件在UI线程触发

如果希望PdfRenderer自身封装线程处理逻辑，让调用者不用关心线程问题，可以在初始化时捕获UI线程的同步上下文，触发事件时用这个上下文执行：

public class PdfRenderer
{
    private readonly SynchronizationContext _syncContext;

    public Uri PdfUri { get; set; }
    public event EventHandler PdfCreated;

    public PdfRenderer()
    {
        // 捕获当前同步上下文（如果在UI线程创建实例，就是UI同步上下文）
        _syncContext = SynchronizationContext.Current ?? new SynchronizationContext();
    }

    protected virtual void onPdfCreated(EventArgs e)
    {
        // 通过捕获的上下文触发事件，确保在创建实例的线程执行
        _syncContext.Post(_ => 
        {
            PdfCreated?.Invoke(this, e);
        }, null);
    }

    public async Task renderPdfAsync()
    {
        PdfUri = await renderPdf();
        onPdfCreated(new EventArgs());
    }

    // 你的实际PDF渲染方法
    private Task<Uri> renderPdf()
    {
        // 模拟异步操作
        return Task.FromResult(new Uri("your-pdf-path"));
    }
}

这样不管renderPdf在哪个线程完成，事件都会在UI线程触发，处理器里直接操作控件就不会报错了。

方案3：确保await后回到UI线程

如果renderPdfAsync是在UI线程调用的（你的代码里确实是在窗体构造函数，也就是UI线程调用的），可以在await时明确使用ConfigureAwait(true)（默认是true，但如果renderPdf内部用了ConfigureAwait(false)可能失效），保证后续代码回到UI线程：

public async Task renderPdfAsync()
{
    // 确保await后回到原始上下文（UI线程）
    PdfUri = await renderPdf().ConfigureAwait(true);
    onPdfCreated(new EventArgs());
}

这个方案的局限性是：如果renderPdf内部的异步操作已经脱离了UI上下文，可能无法保证回到UI线程，所以前两种方案更稳妥。

总结 #

• 如果你希望PdfRenderer保持通用性（不依赖WPF），优先选方案1；
• 如果你想让调用者完全不用关心线程问题，优先选方案2。

备注：内容来源于stack exchange，提问作者Tsaras