Java SE工具类API是否需全面使用Jakarta Validation注解？

在Java SE环境下开发工具类API，没必要给所有公共方法的输入参数全量添加Jakarta Validation注解，得根据参数的实际情况和工具类的使用场景来判断，下面分情况说明：

何时有必要使用 #

• 约束逻辑复杂且易重复的参数：比如要求参数是正整数、非空且元素长度符合要求的集合这类有明确规则的参数，用@Positive、@NotEmpty这类注解，既能替代重复手写的校验代码，又能把约束规则直观地暴露给调用者，比纯Javadoc更精准。
• 涉及核心功能或安全的参数：比如加密工具的密钥参数、数据转换工具的源数据参数，这类参数的合法性直接影响功能能否正常运行甚至数据安全，用@NonNull、@NotBlank等注解强制校验，能提前拦截非法输入，避免后续逻辑崩溃，同时明确告知调用者这是硬约束。
• 被广泛复用的公共工具方法：如果你的工具类是给多个团队或项目使用的，注解相当于自带的约束文档，调用者不用翻源码就能快速get参数要求，减少沟通和踩坑成本。

何时不推荐使用 #

• 参数约束不言自明的场景：比如int、long这类基本类型参数，本身就不可能为null，再加@NonNull纯属冗余；或者像trim(String str)这种方法，传null虽然会报错，但逻辑上调用者应该能预判，硬加注解反而让代码显得啰嗦。
• 性能敏感的高频调用方法：Jakarta Validation的校验是运行时动态执行的，有一定性能开销。如果工具方法会被高频调用（比如在循环里每秒调用上万次），注解带来的额外开销会被放大，这种情况要么手动做极简校验，要么把校验责任交给调用者更合适。
• 约束依赖上下文的参数：比如某个参数的合法范围依赖另一个参数的取值，这种复杂的关联约束没法用单一注解表达，硬加注解反而会误导调用者，不如在Javadoc里写清楚逻辑，或者手动编写关联校验代码。

另外要注意：Java SE环境下Jakarta Validation不会自动触发校验，你得自己通过Validator实例手动执行校验逻辑。如果只是加了注解但没做校验，那注解就只有文档作用——这种情况下，你得权衡：是加注解更清晰，还是写一段精准的Javadoc更高效？

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