Java学习随笔：参数校验为什么要分清格式和业务状态（2026-10-26）

写 Java 接口时，参数校验往往是最早补上的一段逻辑：判断必填项是否存在，检查字符串长度，再确认数字有没有超出范围。做完这些，很容易觉得请求已经被检查过，后续只需执行操作。但在订单、库存等会持续变化的场景里，输入格式正确，和操作此刻确实可以执行，是两件需要分别判断的事情。今天想整理的，就是这两类校验的边界。

先设想一个取消订单的请求。调用方传入订单标识，服务检查它不是空值，格式也符合约定。这些检查只能说明请求具备继续处理的基本条件，不能证明订单存在，更不能证明订单属于当前用户，或者仍然处于允许取消的状态。如果把所有检查都概括为“参数合法”，就容易忽略其中不同的依据，也容易把权限错误、状态冲突和输入错误混在一起。

格式和范围校验通常只依赖这次提交的内容。例如备注不能超过约定长度，购买数量必须为正，时间区间的开始不能晚于结束。这些检查适合尽早完成，让明显无效的请求不必继续占用数据库连接或下游调用资源。不过“尽早”并不等于只在页面上检查。客户端可以提供即时反馈，服务端仍然需要维护自己的边界，因为请求可能来自其他客户端，也可能经过不同的调用路径。

有些输入还需要先明确如何解释，再决定如何校验。字符串前后的空格是否保留，空字符串与未提供字段是否等价，数量的单位是什么，都应该成为接口约定。随意去掉空格看似方便，但对于密码或某些标识字段，可能改变原意。同样，一个字段在创建操作中必填，在局部更新时可能表示不修改。若没有区分这些语义，同一套校验规则就可能把本来有效的请求挡住，或者把未提供误当成清空。

业务状态校验则需要结合系统中已经存在的信息。订单是否可取消、库存是否足够、某个名称是否已被使用，都不是单凭请求内容就能回答的。相应规则应该由负责该业务的代码表达清楚，避免散落在不同入口里各写一份。同一个业务操作可能被网页接口、定时任务和内部调用共同使用，如果只有其中一个入口检查状态，其他路径就可能绕过本来必须遵守的约束。

更容易被忽略的是，读到的状态只代表某个时刻。服务查询订单时，它可能尚未发货；查询结束到执行取消之间，另一个请求却可能已经改变了状态。先检查再更新并不能自动保证检查结论在更新时仍然成立。对于这种竞争，需要让实际写入也受业务条件约束，例如只允许从约定的旧状态转换到新状态，再根据实际更新结果判断是否成功。具体采用事务、条件更新或版本控制，要结合数据存储和操作范围设计。

唯一性约束也是类似的道理。为了给出友好的提示，可以先查询某个名称是否存在，但并发请求可能同时得到不存在的结果。真正不能重复的数据，还需要在可信的存储边界维护约束，并处理竞争失败的结果。前面的查询能改善体验，却不能代替最终约束。理解这一点以后，就不会再把“代码里已经判断过”当作并发安全的证明。

校验失败的表达也值得认真设计。缺少必要字段，可以告诉调用方补充什么；资源已经进入不允许修改的状态，则应说明本次操作无法继续，而不是让调用方反复修改格式。权限相关的失败还要考虑信息暴露，不能为了提示详细而泄漏不该被知道的资源状态。对外的错误信息应当清楚且稳定，对内则保留足够的关联线索，便于定位是哪条规则阻止了操作。

当然，也不是每一层都需要把同样的检查复制一遍。入口负责解释外部输入，业务逻辑负责维护自己的前置条件和状态变化，存储边界负责兑现它能够保证的约束。各层可以提供不同的保护，但要知道每一项检查为什么存在。如果所有地方都使用一个没有具体含义的“检查失败”，代码虽然看起来防守严密，修改规则时仍然容易漏掉某条路径。

学习时可以围绕一个取消订单的小例子，分别列出缺少标识、订单不存在、无权操作、状态已经变化和两个请求同时执行的情况，再逐一判断应该由哪里发现问题、如何返回结果。这样整理以后，参数校验就不只是几句条件判断，而是对接口语义和业务边界的说明。格式校验帮助请求被正确理解，业务约束保证操作在真实状态下仍然成立，两者衔接清楚，服务的行为才更容易解释。