启用F#警告等级5后大量触发FS1178警告，添加NoComparison/NoEquality属性的收益咨询

我来帮你拆解一下给这些类型添加NoEquality/NoComparison属性能带来的实际好处，毕竟在大型F#代码库里面对几百条警告，得搞清楚这么做值不值对吧？

• 消除冗余警告，聚焦关键问题
  开启警告等级5后，这类FS1178警告会占据大量输出，让你很难发现其他更重要的潜在问题（比如未使用的变量、类型不匹配等）。添加属性后，能精准抑制这些已知的、非功能性的警告，让代码库的警告列表回归整洁，方便你快速定位真正需要修复的bug。

• 明确类型意图，提升代码可读性
  F#默认会为结构体、记录和联合类型自动生成相等性比较逻辑，但当你的类型包含函数类型（比如unit -> IBar option）或不支持相等的C#类型时，默认的相等性逻辑根本无法正常工作。添加NoEquality/NoComparison属性相当于给所有开发者（包括未来的你）一个清晰的提示：这个类型不应该被用于相等性比较或排序，避免有人误用=、<>或hash等操作。

• 提前拦截运行时异常与错误行为
  如果不添加属性，有人不小心对这类类型执行相等性比较，F#会尝试生成默认逻辑，但遇到函数类型或不支持相等的成员时，要么抛出InvalidOperationException，要么返回毫无意义的结果（比如函数引用的比较是基于内存地址的，这通常不是业务逻辑想要的）。添加属性后，编译器会在编译期就阻止这类错误操作，把问题扼杀在开发阶段，而不是等到线上出故障才排查。

• 优化大型代码库的编译性能
  对于大型F#项目，编译器在处理这些类型时，会反复推导相等性约束是否满足，这会额外消耗编译时间。添加NoEquality/NoComparison属性后，编译器可以直接跳过这些推导步骤，减少编译开销，尤其是增量编译时，能明显提升构建速度。

• 贴合F#设计哲学，增强代码健壮性
  F#的设计核心之一是静态安全与显式意图。通过这些属性，你是主动定义类型的使用边界，而不是依赖编译器的默认行为或让开发者猜测类型能力。这种显式约束能大幅降低因误解类型功能而产生的bug，让代码更健壮、更易于维护。

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