Fluent UI Blazor 中记录类型对象导致对话框重置问题解析

问题现象

在使用 Fluent UI Blazor 4.9.0及以上版本时，开发人员发现当对话框组件(FluentDialog)使用记录类型(record)作为数据模型，并且设置了PreventDismissOnOverlayClick属性为true时，会出现一个特殊问题：当修改记录对象的任何属性后点击对话框外部遮罩层，会导致对话框被销毁并重新创建。

技术背景

记录类型(record)是C# 9.0引入的一种特殊引用类型，它默认实现了基于值的相等性比较。与类(class)不同，记录类型会自动生成Equals和GetHashCode方法，这些方法会考虑记录中所有属性的值。

Fluent UI Blazor组件内部使用GetHashCode方法来跟踪组件状态。当记录对象的属性发生变化时，其哈希值也会随之改变，这会触发Blazor的重新渲染机制。

问题根源

问题的核心在于记录类型的哈希值计算方式与FluentDialog组件的交互逻辑产生了冲突：

1. 记录类型会自动生成基于所有属性值的GetHashCode实现
2. FluentDialog组件内部使用哈希值来跟踪组件状态
3. 当记录属性改变时，哈希值变化导致组件被重新创建
4. PreventDismissOnOverlayClick设置阻止了对话框关闭，但无法阻止重新渲染

解决方案

针对这一问题，开发者可以采取以下几种解决方案：

方案一：重写GetHashCode方法

在记录类型中显式重写GetHashCode方法，返回基类的实现而非基于值的哈希：

public override int GetHashCode()
{
    return base.GetHashCode();
}

这种方法保留了记录类型的其他优点，同时避免了因属性变化导致的哈希值改变。

方案二：改用类(class)类型

如果不需要记录类型的特定功能，可以改用传统的类定义：

public class TestObject
{
    public string Value { get; set; }
}

方案三：降级Fluent UI Blazor版本

回退到4.9.0之前的版本可以避免这一问题，但这只是临时解决方案，不推荐长期使用。

最佳实践建议

1. 当需要在对话框中使用可变数据模型时，优先考虑使用类而非记录类型
2. 如果必须使用记录类型，确保重写GetHashCode方法
3. 对于复杂表单场景，考虑将对话框内容封装为独立组件，通过参数传递回调方法而非整个对象
4. 在Blazor Hybrid应用中，特别注意触摸设备上用户可能意外点击遮罩层的情况

总结

这个问题展示了Blazor框架中值类型比较与组件生命周期交互的一个典型案例。理解记录类型的特性及其对组件渲染的影响，有助于开发者编写更健壮的Blazor应用。在大多数对话框使用场景中，使用类类型或自定义哈希计算是更可靠的选择。