在Grails项目中使用Apache StringUtils而非Groovy Truth是否有优势？

针对你遇到的场景，团队坚持使用Apache StringUtils而非Groovy Truth，可能有以下你没注意到的原因：

• 语义明确，避免隐式规则混淆：Groovy Truth的判断逻辑是隐式的，不同类型（字符串、集合、数字等）的判断规则差异很大。比如字符串的Groovy Truth中，" "（空白字符串）会被视为true，如果后续需求改成判断非空白（对应StringUtils.isNotBlank），直接用Groovy Truth就会出错。而StringUtils的方法名（isNotEmpty/isNotBlank/isEmpty）直接说明了判断逻辑，任何人看代码都能立刻明白要做什么，不用去回忆Groovy的隐式规则。

• Java背景的习惯延续：很多Grails团队是从Java项目转型过来的，成员更熟悉Apache Commons工具类的用法。保持使用StringUtils可以让团队成员不用切换思维模式，尤其是当项目中还混合Java代码时，统一的工具类使用方式能降低认知成本。

• 代码风格的一致性：遗留代码已经大量使用StringUtils，团队选择不修改旧代码、新代码延续写法，是为了保持整体代码风格统一。统一的风格能减少维护时的心智负担，新成员接手时也能快速适应，不用在两种写法间切换。

• 避免Groovy Truth的新手陷阱：对于刚接触Groovy的开发者来说，很容易记错Groovy Truth的规则（比如误以为空白字符串会被视为false），而StringUtils的方法是显式的判断，几乎不会出现这类误解。团队可能是出于降低新人犯错概率的考虑，坚持使用更稳妥的显式写法。

• 空指针安全的心理安全感：虽然Groovy本身通过安全导航运算符、自动处理null的特性避免了很多NPE，但来自Java背景的开发者更信任StringUtils这类专门为null处理设计的工具类，觉得这种写法“更安全”，即使实际效果在当前场景下和Groovy Truth一致。

结合你的示例代码：

if (StringUtils.isNotEmpty(params.invoiceEventId)) {
 invoiceEvent = InvoiceEvent.findById(params.invoiceEventId)
}

这段代码用Groovy Truth改写是if (params.invoiceEventId)，两者行为一致，但团队选择保留StringUtils，大概率是出于上述的习惯统一、语义明确等长期维护层面的考虑。

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