后台线程里给TextBox赋值，界面当场抛异常，这是Windows桌面开发里最经典的一个报错。报错文字本身已经把原因说明白了，真正要处理的是"怎么把这段更新送回UI线程"。
System.InvalidOperationException: Cross-thread operation not valid: Control 'textBox1' accessed from a thread other than the thread it was created on.
WPF里换了个说法，病因是同一个：
System.InvalidOperationException: The calling thread cannot access this object because a different thread owns it.
为什么非要回到UI线程
Windows的窗口消息是投递给创建窗口的那个线程的。鼠标移动、重绘、输入这些消息排成队列，由UI线程一条条取出来处理，控件句柄、GDI资源都绑在这条线程上。另一条线程直接改控件属性，等于绕开消息队列改状态，轻则显示错乱，重则随机崩溃。微软文档的原话是：调试时一定会抛这个异常，直接运行程序时不一定抛。这个"不一定"很害人，现场见过debug下崩、发布出去之后只是偶尔界面卡死不刷新，查了两天才回到线程上。
用Control.CheckForIllegalCrossThreadCalls = false把这个检查关掉能立刻消停，但这个开关只是不抛异常了，线程安全问题还在。旧项目里见过在Program.Main第一行就写了这行，后面接手的人只能一直带着这个雷。
WinForms的标准写法
先在UI线程上准备一个更新方法，然后判断当前是不是在UI线程：
private void SetText(string text)
{
if (textBox1.InvokeRequired)
{
textBox1.Invoke(new Action<string>(SetText), text);
return;
}
textBox1.Text = text;
}
InvokeRequired为false时说明已经在UI线程，直接赋值就行，不用再包一层。
Invoke是同步的，调用线程会一直等到UI线程把委托执行完。频繁刷进度条时用它会把后台线程拖慢，换成BeginInvoke投递出去不等待，界面刷新自然就跟上节奏了。之前在一个每秒推几百条日志的工具上做过对比，用BeginInvoke之后界面不再一顿一顿的，后台处理速度也回来了。
BeginInvoke有个前提：控件的窗口句柄必须已经创建。在窗体的构造函数里或者窗体还没Show出来的时候调BeginInvoke，会换一个报错：
InvalidOperationException: Invoke or BeginInvoke cannot be called on a control until the window handle has been created.
遇到这条就把更新挪到Form.Shown事件之后，或者先读一次Handle属性强制创建。
.NET 9里多了一个更好用的
Control.InvokeAsync从.NET 9开始才有，.NET Framework和.NET 8.0上找不到这个方法。它返回Task，可以await，天然适配async/await的代码：
await textBox1.InvokeAsync(() => textBox1.Text = "done");
能await意味着不会出现"后台线程等UI线程、UI线程又在等后台线程"的死锁，这是旧Invoke最常见的翻车方式。手上还在用.NET Framework 4.8、4.8.1或者.NET 6.0、8.0的项目，就只能继续用Invoke加回调。.NET 10在2025年11月11日发布，.NET 9是2024年11月12日，.NET 8是2023年11月14日，升级到9.0及以上就能直接享受这个写法。
async与await下的坑
很多人以为用了async/await就不会有跨线程问题。默认情况确实如此：await之后会回到原来的SynchronizationContext，UI上下文会自动把后续代码送回UI线程。但写了ConfigureAwait(false)就不一样了，它明确表示后续代码不必回到原上下文，会在线程池线程上继续执行：
await Task.Run(() => Load()).ConfigureAwait(false); label1.Text = "完成"; // 这里已经不在UI线程，会抛异常
实测这种写法在2026年一个移植到.NET 8.0的老项目上出现过好几次，报错行指向的居然是下一行赋值语句，不是await那行，第一眼看过去很难反应过来。
要在await期间报告进度，用IProgress<T>，Progress<T>在构造时捕获当前上下文，回调里的代码回到构造它的线程跑：
var progress = new Progress<int>(p => progressBar1.Value = p); await Task.Run(() => Work(progress));
.NET Framework 4.5起就有这个类型，比自己封一个带Invoke的事件省事。
还有一个容易写反的场景：Task.Wait()或者.Result。UI线程上调用它们会把UI线程堵住，如果那个Task内部又在用Invoke等UI线程执行，两边就互相干等，界面直接冻住。这种情况下要么全程await，要么在库代码里写ConfigureAwait(false)，二选一，别混着写。
WPF的写法
WPF用Dispatcher，判断用CheckAccess，返回true表示当前线程就是这个Dispatcher的线程：
if (!listBox1.Dispatcher.CheckAccess())
{
listBox1.Dispatcher.Invoke(() => listBox1.Items.Add(s));
}
else
{
listBox1.Items.Add(s);
}
Dispatcher.InvokeAsync自.NET Framework 4.5起可用，返回DispatcherOperation，同样能await。Dispatcher.Invoke还能指定优先级，比如DispatcherPriority.Background把刷新排在输入之后，滚动列表时更新大量条目就不会把界面拖住。
BackgroundWorker还在用吗
老项目里遍地都是。它从.NET Framework 2.0就有，ProgressChanged和RunWorkerCompleted这两个事件是框架自动封送回UI线程的，所以在事件处理函数里直接改控件不会报错。维护十年前的代码时改到这块，只要确认事件里没有额外开线程，可以不用改。
定时器也是常见的坑源
System.Windows.Forms.Timer的Tick在UI线程触发，改控件没问题。System.Threading.Timer和System.Timers.Timer的回调跑在线程池线程上，直接改控件就是本文开头那个报错。分不清的时候看回调里有没有InvokeRequired，有就说明已经不在UI线程了。
排查这类问题有个省事的办法：异常抛出后看调用栈最上面几帧，如果栈里面没有你写的UI事件处理函数，那基本可以确定是外部线程进来的。顺着InvokeRequired或者CheckAccess加一层判断，问题当场就消了。