event 的 += 和 -= 操作本身是线程安全的
CLR 保证
event的订阅（
+=）和取消订阅（
-=）是原子操作，底层通过
Interlocked.CompareExchange实现。这意味着多个线程同时调用
myEvent += handler不会导致委托链损坏或 NullReferenceException。
但注意：这只是「修改事件字段」安全，不等于「触发事件」安全，也不等于「事件处理逻辑」安全。
如果在事件触发前，另一个线程刚执行了-=，而你没做空检查，
myEvent?.Invoke()仍可能为 null（虽然概率低，但非零） 委托链内部的合并/拆分虽原子，但若多个线程反复高频订阅/取消，可能因引用竞争导致某次
Invoke调用漏掉部分 handler（罕见，但 .NET Framework 4.5 以前有报告） .NET Core / .NET 5+ 对
MulticastDelegate的操作做了更强一致性保证，但仍建议显式防御
触发 event 时必须手动判空并快照委托引用
直接写
MyEvent?.Invoke(args)在多线程下存在竞态：判断非空后，另一线程可能立刻把
MyEvent设为
null，导致
Invoke抛出
NullReferenceException。
正确做法是先读取一次委托引用，再判空调用：
var handler = MyEvent;
if (handler != null)
{
handler(args);
}
这个模式叫「委托快照（delegate snapshot）」，本质是避免两次读取字段带来的状态漂移。
不能用lock(this)或其他锁包裹整个
Invoke—— 会把调用方线程拖进你的锁，极易引发死锁或性能瓶颈 快照方式开销极小，且符合事件「fire-and-forget」语义 如果事件是
static，快照变量也应是局部的，不要缓存到字段里
委托指向的方法体不是自动线程安全的
委托本身只是方法指针 + 目标对象引用，它不提供任何同步机制。如果你的事件处理器里修改了共享字段、集合或 UI 控件，线程安全责任完全在你自己。
常见陷阱场景：
UI 线程事件（如 WinFormsButton.Click）在 UI 线程触发，但若你从后台线程触发自定义事件，处理器可能在非 UI 线程执行 → 直接访问
textBox.Text抛
InvalidOperationException多个线程触发同一事件，处理器中更新
List<t></t>未加锁 →
IndexOutOfRangeException或数据丢失 使用
async void事件处理器，异常无法被外层捕获，且上下文切换可能放大竞态
解决方向取决于场景：
— UI 更新走
Control.Invoke或
Dispatcher.Invoke
— 共享数据结构换用
ConcurrentQueue<t></t>、
ConcurrentDictionary<k></k>
— 真需要锁时，优先用
ReaderWriterLockSlim而非
lock，尤其读多写少
自定义 event 访问器要格外小心
一旦你用
add/
remove块显式实现事件（比如为了日志、限流或线程调度），所有线程安全假设都失效。CLR 不再介入，完全由你负责。
例如下面这段代码是危险的：
private EventHandler _handlers;
public event EventHandler MyEvent
{
add { _handlers += value; } // 非原子！
remove { _handlers -= value; }
}
因为
_handlers += value是「读-改-写」三步操作，在多线程下会丢失更新。 必须手动同步：用
lock、
Interlocked或
ConcurrentQueue管理委托列表 若想保持快照语义，
add中也要用快照方式合并，
remove中用
Delegate.Remove并赋值回字段 更推荐的做法是：除非真有特殊需求，否则别手写访问器；用编译器生成的默认事件，只在触发处做快照 委托链的线程安全边界非常窄——只保订阅/取消动作，其余全是灰色地带。最常被忽略的是：你以为用了 event 就“自带同步”，结果在
Invoke前没快照、处理器里乱改共享状态、或者手写访问器时把
+=当成原子操作。
