校验失效主因是未覆盖真实入参路径：dto注解校验被原始请求读取、map/object接收、嵌套json手动解析等绕过；须强制dto绑定、禁用裸request访问、启用嵌套校验、统一拦截异常并严控json字符串语义校验。
参数校验形同虚设，本质不是没写校验逻辑，而是校验没落到真实入参路径上。Spring Boot 项目里，很多团队加了 @Valid、写了 @NotBlank，但攻击者仍能绕过——因为校验只作用于 DTO 字段，而实际业务逻辑直接从 HttpServletRequest、QueryParameter、RequestBody 原始流或反射取值，或者用了不校验的 Map/JSONObject 接收参数。
绕过常见场景：校验没覆盖到“真入口”
校验失效往往发生在这些地方：
- 用
@RequestParam Map<string string> params</string>或MultiValueMap接收所有参数，跳过了 Bean Validation 的字段级约束 - 控制器方法里手动调用
request.getParameter("xxx")或request.getInputStream()读原始数据，完全绕开 Spring 的绑定与校验流程 - DTO 中某个字段是
Object、Map或JsonNode类型，校验注解对其内部结构无效（如@Valid不递归校验 Map 的 value） - 使用
@RequestBody接收泛型类型（如ResponseEntity<object></object>），JSON 反序列化后未做二次类型转换和校验 - 前端传参用数组、嵌套 JSON 字符串，后端用
String字段接收再手动JSON.parse()，校验只拦住了字符串长度，没拦住内部恶意内容
关键防御动作：让校验真正生效
光加注解不够，必须确保校验链路完整闭合：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 禁用原始参数读取：在全局配置中关闭
spring.mvc.throw-exception-if-no-handler-found=true，并统一拦截所有非标准参数访问，比如自定义HandlerMethodArgumentResolver替代裸 request 调用 - 强制 DTO 绑定：所有接口必须声明明确的入参 DTO，禁止使用
Map、Object、String接收结构化业务参数；对动态字段需求，改用@Validated+ 自定义约束注解（如@SafeJson校验 JSON 内容合法性） - 启用嵌套校验：DTO 中含子对象时，子类字段必须加
@Valid，且主类校验需显式触发（@Validated配合分组校验更可控） - 校验失败统一拦截：配置
@ControllerAdvice捕获MethodArgumentNotValidException和ConstraintViolationException，返回标准化错误，避免堆栈暴露细节 - 对 JSON 字符串字段额外防护：若字段类型为
String但语义是 JSON（如extraInfo），应在@PostConstruct或@EventListener中解析并校验其结构，或用自定义ConstraintValidator<safejson string></safejson>做语法+语义双检
容易被忽略的“伪校验”陷阱
这些做法看着像校验，实则毫无防护力：
- 只在校验 DTO 上加
@Size(max=50)，但数据库字段是VARCHAR(255)，且 SQL 插入前没做截断或拒绝——攻击者仍可提交超长 payload 触发服务端异常或缓冲区问题 - 用
@Pattern匹配邮箱格式，但正则太宽松（如.*@.*），无法防注入；应结合白名单字符集（如[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}）并限制总长 - 在 Service 层做“二次校验”，但 Controller 已把非法参数转成对象传入——此时校验只是补救，异常可能已污染上下文或触发日志泄露
- 开启
spring.jackson.deserialization.fail-on-unknown-properties=true，但没配合@JsonIgnoreProperties(ignoreUnknown = true)控制反序列化范围，导致攻击者通过未知字段名试探接口行为
校验要起作用，就得让它出现在数据进入业务逻辑前的最后一道门。不是加了注解就安全，而是每个参数都必须经过可审计、不可绕过的验证路径。
