那天晚上十一点多支付系统的告警把我从沙发上拉起来。翻日志的时候我在请求参数里看到一串扎眼的数字9999999999。十个9连成一排第一反应是哪个用户手滑按错了键但等我把整条链路追完才发现这串数字从用户输入表单到数据库报错每一层都留下了不一样的“症状”。这一趟排查下来我对“边界值”这三个字有了全新的敬畏。这篇就好好聊聊这串 9999999999 带来的连锁故障它到底是怎么穿透前端校验的、为什么后端一接收就崩、数据库里又是怎么被拦下来的以及我们后来在开发规范和测试用例上做了哪些调整。适合后端开发、前端开发、测试工程师以及所有跟接口参数、数据校验打过照面的人看。就算你不做支付业务“输入了超长数字导致系统崩溃”这件事本身也值得记上一笔。1. 现场还原十个 9 是怎么把链路打崩的1.1 日志取证从入参异常一路追到数据库报错当时告警的内容是订单创建接口大量 500错误码集中在两个方面一个是参数反序列化异常另一个是数据库字段值超出范围。把请求日志捞出来比对所有报错请求里都出现了同一个入参userId9999999999。我先说结论这个 userId 根本不是用户体系里的真实 ID而是用户在“绑定手机号”的收银表单里填的号码。因为下单页要校验手机号用户随手输入了十位数字而当时的表单校验规则只有一个——“必须是纯数字且长度不小于 8”。9999999999 满足这两个条件于是顺利进入后端。后端拿到参数后在服务层做了一次转类型处理把这个手机号当成长整型字段透传给内部的订单计费服务。问题来了计费服务里对应的字段是 int 类型。Java 的 int 最大值是 2147483647而 9999999999 大约是 100 亿直接超出 int 的范围一个数量级。反序列化的时候框架按 int 去解析这串数字直接就抛了类型转换异常。更隐蔽的问题在数据库。即便反序列化没有立刻报错落库的时候如果字段是 int(11)MySQL 也会直接拒绝写入一条超范围的值报 Out of range value for column。所以这一条请求在应用层和数据库层几乎同时触发了两种不同类型的错误这也是为什么排查时日志看起来特别乱——你先看到的是反序列化异常再往深处挖才发现数据库也在报同样的源头。1.2 第一直觉不靠谱它既不是电话号也不是攻击很多人看到十个 9 的第一反应是这不是标准的手机号但也不像攻击流量。我当时的排查路径也走偏了先查了风控、IP 频控、用户资损排除了批量刷单和漏洞扫描最后才发现源头这么朴素——不过是用户在输入框里多按了几下 9。这也给我提了个醒遇到异常参数不要急着往“恶意攻击”上靠。很多时候它就是普通用户在边界场景下的误操作。真正的问题不是这个用户手误而是我们的校验规则和字段设计没有给这种“合法格式里的非法值”留好后路。1.3 整条链路上的三段式故障复盘时我把这次故障拆成了三段前端校验层只校验了“纯数字 长度大于等于 8”十位数字的 9999999999 轻松通过真正的手机号规则没有被强制执行。后端应用层把手机号字段定义成了 int 类型而十位数字已经超过 int32 上限参数反序列化直接失败。数据库层如果应用层侥幸放行int(11) 字段也无法写入 9999999999最终还是会报错。这三段不是孤立的而是层层递进。任何一层做好了后面的故障都不会发生。这也是我后面要说的核心观点边界值问题必须全链路治理单靠某一层补漏洞永远追不上另一层的疏忽。2. 边界值为什么会成为系统里的“定时炸弹”2.1 整数上限int32 到底能装多少先看一张常见的数值类型容量表类型字节数最小值最大值int16 / short2-3276832767int32 / int4-21474836482147483647int64 / bigint / long8-92233720368547758089223372036854775807uint32404294967295uint6480184467440737095516159999999999 是 100 亿放在 int32 里明显不够用放到 uint32 里其实也悬uint32 最大 42.9 亿得放到 int64 才安全。所以当你看到一串十位以上的纯数字时第一件事就要想这个字段可能来自 long 或者 bigint绝对不能用 int 去接。还有一个特别容易误解的地方MySQL 的 int(11) 里的 11 不是“最多存 11 位数字”而是显示宽度。int 类型不管括号里写几存储上限都一样都是 2147483647。很多人建表时写了 int(20)以为够存很长的数结果一个大数直接溢出这就是只学了样子没理解原理。同样的道理也适用于 Java 里的 Integer——它不会因为你给它赋值时多写几个 9 就自动扩容它会直接给你抛一个 NumberFormatException 或者静默溢出成一个负数。2.2 JavaScript 的精度陷阱为什么前端“看着没事”如果这个请求是从浏览器发出来的那么前端 JavaScript 本身也有一个隐藏的坑Number 类型的安全整数范围由 IEEE 754 双精度浮点数决定最大安全整数是 Number.MAX_SAFE_INTEGER等于 9007199254740991也就是 16 位。9999999999 只有 10 位在 JS 里其实是安全的没毛病。但如果你把 9 继续往上加到 17 位以上比如 99999999999999999JS 的 Number 就会开始丢精度出现“看起来是个整数实际上已经被四舍五入成另一个数”的情况。我直接用代码给你演示一下console.log(Number.MAX_SAFE_INTEGER 1); // 9007199254740992 console.log(9007199254740993); // 9007199254740992第二行你原本想表示的是 9007199254740993但打印出来变成了 9007199254740992这就是精度丢失。这个问题最常见的表现是前端用雪花算法生成一个用户 ID 或者订单号传给后端后端发现这单对不上号最后定位出来是 JS 在解析时已经把数字改了。所以前端的校验规则不仅要判断“是不是数字”还要判断“这个数字在目标语言里能不能精确表示”。尤其是涉及 ID、金额、手机号、银行卡号这类业务标识时更推荐的做法是后端用字符串接收、数据库用 varchar 存储而不是在中间任何一环转成有精度限制的数值类型。2.3 字符串还是数字业务标识的选型原则这里其实是一个老生常谈的决策问题手机号、用户 ID、订单号到底该用数字类型还是字符串类型我的建议分成两种情况如果这个数只用来展示、透传、参加字符串拼接不参与任何数学运算那就应该用字符串。典型例子就是手机号和银行卡号。本质上一个“号码”并不等于一个“数值”它不需要做加减乘除也不需要做大小比较。如果这个数真的要做自增、排序、加减、范围查询那才是数字类型的合理使用场景。比如数据库自增主键、金额字段不过金额一般也不建议直接用浮点数。很多人栽跟头就栽在“看着像数字就按数字处理”。而现实是业务开发里大量字段都只是“长得像数字的字符串”。十个 9 这种值本质上就是一个长度稍长的字符串你要拿数字类型的容器去接它迟早出问题。3. 全链路加固从前端校验到数据库字段设计3.1 前端表单校验别只判断“是不是数字”先说前端那层。绑定手机号的表单校验规则从“纯数字 length8”改成了这样必须匹配手机号正则^1[3-9]\d{9}$输入框 maxLength 限制为 11 位针对用户粘贴的场景去掉首尾空格后再校验这里有细节要说maxLength 限制 11 位是为了防手滑连按但也不能只依赖它因为有些浏览器对 paste 进去的超长字符串和移动端的自动填充并不总会触发 maxLength 拦截。所以正则校验必须写在 change 事件和提交前的校验器里双保险。对应的前端代码大概长这样const MOBILE_REG /^1[3-9]\d{9}$/; function validateMobile(input) { const value input.value.trim(); if (!MOBILE_REG.test(value)) { return 请输入正确的手机号; } return ; }另外如果这个字段还会被别的服务使用前端只能做体验层拦截后端必须再做一次完整校验。前端可以被绕过后端的校验才是安全底线。3.2 后端接口参数类型收窄与统一校验后端这边我改动了两处。第一处是 DTO 里的字段类型。把原本的 Integer 类型改成 Long但随即想了想手机号这种字段其实用 String 更合适因为后面还可能要支持区号、分机号等格式。最终我们把手机号、银行卡号这类“号码型”字段统一改成了 String配合注解做格式校验。类似这样public class BindMobileRequest { NotBlank(message 手机号不能为空) Pattern(regexp ^1[3-9]\\d{9}$, message 手机号格式不正确) private String mobile; // getter/setter }第二处是在全局参数校验里加了一条规则凡是接收数值型 ID 参数的接口如果参数值超过 Long.MAX_VALUE直接拒绝请求并返回参数错误。这样哪怕上游犯了错下游也不会被超长数字炸穿。这里想多说一句校验要分层。前端管体验网关管安全后端管业务正确性各层解决各层的问题但每一层都不能把责任完全推给下一层。以前端校验为例你永远不知道用户会从哪个入口绕过浏览器直接把十个 9 打到后端接口上。3.3 数据库字段设计类型选对才能兜底数据库层面我们把跟手机号、账号相关的字段全部从 int 改成了 varchar长度按业务峰值留了余地比如手机号用 varchar(20)。对于真正的自增 ID、业务单号这类需要数值比较的字段则统一用 bigint并且在建表时确认一下 bigint 和无符号类型能不能满足未来十年的增长。改完之后的表结构大概长这样CREATE TABLE user_bind_log ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, mobile VARCHAR(20) NOT NULL, account_no VARCHAR(64) NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP );这里有一个很容易被人忽略的原则varchar 字段在 MySQL 里存手机号、账号这类值查询时如果走索引要注意字符集和排序规则的一致性避免隐式类型转换导致索引失效。比如 varchar 字段和数字类型的查询条件做关联MySQL 很大概率会把字符串转成数字去比较结果就是全表扫描。所以校验里还是要保证入参类型、字段类型和查询条件的类型三者一致。还有一个经验上线前最好做个“字段类型与最大边界对照表”把每个表的每个数值字段的最大预计值算一遍再对照类型上限超过一半容量的就要考虑升级类型。这种表看着简单真到出故障的时候比什么都管用。4. 极限值测试的正确打开方式4.1 边界值测试用例别只测“正常值”这次事故之后我让团队把接口测试用例里补了一组“边界值套餐”覆盖数字类型最小值、最大值、最大值1、最小值-1、0、负数、超长字符串长度校验目标长度-1、目标长度、目标长度1手机号校验1 开头 11 位、非 1 开头的 11 位、10 位纯数字、空字符串、带空格这个“最大值1”特别关键。很多接口只测了正常值和异常格式恰好漏掉了“格式正确但数值超限”这个区间。9999999999 就是这种值的典型代表——它合法地被解析成一个十位数字串但根本存不进 int 字段。如果你们用的是 Python 做接口测试边界值用例可以直接参数化比如import re MOBILE_PATTERN re.compile(r^1[3-9]\d{9}$) def validate_mobile(mobile: str) - bool: return bool(MOBILE_PATTERN.match(mobile.strip())) # 边界值用例 cases [ 13800138000, # 正常 9999999999, # 10位纯数字 1380013800, # 10位 138001380001, # 12位 23800138000, # 2开头 1380013800a, # 含字母 , # 空 ] for case in cases: print(case, validate_mobile(case))这种测试的价值在于它会逼着开发把“合法格式的具体约束”写清楚而不是写一个宽泛的“纯数字”规则就完事。4.2 用 9999999999 做容量和压测数据除了功能测试9999999999 这种超长数字在容量场景也很有用。比如我常用来测试文件系统的写入上限dd if/dev/zero of/tmp/testfile bs1M count9999999999这条命令会尝试写入一个接近无限大的文件用来验证磁盘配额、inode 耗尽时应用的行为。同理构造千万级别的 int 循环来压测接口幂等、超时、熔断策略也可以用类似思路。注意压测时如果不加限制这种命令真的会瞬间打满磁盘或者内存建议在容器或者专门的一次性虚拟机里做测完直接销毁。我当时是在一个一次性 Docker 容器里跑的跑完直接删容器省得清理。4.3 一套可复用的防线组合简单总结下我现在倾向于采用的组合接口文档里明确字段类型、取值范围、长度上限前后端按文档对齐。前端和后端各做一次参数校验规则保持一致不接受“前端已经挡过了”的说法。数据库字段类型按业务增长预留容量数值型超过类型上限一半就换更大的类型。测试用例固定包含边界值套餐把它当上线前置条件。核心接口加监控告警一旦出现“超长数字入参”一类的异常先通知再排查。这套东西不复杂但成本极低收益却很大。至少下一次再出现十位甚至二十位数字系统能优雅地拒绝而不是半夜把你叫起来。5. 问题排查速查表现象可能原因排查方法解决方案参数反序列化报 NumberFormatExceptionint 类型接收了超 int32 上限的值查入参类型对比 int/long 上限改成 Long/String加校验数据库报 Out of range value写入值超出字段类型范围查看表结构、字段类型与实际值升级 bigint 或改 varcharJS 里传来传去数字变了超过 Number.MAX_SAFE_INTEGERconsole.log 打印对比前后端值字符串传递大整数或用 BigInt手机号校验形同虚设规则只判断纯数字和长度检查正则跑边界用例用^1[3-9]\d{9}$等规范正则看起来是数字但业务不该当数字字段选型错误确认字段是否参与数学运算号码类字段统一 String这个表格是浓缩版真实的排查过程一定比我写的要乱但只要记住一点边界值不是“偶尔出现的小概率事件”它是系统设计的常量测试。十个 9 拦住了二十个 9、一百个 9 还在等着呢。最后说点个人体会。那次排障之后我养成了一个习惯每写一个接收参数的接口先问自己三个问题——这个参数最大可能是什么值它会被拿去做什么运算如果数据库里存不下会发生什么这三个问题想清楚了至少一半以上的边界问题都能在设计阶段被消灭。至于剩下的交给监控和告警。做技术的不是每件事都要等到出事故才长记性的。