为何从后台线程更新UI属于不良开发实践？

所有主流桌面、移动端GUI框架（WinForm/WPF/Android/iOS/Web DOM）的UI体系，本质都是单线程模型设计，跨线程直接更新UI属于违反底层设计规则的操作，出问题是必然的。

• 首先是UI线程的串行调度规则
  整个界面的所有控件绘制、用户输入响应、属性变更、事件触发，全部由唯一的UI线程（主线程）负责处理。这个线程内部维护了一个消息队列，所有和UI相关的操作都会按顺序塞进队列，UI线程循环从队列取任务挨个执行，从设计上避免多线程同时操作同一个控件状态的竞态问题。
  如果你在后台线程直接修改UI元素，相当于绕开了这个队列调度：比如后台线程改文本框内容的时候，UI线程刚好在渲染这个文本框，两边同时操作同一块内存——一边改文本长度，一边按旧长度计算渲染坐标，轻则出现内容错位、显示花屏，重则直接触发内存越界，把整个进程干崩。
• 其次是跨线程校验和死锁风险
  现在大部分GUI框架默认都开了跨线程访问校验：只要检测到不是创建控件的UI线程在操作控件，直接抛出非法跨线程调用异常。如果写代码的时候没做异常捕获，直接把异常吞了，后台线程会卡在异常点；要是这时候后台线程持有UI线程正在等待的锁资源，直接就会形成死锁，整个界面完全不响应任何点击、输入操作，也就是你说的UI挂起。
  哪怕你手动关掉框架的跨线程校验（比如WinForm里把CheckForIllegalCrossThreadCalls = false），问题也不会消失：后台线程修改控件状态不会自动往UI消息队列塞正确的重绘请求，要么改完的内容半天不刷新，要么大量无序的重绘请求把消息队列堵死，界面点关闭按钮都要等几秒才有反应，本质还是假死。
• 最后说下为什么框架不把UI控件做成线程安全的
  本质是成本和收益的权衡：如果给每个控件的所有属性、方法都加线程锁来支持多线程访问，UI本身是高频操作场景，每秒上百次的绘制、事件响应都要反复加锁解锁，性能损耗会非常大；同时多线程下锁的粒度极难控制，反而会比单线程模型更容易出现死锁，开发和调试成本飙升。所以所有GUI框架统一选择了单线程模型：只允许UI线程操作控件，其他线程要更新UI，必须把更新操作封装成任务投递到UI线程的消息队列里排队执行。

举个最常见的正确写法示例：

// 错误：后台线程直接操作UI，大概率触发异常或死锁
Task.Run(() => {
    processBar.Value = 80;
});

// 正确：耗时操作放后台，UI更新切回UI线程调度
Task.Run(() => {
    // 后台跑耗时计算、IO等不碰UI的逻辑
    var progress = CalculateProgress();
    // 把UI更新操作投递到UI线程队列执行
    Dispatcher.Invoke(() => {
        processBar.Value = progress;
    });
});

不要试图绕过框架的跨线程校验。那些偶发、复现概率极低的界面错乱、无理由崩溃，十有八九都是不规范的跨线程UI更新导致的，排查成本极高。

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