参数校验失败的常见场景
开发接口时，前端传了个空字符串给用户ID字段，后端直接查数据库，结果抛异常。这种问题太常见了。参数校验失败不是系统崩溃的理由，而是程序该优雅处理的第一道防线。
比如用户注册时手机号格式不对、必填项没填、数字超出范围，这些都不是“出错了”，而是“输入不符合要求”。处理方式也就不该是返回500，而是明确告诉调用方：你哪里错了。
返回清晰的错误信息
别只返回一个“参数错误”。用户看到这种提示，只会一头雾水。应该具体说明哪个字段有问题。例如：
{
"code": 400,
"message": "参数校验失败",
"errors": [
{ "field": "phone", "reason": "手机号格式不正确" },
{ "field": "age", "reason": "年龄必须在1~120之间" }
]
}这样前端可以直接把错误对应到表单项上，用户体验也好很多。
利用框架能力自动拦截
像Spring Boot里用@Valid注解，配合@NotBlank、@Pattern这些约束，能省不少事。控制器方法还没执行，校验就先拦住了。
@PostMapping("/user")
public ResponseEntity<?> createUser(@Valid @RequestBody UserForm form) {
// 业务逻辑
}再配一个@ControllerAdvice统一捕获MethodArgumentNotValidException，就能集中返回格式化的错误内容。
自定义校验逻辑别硬编码
有些规则没法靠注解覆盖，比如“用户名不能是黑名单词汇”。这时候写个工具类或者自定义Validator就行，关键是别把校验逻辑散落在各个if-else里。
把校验过程抽出来，单独成方法或服务，测试起来也方便。改规则时不用翻三四个文件。
前端后端都要校验
有人觉得前端校验了，后端就没必要重复做。这是误区。前端校验是为了提升体验，防止用户点提交后才等反馈；后端校验才是真正的安全底线。网络请求可以绕过页面，直接发数据过来。
就像超市安检，入口处提醒你别带液体是善意提示，但真要查包的是里面的安保人员。
日志记录要有分寸
参数错了记日志没问题，但别把用户的敏感信息原样打进去。比如密码校验失败，日志里还打印明文密码，那就出大事了。
记下字段名、错误类型、时间戳足够排查问题，其他信息脱敏处理。
自动化测试覆盖边界情况
写单元测试时，别只测“正常流程通过”。专门写几个测试用例，模拟手机号少一位、邮箱缺@符号、数值为负数的情况。确保每种错误都能被正确拦截并反馈。
这类测试写一次，以后改代码时还能帮你兜底。比上线后被人提bug强得多。