事件订阅与生命周期

是什么，为什么存在

事件让对象公开“某件事已经发生”的通知点，而不必知道谁会响应。发出通知的对象叫发布者（publisher），注册响应代码的对象叫订阅者（subscriber），注册的方法或 lambda 是 事件处理器（event handler） 。按钮点击、属性变化、进度更新和连接状态变化都会用到它。

事件建立在委托（delegate）之上，但两者不是同一种公开接口。公开委托字段允许外部代码整体赋值、清空或调用；公开事件只允许外部代码使用 += 和 -=。这个限制把“何时发生”留给发布者，把“发生后做什么”留给订阅者。

一个事件可以注册多个处理器，因此通常由 多播委托（multicast delegate） 保存调用列表。通知仍发生在一个进程内，并且默认是同步方法调用。事件不是消息队列，也不会自动创建后台任务、跨线程调度或持久化消息。

当一个组件需要向数量未知的本地使用方广播状态变化，而且发布者不应依赖具体订阅者时，事件很合适。如果调用方必须得到返回值、控制执行顺序，或者失败需要参与发布者的事务，普通方法或显式回调（callback）通常更清楚。

工作原理

一个受限制的委托成员

public event EventHandler<OrderEventArgs>? Changed; 声明了一个字段式事件。事件的类型必须是委托类型。类的内部可以像使用委托一样读取和调用该事件，外部代码则只能通过事件的 add 和 remove 操作注册或移除处理器。

EventHandler 的签名是 void (object? sender, EventArgs e)。需要携带数据时，通常使用 EventHandler<TEventArgs>，把领域数据放入 EventArgs 派生类。sender 表示通知来源；如果订阅者已经明确持有来源，也不必为了使用这个参数而强制转换它。

字段式事件没有订阅者时，内部委托为 null。发布者通常使用 Changed?.Invoke(this, args)：有处理器就调用，没有则直接结束。外部代码不能写 publisher.Changed?.Invoke(...)，因为事件的调用权限属于声明它的类型。

通知路径可以画成下面这样。add 和 remove 操作改变调用列表；触发操作读取列表，再调用其中的处理器。

订阅、触发和取消订阅

+= 把处理器加入调用列表，重复添加同一个处理器会得到重复条目。-= 移除最后一个匹配的处理器；找不到匹配项时没有效果。若以后需要取消订阅，应保存命名方法或委托实例，而不是在 -= 处重新写一个看似相同的 lambda。

触发多播委托时，处理器按调用列表中的顺序同步执行。发布者的调用线程会一直执行这些处理器，直到全部返回或其中一个抛出异常。事件本身没有内置的优先级、重试、超时或异常隔离。

事件参数对象会依次传给每个处理器。对于可取消的“操作前”事件，处理器可以把共享参数的 Cancel 属性设为 true，发布者在通知结束后读取它。这个模式依赖明确契约：后面的处理器不应把已经为 true 的取消标志改回 false。

引用关系决定生命周期

实例方法委托包含目标对象和方法。只要发布者的调用列表保留这个委托，订阅者就通过 强引用（strong reference） 保持可达。局部变量离开作用域，并不足以让订阅者被垃圾回收。

当发布者比订阅者活得更久时，订阅者应在生命周期结束时执行 -=。常见做法是在 Dispose() 中取消订阅，或者让创建订阅关系的上层对象同时负责拆除它。若两者生命周期相同，额外取消订阅不一定有收益；判断依据是所有权，不是一条机械规则。

lambda 可能捕获 this、服务或大型对象图。即使处理器正文很短，捕获目标仍会随委托一起保留。静态事件和应用级单例发布者尤其需要检查，因为它们往往比页面、请求或临时服务活得更久。

示例

声明、触发和移除处理器

这个订单对象只公开状态事件，不公开底层委托。第一个状态变化会写入审计输出；移除同一个 audit 委托后，第二次变化不会再通知它。

StatusChanged 是字段式事件，只有 Order 能调用它。事件数据是不可变记录，订阅者看到的是一次状态迁移的快照。程序最后仍会打印当前状态，因此取消订阅并不影响订单自身的业务操作。

这里保存 audit 的原因不是语法偏好，而是身份。+= 和 -= 必须处理相等的委托，保存引用能让意图和生命周期都清楚。命名方法同样可以稳定地添加和移除。

让操作前事件可以取消

第二个例子在提交前发出通知。第一个处理器拒绝超过限额的总额，第二个处理器观察同一个参数对象，因此会看到已经设置的取消状态。

using System;

var checkout = new Checkout();

checkout.Submitting += (_, e) =>
{
    if (e.Total > 100m)
        e.Cancel = true;
};

checkout.Submitting += (_, e) =>
    Console.WriteLine($"observed cancel: {e.Cancel}");

Console.WriteLine($"accepted: {checkout.Submit(120m)}");

public sealed class SubmitEventArgs(decimal total) : EventArgs
{
    public decimal Total { get; } = total;
    public bool Cancel { get; set; }
}

public sealed class Checkout
{
    public event EventHandler<SubmitEventArgs>? Submitting;

    public bool Submit(decimal total)
    {
        var args = new SubmitEventArgs(total);
        Submitting?.Invoke(this, args);
        return !args.Cancel;
    }
}

# not executed here: the .NET SDK and C# compilers are unavailable

这个 API 明确把取消决定放在所有同步处理器运行之后。它没有用处理器返回值，因为多播调用会产生多个返回值，难以定义组合规则。可变参数适合这种窄用途，普通的“已经发生”事件则更适合不可变数据。

处理器顺序不应成为权限规则。这个示例约定处理器只能把 Cancel 从 false 设为 true；如果一个后注册处理器可以恢复提交，前面的拒绝就会失效。需要强制授权时，发布者本身必须执行最终检查。

看清异常传播

第三个例子注册三个处理器。第二个处理器抛出异常后，异常回到 Complete() 的调用方，第三个处理器不会运行。

using System;

var job = new Job();

job.Completed += (_, _) => Console.WriteLine("audit saved");
job.Completed += (_, _) => throw new InvalidOperationException("email failed");
job.Completed += (_, _) => Console.WriteLine("metrics updated");

try
{
    job.Complete();
}
catch (InvalidOperationException error)
{
    Console.WriteLine($"caught: {error.Message}");
}

public sealed class Job
{
    public event EventHandler? Completed;

    public void Complete()
    {
        Completed?.Invoke(this, EventArgs.Empty);
    }
}

# not executed here: the .NET SDK and C# compilers are unavailable

发布者不能假设每个订阅者都会获得通知。若“每个处理器都尝试一次”是契约的一部分，发布者必须取得调用列表，逐个调用并记录异常，然后定义如何向调用方报告多个失败。不要在每个事件上悄悄采用这种策略，它会改变错误语义。

也不要在处理器里无条件吞掉异常。处理器能在本地恢复时可以处理；不能恢复时，应让失败进入系统规定的错误边界。审计、邮件和指标是否允许彼此独立，是应用设计决定，不是 event 关键字替你做的决定。

把订阅绑到对象生命周期

最后一个例子让面板在构造时订阅，在 Dispose() 中移除同一个命名方法。using 块结束后的第二次触发不会再调用面板，订阅关系与对象的使用范围保持一致。

using System;

var ticker = new Ticker();

using (var panel = new StatusPanel(ticker))
{
    ticker.Tick();
}

ticker.Tick();
Console.WriteLine("done");

public sealed class Ticker
{
    public event EventHandler? Ticked;

    public void Tick() => Ticked?.Invoke(this, EventArgs.Empty);
}

public sealed class StatusPanel : IDisposable
{
    private readonly Ticker _ticker;

    public StatusPanel(Ticker ticker)
    {
        _ticker = ticker;
        _ticker.Ticked += OnTicked;
    }

    private void OnTicked(object? sender, EventArgs e) =>
        Console.WriteLine("panel refreshed");

    public void Dispose() => _ticker.Ticked -= OnTicked;
}

# not executed here: the .NET SDK and C# compilers are unavailable

Dispose() 在这里负责结束订阅，不代表对象持有非托管资源。这个用法仍然合理，因为它表达了必须确定结束的托管关系。调用者必须实际释放面板；仅仅实现接口不会自动执行清理。

有些框架已经提供加载与卸载钩子、订阅令牌或弱事件机制，应优先沿用框架的生命周期模型。手写的 IDisposable 适合所有权清楚的普通对象，但不要让多个位置同时猜测谁负责释放同一次订阅。

陷阱

用新 lambda 取消旧订阅

修复方法： 需要解除订阅时，把处理器保存为字段或局部委托，或者使用命名方法。测试应在解除后再次触发事件，确认处理器不再运行；只检查 -= 能否编译没有意义。

忘记长生命周期发布者仍持有订阅者

修复方法： 明确谁创建和销毁订阅关系，并在同一生命周期边界取消订阅。优先使用可验证的 IDisposable 或框架生命周期钩子；不要先写一套通用弱事件实现来掩盖所有权不清。

把同步事件当成异步管道

修复方法： 如果完成、取消和错误必须回到发布者，定义返回 Task 的明确异步契约，并规定处理器顺序或并行方式。真正的即发即弃通知也要把异常交给可观察的错误通道，而不是依靠进程级未处理异常。

假设每个处理器都会运行

修复方法： 必须维护业务不变量的操作应由发布者直接执行，并使用 try/finally 保护资源。只有当事件契约明确要求隔离失败时，才逐个调用处理器并聚合或记录异常。

认为 ?.Invoke 解决了线程问题

修复方法： 在事件契约中写明触发线程和重入规则。UI 订阅者应通过所属框架的调度器切回正确线程，共享状态则使用适合它的同步方式；取消订阅只能阻止未来取得的新列表，不能撤回已经开始的调用。

让外部处理器维护发布者不变量

修复方法： 发布者先完成并验证自己的状态变化，再发出“已经发生”事件。可取消的“即将发生”事件只能收集意见，最终授权和一致性检查仍由发布者负责。

延伸阅读

• C# 编程指南：事件
• 订阅和取消订阅事件
• .NET 标准事件模式
• event 关键字参考
• C# 语言规范：事件
• Delegate.GetInvocationList