订单列表正常打开，详情按钮也能点击。直到把请求里的订单号和数据库里的值并排放在一起，才发现最后几位对不上。
这类问题很容易被查成“点错行”“缓存没更新”或者“AI把编号抄错了”。但有时，模型和业务逻辑还没开始处理，编号就已经在JSON解析时变了。
先做一个可以直接运行的小实验。这里用的是教学编号，不对应真实订单：
const a = JSON.parse('{"order_id":1234567890123456789}');
const b = JSON.parse('{"order_id":1234567890123456790}');
console.log(a.order_id === b.order_id); // true
两笔不同的订单，解析后却成了同一个数。
如果测试只检查状态码、字段存在和类型是number，这个错误可以一路绿灯。
第一处变形，可能就发生在收包之后
JavaScript的Number不能精确区分所有大整数。安全整数上限是9007199254740991，也就是2的53次方减1。超过这个范围，有些整数仍能表示，有些相邻整数却会落到同一个可表示值上。
因此，“数据库用BIGINT存得下”和“浏览器Number能原样接住”，是两个需要分别验证的条件。
排查时先留下四份证据：数据库或源系统里的原值、响应原始文本、解析后的值、后续请求实际发出的值。浏览器开发者工具里格式化后的对象展示，未必能替代原始响应文本。
如果原始响应还正确，解析后的值已经变化，先查类型契约。若原始响应也错了，就继续向网关、序列化器和源服务追查。
这里最容易让修复跑偏的一句话是：“那我收到以后再转字符串。”
转成字符串，能救回已经丢掉的数字吗
不能。转换发生得太晚，只会得到错误数值的字符串版本。
const original = "1234567890123456789";
const damaged = JSON.parse('{"order_id":1234567890123456789}');
console.assert(String(damaged.order_id) !== original);
const intact = JSON.parse('{"order_id":"1234567890123456789"}');
console.assert(intact.order_id === original);
console.assert(typeof intact.order_id === "string");
对订单号、工单号、设备号这类标识，一种容易保持一致的契约是：在跨语言接口中使用字符串，全程按不透明标识处理。它们通常不需要参与加减乘除。
别只改响应端。还要检查前端组件有没有偷偷调用Number或parseInt，URL参数是否再次转型，日志SDK是否把长数字识别为数值，工具参数Schema是否仍定义成整数。
BigInt可以处理大整数，但它也需要明确的序列化约定。不能把“改成BigInt”理解成所有JSON客户端都自动兼容。若字段只是业务标识，保留字符串通常更直观；若确实需要计算，应另行设计精确数值类型和传输方式。
一条端到端断言，比十个类型检查更有用
接口契约可以写得很明确：
{
"type": "object",
"required": ["order_id"],
"properties": {
"order_id": {
"type": "string",
"pattern": "^[0-9]{1,32}$"
}
}
}
这个长度范围只是示例，应按真实业务设置。是否允许前导零、是否区分大小写，也必须由标识规则决定。不要因为“看起来都是数字”，就顺手去掉前导零。
随后验证完整往返：源标识进入响应，前端选中该对象，再提交到详情、编辑或AI工具调用，最终标识与源值逐字符相同。
| 样本 | 为什么要放进测试集 |
|---|---|
| 安全整数边界附近 | 找出从精确到不精确的变化 |
| 两个仅末位不同的19位编号 | 发现错误合并、错误选中 |
| 带前导零的合法编号 | 发现偷偷数值化的组件 |
| 同一编号多次往返 | 发现某一段再次转换类型 |
| 字符串形式的非法编号 | 确认边界校验没有因改类型而消失 |
测试还应同时检查“没有碰到另一笔订单”。只断言目标请求返回成功，有可能把错误对象上的成功当成通过。
AI工具链里，这个问题会再走一遍
让AI助手按工单号查询详情时，编号可能经过模型结构化输出、MCP或其他工具协议、应用校验、数据库查询，再回到页面。某一段把字符串改成浮点数，就会破坏前面所有环节保存的精度。
可以给工具调用测试增加一组相邻长编号。让模型选择其中一个，运行时校验实际参数必须来自授权候选集合，并检查调用结果的标识完全一致。用户身份与对象权限仍由服务端校验，不能靠“编号没变”替代权限检查。
让AI补测试时，也应该给出这类反例，而不只是说“覆盖边界情况”。边界要具体到字段和表示方式，才会变成可执行的验证。
下次看到一个很长的业务ID，先别问它能不能转成数字。先问：从系统A走到系统B，再走回来，它还会不会是原来的那个对象？
