参数校验是后端开发里最容易写、也最容易写坏的一环。多数接口的安全问题不是出在复杂的业务逻辑上，而是出在“以为前端已经校验过了”“以为类型声明能挡住脏数据”“以为框架默认会处理”这些想当然的瞬间。后端参数校验的本质不是礼貌地拒绝错误输入，而是在数据进入业务层之前，把一切不符合契约、可能触发异常、可能被利用的输入挡在核心逻辑之外。校验做得越靠前、越严格、越显式，后续的维护成本和攻击面就越小。
先看一个最常见的错误形态：用类型声明代替运行时校验。很多团队使用 TypeScript、Java、Go 这类带类型的语言，就默认接口收到的数据一定符合声明的结构。实际上，类型系统只在编译期起作用，而 HTTP 请求体、查询参数、路径参数全部来自不可信的外部输入，运行时完全可能传入 null、超长字符串、嵌套对象、错误数字格式。真正的安全校验必须发生在运行时，而且要在反序列化之后、业务处理之前完成。
先定义“合法输入”的边界，再谈校验方式
参数校验不是漫无目的地写一堆 if，而是先明确每个字段的契约：类型、长度、范围、格式、是否必填、是否允许空值、是否允许重复、字符集限制。比如用户名字段，合法边界可能是 3 到 20 个字符，只允许字母、数字和下划线，不能以数字开头，不能包含控制字符。手机号字段则要明确是否接受国际区号、是否允许空格和短横线、长度是否固定。把边界写清楚之后，校验代码就变成了对契约的直接翻译，而不是零散的防御性判断。
一个容易被忽略的细节是：校验顺序会影响性能和安全性。应当先做“廉价”的校验，比如类型判断、空值判断、长度判断，再做“昂贵”的校验，比如正则匹配、数据库唯一性检查、外部服务调用。攻击者可以通过构造大量超长字符串或畸形结构来消耗服务器资源，如果每次都先跑复杂正则或查数据库，很容易被拖垮。先做长度上限检查，再做格式匹配，能显著降低正则回溯和资源消耗的风险。
字符串校验是安全处理的核心战场
后端接收的字符串参数几乎无处不在，而字符串也是注入攻击、存储型 XSS、日志注入、路径穿越的主要载体。对字符串的校验不能只停留在“非空”和“长度合理”，还要考虑字符集白名单。比如一个用户昵称，如果允许任意 Unicode 字符，就可能混入零宽字符、控制字符、双向文本控制符，导致显示混乱或日志伪造。更实际的做法是明确允许的字符范围，例如只允许中文、英文字母、数字、下划线和连字符，其余一律拒绝。
对于可能被拼接到 SQL、命令、文件路径、HTML 输出中的字符串，校验和转义是两件不同的事。校验决定“这个输入能不能用”，转义决定“这个输入怎么安全地用”。不要用转义替代校验，也不要以为做了参数化查询就可以完全忽略校验。参数化查询能防 SQL 注入，但防不了业务逻辑被脏数据破坏。比如一个订单金额字段传入了负数或超大数，即使 SQL 安全，业务上也会出问题。
数字参数的陷阱比想象中多
数字校验最容易犯的错是只判断“是不是数字”，而忽略了范围、精度、类型溢出和特殊值。JavaScript 的 number 类型在 JSON 反序列化时可能丢失大整数精度，比如超过 2^53 的订单号或时间戳，前端传过来就已经不准确了。对于这类场景，后端应当接收字符串形式的数字，再用高精度类型处理，而不是直接映射成浮点数或普通整数。
另外，浮点数比较不能直接用等号，金额字段更不应该用浮点数存储和计算。校验金额时，要明确小数位数上限、最小值、最大值，并且拒绝 NaN、Infinity、科学计数法表示。很多语言的反序列化库会把 “1e3” 解析成 1000，如果业务层期望的是普通十进制格式，这种输入就应当在校验层被拒绝。数字范围校验还要考虑语言本身的整型溢出问题，比如在 Java 里把一个超长数字字符串解析成 int，可能抛出异常或被截断，必须先用字符串长度和范围预检。
数组和对象参数的深度校验
数组参数不能只校验“是数组”，还要限制元素个数、元素类型、是否允许重复、嵌套深度。一个批量创建接口如果允许客户端传入任意长度的数组，攻击者可以一次传入几万条记录，造成内存压力和数据库写入风暴。合理做法是设置硬性的数量上限，比如单次最多 100 条，超过直接返回错误。对于嵌套对象，要限制递归深度，防止构造深层嵌套结构导致反序列化栈溢出或校验逻辑递归过深。
对象参数的校验要逐字段进行，不能只校验顶层字段而忽略嵌套对象。很多框架的校验注解默认只作用于当前层，嵌套对象需要显式标记级联校验。对于动态字段或 Map 类型参数，要限制键的数量、键名的字符集、值的大小，防止攻击者传入大量随机键值对撑爆内存或污染日志。对于可选字段，要明确“字段缺失”和“字段为 null”的区别，有些业务逻辑对这两种情况的处理完全不同。
枚举和布尔参数的严格匹配
枚举参数如果只做“是否在合法值列表里”的判断，通常会忽略大小写、前后空格、数字与字符串的隐式转换。一个状态字段，前端可能传 “active”，也可能传 “Active” 或 “ active ”，甚至传 1 或 true。后端如果做宽松匹配，看似兼容性好，实际上会让契约变得模糊，后续维护时容易产生歧义。更安全的做法是严格匹配，只接受预定义的精确值，其余一律拒绝。布尔参数同理，不要接受 “yes”、“1”、“on” 这类变体，除非业务明确要求兼容多种表示。
时间与日期参数的格式统一
时间参数是跨时区系统里最容易出错的类型。如果接口同时接受时间戳和格式化字符串，校验逻辑就会变得复杂且容易遗漏。建议在接口契约层面统一时间格式，比如只接受 ISO 8601 格式的 UTC 时间字符串，或者只接受毫秒级时间戳。校验时要检查字符串是否能被正确解析、是否包含时区信息、是否在合理的时间范围内。对于时间范围查询，要校验开始时间不晚于结束时间，并且限制查询跨度，防止一次查询拉取过多数据。
文件上传参数的专项校验
文件上传接口的参数校验不能只看文件名和大小。文件类型要同时校验扩展名和 MIME 类型，并且不能信任客户端提供的 Content-Type，因为这两者都可以被伪造。更可靠的方式是读取文件头部的魔数来判断真实类型。文件大小要在接收前就通过 Content-Length 做预检，超过上限直接拒绝，而不是等文件全部写入磁盘后再检查。文件名要过滤路径分隔符和特殊字符，防止路径穿越，存储时最好使用服务端生成的随机文件名，而不是保留原始文件名。对于图片文件，如果业务允许，可以在服务端做二次解码和重编码，消除可能嵌入的恶意代码。
校验失败的错误信息要克制
校验失败时返回的错误信息，应当告诉客户端“哪里错了”，但不要泄露服务端的技术细节。比如不要返回“数据库连接超时”“字段 user_id 违反外键约束”“正则表达式解析失败”这类信息。攻击者可以通过错误信息推断数据库结构、框架版本、内部字段名。更安全的做法是返回统一的错误码和用户可读的提示，比如“参数不合法：用户名长度需在 3 到 20 个字符之间”。对于调试需要，可以把详细错误记录在服务端日志里，但不返回给客户端。
集中式校验与业务校验的分层
参数校验应当分层进行：第一层是格式校验，在控制器或路由层完成，只检查类型、长度、范围、格式等通用规则；第二层是业务校验，在服务层完成，检查数据是否存在、状态是否允许操作、权限是否满足等。不要把业务校验混在格式校验里，比如在参数校验阶段就去查数据库判断用户名是否重复。这样会让校验逻辑变得臃肿，也难以复用。格式校验失败应当快速返回，业务校验失败则需要根据业务规则返回不同的错误码和提示。
一个常见的反模式是：每个接口都手写一套相似的校验代码，导致规则不一致、维护成本高。更好的做法是定义统一的校验规则和错误处理机制，比如使用装饰器、中间件、拦截器或校验器类，把校验逻辑集中管理。对于复杂规则，可以拆分成可复用的校验函数，比如“校验手机号”“校验密码强度”“校验分页参数”，在多个接口中复用。
示例：一个用户注册接口的完整校验思路
假设有一个用户注册接口，接收用户名、密码、邮箱、手机号四个字段。用户名要求 3 到 20 个字符，只允许字母、数字和下划线，不能以数字开头。密码要求 8 到 64 个字符，必须包含大写字母、小写字母和数字。邮箱要求符合基本格式，并且长度不超过 254。手机号要求 11 位数字，以 1 开头。校验代码可以这样组织：
function validateUsername(username) {
if (typeof username !== 'string') return false;
if (username.length < 3 || username.length > 20) return false;
if (!/^[A-Za-z_][A-Za-z0-9_]*$/.test(username)) return false;
return true;
}
function validatePassword(password) {
if (typeof password !== 'string') return false;
if (password.length < 8 || password.length > 64) return false;
if (!/[A-Z]/.test(password)) return false;
if (!/[a-z]/.test(password)) return false;
if (!/[0-9]/.test(password)) return false;
return true;
}
function validateEmail(email) {
if (typeof email !== 'string') return false;
if (email.length > 254) return false;
if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) return false;
return true;
}
function validatePhone(phone) {
if (typeof phone !== 'string') return false;
if (!/^1[0-9]{10}$/.test(phone)) return false;
return true;
}
这些校验函数只做格式检查，不涉及数据库查询。业务层再检查用户名和邮箱是否已被注册。格式校验放在路由层，业务校验放在服务层，职责清晰，也便于单元测试。注意密码校验没有使用过于复杂的正则，而是拆分成多个简单判断，这样可读性更好，也避免了正则回溯的风险。
不要忽略查询参数和路径参数
很多开发者对请求体参数的校验比较重视，但对查询参数和路径参数往往掉以轻心。查询参数同样来自外部输入，同样可以被篡改。分页参数 page 和 pageSize 必须校验为正整数，并且设置上限，比如 pageSize 最大 100。排序字段要做白名单校验，不能直接拼接用户传入的字段名到 SQL 的 ORDER BY 子句。路径参数中的 ID 要校验格式，比如必须是数字或 UUID，防止路径穿越或类型转换异常。
安全校验的最终目标是让非法数据无处可去
参数校验不是一次性工作，而是随着接口演进需要持续维护的契约。每新增一个字段、每修改一个业务规则，都要同步更新校验逻辑。把校验规则写在接口文档里，让前端、测试、后端对“合法输入”的理解保持一致。对于关键接口，可以增加自动化测试覆盖各种非法输入场景，包括空值、超长字符串、特殊字符、越界数字、错误类型、嵌套对象等。只有把校验当成安全体系的一部分来对待，而不是当成可有可无的防御代码，后端接口才能在面对恶意输入和意外数据时保持稳定。
