如何通知Blazor WebAssembly感知JS对DOM的修改？

核心问题本质 #

Blazor依赖虚拟DOM与真实DOM的一致性完成渲染更新，直接通过JS修改真实DOM会打破这种一致性，当Blazor触发重绘（如StateHasChanged()调用、组件参数更新）时，虚拟DOM对比会出现偏差，最终导致渲染状态损坏。

关键解决方案 #

1. 优先通过更新数据源触发渲染（推荐） #

放弃直接用JS操作DOM，转而修改Blazor的数据源集合els，再通过StateHasChanged()触发局部渲染：

• 修改span的textContent：找到els中对应Key的项，更新其String属性，调用StateHasChanged()，Blazor会基于@key复用原span元素并更新内容，无需全量重绘。
• 拆分span：在els集合的对应位置移除原item，插入拆分后的两个新item（需确保新item有唯一Key），调用StateHasChanged()，Blazor会精准更新DOM结构。
• 添加span：向els集合中插入新的item，调用StateHasChanged()，Blazor自动渲染新增的span元素。

2. 临时JS操作DOM的修复方案 #

如果出于性能考量需要临时用JS修改DOM（比如避免高频触发Blazor渲染），则必须在Blazor触发重绘之前，将真实DOM恢复到与els数据源完全一致的状态。否则虚拟DOM与真实DOM的对比会出错，导致渲染混乱。

关于dispatchEvent('change')的问题 #

这种方式无法解决DOM同步问题：

• Blazor不会监听contenteditable元素的change事件来同步虚拟DOM，事件触发后不会更新Blazor的数据源或虚拟DOM。
• 潜在问题：可能误触发其他绑定的事件处理逻辑，引发意外行为；且根本无法修复虚拟DOM与真实DOM的不一致，重绘时状态损坏的问题依然存在。

初始渲染性能优化建议 #

• 保留@key属性：Blazor会基于Key复用DOM元素，大幅减少重绘时的DOM操作。
• 合理拆分组件粒度：不要将单个span封装为自定义组件（会增加组件实例开销），可将els按固定数量拆分（如每200个span一组），封装为子组件，缩小重绘范围。
• 分批渲染：如果els数据量极大，可实现滚动加载（虽无法虚拟化，但可以分批渲染可见区域外的内容）。

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