生产代码中是否应使用FluentAssertions？技术疑问解析

我太懂你的纠结了——FluentAssertions的语法写起来真的顺手，写生产代码里的守卫语句时，总忍不住想“这不就是它已经实现的功能吗？”，为啥大家只在单元测试里提它？结合实际开发中的各种考量，我整理了几个核心原因：

1. 设计目标从一开始就不一样 #

FluentAssertions从诞生就是为测试场景量身打造的：它的核心价值是生成清晰、人话般的失败提示，帮你一眼定位测试哪里出了问题。比如写user.Should().NotBeNull("因为后续流程必须依赖用户信息")，测试失败时会直接抛出带自定义说明的异常，这在测试里是刚需。但生产代码中，我们更关注异常的标准类型（比如ArgumentNullException），而非格式化后的友好描述——毕竟生产环境的异常日志要靠类型做监控、告警和统一处理，自然语言的提示反而不如标准异常类型实用。

2. 性能与依赖的实际权衡 #

你提到的性能顾虑确实是个实际问题：FluentAssertions的链式调用会产生额外的对象实例和方法调用，单个断言的开销极小，但在高并发、高频执行的生产路径里（比如API的参数校验逻辑），累积起来的开销可能会被放大。而且引入这个库意味着生产依赖多了一个第三方包，哪怕它再稳定，也会带来版本兼容、安全扫描的额外成本——很多团队都会尽量精简生产依赖，只留最核心的那部分。

当然“不要过早优化”的原则没错，但生产代码和测试场景的性能考量完全不同：测试代码跑一次就结束，生产代码可是7*24小时不间断运行的，微小的开销在海量请求下会被无限放大，这时候可读性和性能的天平会偏向后者。

3. 生产代码的异常规范要求 #

生产代码里，我们通常需要抛出符合.NET规范的标准异常类型，比如ArgumentNullException、ArgumentException，但FluentAssertions默认抛出的是对应测试框架的异常（比如Xunit的XunitException），这类异常在生产环境中完全不符合规范——总不能让API给用户返回一个测试框架的异常吧？虽然可以自定义抛出的异常类型，但这会让FluentAssertions的使用变得复杂，反而不如直接写守卫语句简洁：

// 生产代码里的标准守卫语句
if (user == null) throw new ArgumentNullException(nameof(user), "用户信息不能为空");

// 用FluentAssertions自定义异常的写法，反而麻烦
user.Should().NotBeNull("用户信息不能为空")
    .And.Subject.Should().NotBeNull()
    .WithMessage("自定义消息")
    .Throw<ArgumentNullException>(); // 这显然不如直接throw来得直观

4. 团队共识与代码习惯的影响 #

很多团队的编码规范里，生产代码的参数校验就是用守卫语句或者内置的ArgumentGuard类（比如Microsoft.Extensions里的实现），大家已经形成了统一的习惯。突然把FluentAssertions引入生产代码，会让新成员困惑：“为什么这里要用测试库的语法？”，反而增加了认知成本。而测试场景里用它是行业共识，所有人都觉得理所当然。

最后想说 #

当然，如果你的团队不在乎这些细节，并且觉得FluentAssertions的可读性带来的收益大于性能和依赖的成本，完全可以在生产代码里用——技术选择从来没有绝对的对错。但大多数情况下，大家会把它限制在测试场景，因为那里才是它能发挥最大价值的地方。

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