移除ObservableCollection的BlockReentrancy()后仅替换元素是否有风险？

• 无限更新循环风险：
  只要你的业务逻辑不会形成触发闭环（比如修改字节A触发事件，事件里修改字节B，而修改B又反过来触发修改A），就不会出现无限循环。因为你只做Replace操作，每次都是修改已有元素值，没有结构变化。但如果存在这种互相触发的逻辑，不管有没有BlockReentrancy，都会陷入循环，这时候需要在代码里加判断（比如标记正在处理状态，跳过重复触发）来规避。

• 状态不一致风险：
  原ObservableCollection的BlockReentrancy主要是防止集合结构（增、删、移元素）在通知过程中变化，导致枚举或状态混乱。但你的场景只做Replace，不会改变集合长度和元素位置，只是更新元素值。这种情况下，移除BlockReentrancy后，单线程场景下基本不会出现状态不一致；如果是多线程场景，需要额外加锁保证线程安全，因为原集合本身就不是线程安全的。

• 方案合理性判断：
  从你的特定场景来说是合理的，但要守住几个前提：

  1. 严格限制只执行Replace操作，绝对不能在任何流程中进行增删移动元素的操作，否则原BlockReentrancy防护的问题（比如UI控件枚举集合时出错）就会出现。
  2. 必须在业务逻辑中避免CollectionChanged事件的循环触发，这是核心风险，需要自己在代码里控制。
  3. 多线程环境下要额外处理同步逻辑，避免并发修改导致的异常。

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