Blazor MAUI Hybrid中为何需连续两次调用StateHasChanged()更新UI？

可能的原因 #

• 组件初始渲染周期冲突：在OnInitializedAsync中订阅Action后立即调用StateHasChanged()，此时组件可能还未完成初始渲染流程。第一次调用仅标记组件需要更新，但MudTabs的内部状态（如Tab项的Badge状态）尚未完成初始化，导致UI未同步。第二次调用时组件已完成初始渲染，状态变更才会被MudTabs的内部逻辑捕获。
• Fluxor Action的上下文问题：Fluxor分发Action的处理逻辑可能运行在Blazor渲染上下文之外。单次StateHasChanged()仅触发组件的基础渲染，但MudTabs依赖的Tab状态计算可能需要等待下一个渲染周期才能完成，第二次调用才会触发完整的状态同步。
• MudTabs内部渲染逻辑限制：MudTabs的BadgeDot并非直接响应HasBadge属性变更，而是需要组件内部重新计算并更新Tab项的状态。单次StateHasChanged()可能仅更新了组件的属性值，但未触发MudTabs内部的状态刷新逻辑，第二次调用才会强制组件重新处理所有Tab的渲染状态。

可行的解决方法 #

• 改用Fluxor的状态自动订阅：放弃手动订阅Action，使用Fluxor的[FeatureState]特性或SubscribeToState方法绑定状态。当状态变更时，Fluxor会自动触发组件的渲染，无需手动调用StateHasChanged()，避免手动调用的时机问题。
• 确保在Blazor上下文执行更新：将StateHasChanged()包裹在InvokeAsync中，确保在Blazor的同步执行上下文内触发渲染：

  await InvokeAsync(StateHasChanged);
  

• 检查异步方法的await时机：如果UpdateTabBadges是异步方法，确保先await该方法完成，确认HasBadge属性已完全更新后，再调用状态更新方法，避免属性未变更就触发渲染。
• 验证MudTabs的绑定逻辑：确认HasBadge与MudTabs的Tab项绑定正确，确保是单向绑定（直接传递参数）或正确的双向绑定，避免因绑定方式错误导致属性变更未传递到组件内部。

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