为何在事件处理程序中触发同一事件？是否会引发递归调用？

你的理解纠正 #

• 首先要明确：public delegate void ProductUpdateEvent(object? sender, EventArgs e);是委托类型的定义，不是事件。事件的正确声明形式应该是public event ProductUpdateEvent ProductUpdate;——事件是委托的封装，对外仅开放订阅/取消订阅操作，只有类内部才能触发。
• 你对+=的理解是正确的：将右侧Lambda作为处理程序添加到委托/事件的调用列表，当委托/事件被触发时，该Lambda会被执行。
• ProductUpdateEvent?.(this, EventArgs.Empty)的作用是：检查委托/事件的调用列表是否非空，若不为空则触发它，执行所有已订阅的处理程序。

你的疑惑解答 #

为什么这么写会出现递归风险？ #

按照你贴出的代码，必然会引发无限递归：

1. 当ProductUpdateEvent被触发时，会执行你添加的Lambda处理程序
2. Lambda内部又调用ProductUpdateEvent?.(this, EventArgs.Empty)，再次触发该委托/事件
3. 上述过程循环执行，直到栈内存耗尽抛出StackOverflowException

生产代码未出问题的可能原因 #

既然这是已上线的生产代码，大概率存在你没注意到的细节：

• 变量名混淆：实际代码中，Lambda里触发的是另一个完全不同的事件，只是名字和当前订阅的委托/事件相近，你误看成了同一个。
• 动态移除处理程序：feedConnector.getPrice(Products)方法内部，可能通过提前保存的Lambda引用，执行了ProductUpdateEvent -= savedLambda操作，移除当前处理程序，避免后续递归。（注：匿名Lambda无法直接移除，所以如果是这种情况，代码里的Lambda应该是有命名的委托实例）
• 业务逻辑限制：该事件在生产场景中只会被触发一次，且getPrice方法内部有逻辑阻止后续的事件触发（比如设置了某个标志位，让Lambda里的触发逻辑不再执行）。
• 代码遗留/修改：你看到的代码是旧版本，实际生产环境中这段递归触发的逻辑已经被注释或修改。

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