场景

注册表单在浏览器提示格式正确，并不能阻止攻击者直接调用 API；服务端只做格式校验，也无法给普通用户及时友好的反馈。

原理

前端校验关注交互体验，服务端校验承担安全与数据完整性。字段约束检查长度、格式和范围，业务约束检查唯一性、状态和关联关系，权限校验确认当前主体能否操作目标资源。三者失败语义不同。

设计步骤

为 DTO 声明基础约束并在入口触发；跨字段规则使用对象级校验；涉及数据库状态的规则在事务内再次判断；权限检查基于服务端查出的资源而非客户端传入归属；错误响应返回稳定代码和字段路径。

权衡

重复校验增加维护成本，却是跨信任边界必要冗余。注解适合静态规则，复杂业务若塞进自定义校验器会隐藏数据库访问和事务。过严过滤可能拒绝合法输入，过松则把风险推给后续层。

实践建议

采用白名单和长度上限，规范化后再验证，防止 Unicode 或编码绕过。校验失败不回显敏感内部信息。唯一性仍需数据库约束兜底，不能只靠“先查询”。把恶意输入、并发提交和对象越权加入自动化测试。

落地检查

上线前还应做一次桌面演练：准备正常、边界、超时、重复与恶意输入，确认系统的返回、日志和指标彼此对应；在预发布环境模拟依赖不可用、进程重启和配置回滚，验证降级路径不会放大故障。上线时采用小流量观察，提前定义停止条件与负责人。稳定后复盘真实数据，删除没有收益的复杂度，并把新发现的约束补进测试、监控和设计记录，使方案能够随业务持续演进，而不是停留在一次性评审结论。