后端必须定义明确、可执行、可验证的参数校验规范，涵盖必填性、类型格式、取值范围、长度、枚举等字段级规则；请求体需分层建模为专用DTO；统一400错误响应格式；边界场景（空字符串、时间格式、数组、敏感字段）须明确定义。
前端传参的校验标准不能只靠前端“自觉”，必须由后端定义明确、可执行、可验证的规范，否则容易出现绕过校验、数据污染、接口崩溃等问题。核心原则是：**后端定义契约，前后端对齐字段语义与约束，校验逻辑统一落地在服务端**。
字段级校验规则必须写进接口文档
每个请求参数（包括路径变量、查询参数、请求体字段）都应明确标注：
-
是否必填（如
@NotBlank、@NotNull、@NotEmpty，注意三者适用场景不同） -
数据类型与格式（如邮箱用
@Email，手机号用@Pattern(regexp = "^1[3-9]\d{9}$")） -
取值范围（如年龄用
@Min(1) @Max(150)，金额用@DecimalMin("0.01")） -
长度限制（如用户名
@Size(min = 2, max = 20)，而非仅靠前端 maxlength） -
枚举约束（如状态字段用
@Pattern(regexp = "PENDING|APPROVED|REJECTED")或自定义@EnumValue注解）
请求体结构需分层建模，避免混用实体类
不要直接用数据库实体（如 User）接收前端参数。应按用途拆分为：
-
入参 DTO（如
UserCreateParam）：只包含创建时需要的字段，每个字段带完整校验注解 -
更新 DTO（如
UserUpdateParam）：支持部分更新，可结合@Validated分组（如CreateGroup.class/UpdateGroup.class） -
查询 DTO（如
UserQueryParam）：对分页参数（pageNo,pageSize）也做校验（如@Min(1) @Max(1000)）
这样既保证职责清晰，又避免校验逻辑污染持久层模型。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“前端免费学习笔记（深入）”；
统一错误响应格式，暴露有意义的提示
校验失败时不返回堆栈或默认英文消息，而是返回结构化错误信息：
- 状态码统一为
400 Bad Request - 响应体含
code（如"VALIDATION_ERROR"）、message（简明中文提示，如"手机号格式不正确"）、details（字段级错误列表，含field和reason） - 示例：{"code":"VALIDATION_ERROR","message":"参数校验失败","details":[{"field":"phone","reason":"手机号格式不正确"}]}
边界场景必须明确定义并覆盖
以下情况常被忽略，但需在规范中写死：
-
空字符串 vs null：约定所有字符串类型参数禁止传
null，空字符串视为有效值（除非业务要求非空），用@NotBlank而非@NotNull -
时间格式：强制使用 ISO 8601（如
"2026-09-25T07:42:00"），后端用@PastOrPresent或@Future校验，不接受时间戳数字 -
数组/集合参数：明确最大长度（
@Size(max = 50)）、元素是否允许为空（@NotEmpty作用于 List 自身，@NotBlank作用于每个 String 元素） -
敏感字段过滤：如密码字段必须有
@Size(min = 8, max = 32)+@Pattern强度要求，且禁止出现在响应中
