@Valid是JSR-303批注，JSR-303适用于JavaBeans上的验证。A
java.util.List不是JavaBean（根据JavaBean的官方描述），因此不能使用兼容JSR-303的验证器直接对其进行验证。这有两个观察结果支持。
第 3.1.3 中的JSR-303规范说：
除了支持实例验证之外，还支持对象图的验证。 图形验证的结果作为一组统一的约束违规返回。考虑以下情况： bean X包含类型Y的字段 。通过
使用@Valid注释 对 字段Y进行注释 ， 当X被验证时 ，验证器 将验证Y（及其属性）
。在运行时确定类型Y声明的字段（子类，实现）中包含的值的确切类型Z。使用Z的约束定义。这样可以确保标记为@Valid的关联具有正确的多态行为。集合值，数组值和 通常可 迭代的字段和属性也可以使用@Valid注释修饰
。这将使迭代器的内容得到验证。支持任何实现java.lang.Iterable的对象。
我已经用粗体标记了重要的信息。本节意味着，为了验证集合类型，必须将其封装在Bean中（由表示
Consider the situation wherebean X contains a field of type Y）；此外，集合不能直接验证（由表示
Collection-valued, array-valued and generally Iterable fields and properties may also be decorated，重点是
字段和属性 ）。
实际的JSR-303实现
我有一个示例应用程序，它使用Hibernate Validator和Apache Beans
Validator来测试集合验证。如果以
mvn clean test -Phibernate（使用Hibernate Validator）和
mvnclean test -Papache（用于Beans
Validator）对此示例运行测试，则两者都拒绝直接验证集合，这似乎与规范相符。由于Hibernate
Validator是JSR-303的参考实现，因此该示例进一步证明了必须将集合封装在Bean中才能进行验证。
清除这些内容后，我想说还有一个设计问题，即试图以问题中所示的方式将集合直接传递给控制器方法。即使验证直接在集合上进行，控制器方法也将无法使用其他不能直接映射到集合的数据表示形式，例如自定义XML，SOAP，ATOM，EDI，Google协议缓冲区等。为了支持这些表示，控制器必须接受并返回对象实例。那将需要以任何方式将集合封装在对象实例内。因此，
List如其他答案所建议的那样，最好将另一个对象包装在内部。
