写死的示例数据混进了真实路径，上线才发现该怎么排查

2026-07-29

内容截至 2026-07。文中命令与配置写法可能随工具版本变化，以各自官方最新说明为准。

**生产环境冒出一条叫「张三」的用户、一笔金额恒为 0 的订单、一个永远返回成功的支付回执，多数人的第一反应是「数据库被污染了」，于是一头扎进 SQL 里查来源——这是最常见的归错因。这类问题里，真正的根因绝大多数不在数据层，而在代码路径：某段返回写死数据的分支一直都在，它不是今天才被写进去的，只是今天才第一次被走到。**你要找的不是「谁插入了这条数据」，而是「哪条代码路径在什么条件下绕过了真实数据源」。搞反这个顺序，你会在数据库审计日志里耗掉一整个晚上，然后发现那条记录根本没落库，是接口在内存里现编的。

这篇讲的是排查顺序和隔离手段。站内另外两篇和它分工不同：测试全绿但上线就崩讲的是测试用例本身失去了鉴别力（断言写松了、Mock 把被测逻辑一起替换掉了），是「测试为什么没拦住」；AI 写的代码能上生产吗讲的是上线前的整体准入判断，是「要不要放行」。本篇只管一件事：假数据已经出现在真实路径上了，你怎么按顺序定位它、拔掉它、并保证下次不再进来。

一、先把「假数据」拆成三类，它们的指纹完全不同

不分类就动手，是这类故障排查时间失控的主因。三类假数据的注入点、生命周期、清除方式都不一样，混在一起查等于同时在三个方向乱撞。

**第一类是 mock 与 fallback 常量。**它活在代码里，本身不写库（除非被下游写入路径带进去，这种例外后面单说）。典型形态是某个函数在拿不到真实响应时返回一份写死的结构，或者某个开发期的桩实现被注册进了依赖容器。AI 编程工具在这类东西的产出上格外积极：你让它写一个接口调用，它往往顺手加上异常兜底，兜底里塞一份结构完整、字段齐全、看起来很专业的示例返回。这份返回在联调期救过你的命，上线后它就成了一颗定时炸弹——真实接口一旦超时或返回 5xx，用户看到的不是错误提示，而是一份编造的数据，而且看不出任何异常。

**第二类是种子数据。**它进数据库，通过迁移脚本、初始化脚本或者管理命令写入。危险点在于种子脚本和结构迁移经常被放在同一个执行入口里，本地和预发跑得好好的，生产跑一次就把演示用户、演示商品、演示配置全部灌进去了。这类假数据是真实存在于表里的，SQL 能查到，反而容易被误判成「数据被人手工改过」。

**第三类是演示分支与演示构建产物。**它的注入点在交付链路上：某个为了给客户演示而临时改造的分支被合了回来，或者 CI 把 demo 环境的构建产物推到了生产。这类最隐蔽，因为代码仓库主干上可能干干净净，问题出在实际跑起来的那份产物里。

判别的第一步不是读代码，是确认这条假数据到底落没落库。拿到一个可疑值，直接在数据库里精确查一次：

SELECT id, created_at FROM users WHERE name = '张三' LIMIT 10;

查不到，基本可以断定是第一类，这条数据是渲染层或接口层现编出来的，压根没经过存储。查得到则先指向第二、三类，但别就此收工：还有一种情况是第一类的假数据被下游写进了库——某个兜底常量流进了后续的写入路径，于是它既在代码里也在表里。区分办法是看这些行的创建时间分布：种子脚本写入的行时间高度集中在某次发布前后，而兜底常量被写入的行会零散分布在用户实际操作的时间点上。这一步只要一分钟，却能把后面的排查范围砍掉大半。

二、判别表：从现象倒推成因

现象	大概率成因	怎么验证	处置动作
生产出现明显编造的姓名、手机号、邮箱	代码内的 fallback 常量或 mock 实现被走到	取该字符串全仓精确检索；同时在数据库精确查该值	定位分支后改为抛错或返回明确的空态，禁止静默兜底
只在某个环境出现，别的环境正常	环境变量缺失导致启动时降级到默认桩实现	打印进程实际读到的关键变量清单，与预期比对	启动时校验必需变量，缺失直接退出而不是降级
接口结构正确但数值恒定不变	请求层被拦截器或适配器换成了假实现	在网络层抓一次真实出站请求，看有没有真的发出去	把假实现移出生产依赖树，只在测试作用域注册
部分用户或部分时段才出现	特性开关灰度分支里挂着演示实现	按开关维度分组统计出现率，看是否与开关命中一致	关掉开关止血，再清理分支内的演示代码
数据库里确实查得到这些行	种子脚本在生产执行了	查这些行的创建时间，与发布时间对齐	隔离种子脚本执行入口，按主键定点清除
前端展示假数据，接口返回正常	前端占位数据或骨架屏兜底没摘干净	对比接口原始响应与页面渲染值	占位数据统一收敛到一处，用明显不可能的值
上线后第一个请求就是假的	演示分支被误合并，或构建产物来源错了	先核对运行产物的提交号与主干是否一致：不一致说明产物来源错了；一致则说明假实现已经进了主干，改为比对上一个正常版本到当前版本的差异	立即回滚到上一个已知正确的产物

用这张表的方式是：先拿一个具体的假值当作唯一线索，沿着「落库与否 → 环境相关与否 → 用户相关与否」三个二分问题走，两三步就能定位到具体那一类。别一上来就通读代码。

三、动作：三道闸门，按成本从低到高上

定位完之后要做的不只是删掉那一段。删掉只解决这一次，闸门才解决下一次。

**第一道是检索闸门，最便宜，现在就能加。**把所有演示值收敛成一个固定的、绝不可能出现在真实业务里的前缀，比如统一用 DEMO_ONLY_ 开头。约定之后，一条命令就能扫全仓：

git grep -n "DEMO_ONLY_" -- ':!*test*' ':!*spec*'

排除测试目录之后还有命中，就是漏网的。把这条命令挂进提交前检查或者 CI 的一个独立步骤，命中即失败。这里的关键不是命令本身，是先有命名约定——没有约定，你永远不知道该搜什么。很多团队搜的是「张三」「test」「foo」，这些词在正常业务文案里也会出现，噪音大到没人愿意看。

**第二道是依赖闸门，防的是假实现被打包进生产产物。**桩实现、假客户端、内存版仓储，这些东西应该只存在于测试作用域的依赖里，不进生产依赖树。做到这一点之后，就算有人误写了对假实现的引用，也会在编译或依赖安装阶段暴露出来，而不是运行期悄悄生效。具体在哪一步暴露取决于语言：静态编译型语言会在编译期直接失败，而动态语言里作用域隔离不一定拦得住，需要额外在打包阶段做一次依赖清单核对，确认生产产物里没有测试专用的包。构建产物层面还可以再加一层：在打包结果里搜一次演示前缀，命中就阻断发布。这一层比源码检索更可信，因为它看的是真正要跑的那份东西。

**第三道是启动闸门，防的是环境变量缺失导致的降级。**这是最容易被忽略、后果又最重的一类。代码写的是「读不到配置就用默认值」，默认值是本地开发用的假地址，于是生产因为一个变量名拼错就整体走进了模拟模式，而且不报任何错。正确做法是启动时集中校验：生产模式下所有必需变量必须存在且非空，缺一个就打印缺失清单并退出。宁可起不来，也不要带着假数据跑起来。

这里有个前置问题要先排掉：变量到底是没配，还是配了但进程压根没读到。两者的处置完全不同，前者补配置，后者要查启动方式和继承链——同一台机器上，从终端启动和从图标、服务管理器、容器编排启动，进程拿到的环境集合可能完全不是一回事。这类「终端里跑得好好的、换个启动方式就读不到」的判型和分平台验证命令，GUI 进程读不到环境变量的排查里写得更细。另一种邻近场景是变量读到了但指错了地方——测试配置指到生产库那种，判别与切分办法见多环境配置串环境的排查。

顺带说一句 AI 工具在这三道闸门上的位置：它擅长的是第一道——给它一段代码，让它标出所有硬编码的示例值，它找得比人快也比人全。第二、三道属于工程结构决策，需要你自己拍板哪些依赖能进生产、哪些变量算必需，交给工具自动改反而容易把范围扩大到失控。关于怎么把 AI 的改动范围框住，AI 改动范围失控怎么办有更完整的做法。

四、什么情况下别再折腾了

排查这类问题有个很强的心理陷阱：因为每一步都在往前推进，你会觉得再看五分钟就能找到，于是一直看下去。设几个明确的止损点，比靠意志力好使。

**止损点一：假数据涉及金额、权限、身份中的任意一项，立即回滚，不要边查边修。**用户看到一个假名字是体验问题，看到一笔假的成功回执是资金问题，看到不属于自己的数据是安全事故。这三类的止血优先级高于定位根因。回滚到上一个已知正确的版本，让线上先干净，再在预发慢慢查。

**止损点二：三十分钟内定位不到注入点，切换到二分法。**别再读代码了。用发布记录做二分：找到最近一个确认没有该现象的版本，和当前版本之间的提交做折半验证。这个动作看着笨，但耗时可预测，而通读代码的耗时不可预测。

**止损点三：清理成本超过重建成本时，换条路。**如果种子数据已经和真实业务数据产生了外键关联，被引用、被统计、被下游同步走了，那么「精确删除演示行」这条路会越走越长，每删一行都要处理一串依赖。这时候更划算的是保留这些行、给它们打上标记、在查询层统一过滤掉，把「删除」问题转成「标记与排除」问题。

**止损点四：同一个位置修了两次又复发，说明你修的是症状。**第二次复发就应该停下来问：这段假数据是从哪个环节反复被带进来的？是某个模板、某个脚手架、某个团队约定的代码片段？改源头，别改副本。

还有一个反向的止损：如果查到最后发现那份数据是真的、只是长得像假的（有些测试账号会一直存在于生产），那就到此为止，把它加进已知白名单，别再顺着往下挖。

五、避坑清单

**坑一：用 try/catch 包住整个数据获取，catch 里返回示例数据。**为什么会踩——联调阶段后端没就绪，前端为了页面能跑先这么写，写完就忘了；AI 补全也倾向于给出「结构完整」的兜底以让代码看起来更健壮。怎么避——定一条硬规则：兜底只能返回空态或者抛出，绝不能返回带业务字段的具体值。空态难看，但它诚实。

**坑二：种子脚本和结构迁移共用一个执行命令。**为什么会踩——本地开发希望一条命令把库建好、数据填好，方便；这个方便一路带到了部署脚本里。怎么避——拆成两个入口，种子入口在生产模式下直接拒绝执行，判断依据用环境标识而不是数据库地址（地址会被改，标识不会）。

**坑三：演示分支从主干拉出去，改完再合回来。**为什么会踩——演示时间紧，改的都是「临时的」，合回来时评审注意力全在功能上，没人逐行看那些临时值。怎么避——演示改动只允许单向：从主干拉，永不合回；演示要保留的能力重新在主干上实现一遍。听起来浪费，实际比事后排查便宜得多。

**坑四：假数据长得太真。**为什么会踩——为了演示效果好看，示例数据会刻意做得逼真：真实感的姓名、合理的金额、连贯的时间序列。逼真意味着不可检索、不可肉眼识别。怎么避——演示值统一带可检索前缀，金额之类的数值用明显异常但不至于崩溃的值，让它一出现就刺眼。

**坑五：把「有测试覆盖」当成有防护。**为什么会踩——那段兜底逻辑往往有测试，而且测试是绿的，因为测试断言的正是「异常时返回这份示例数据」。测试在保护 bug。怎么避——把这类断言反过来写：异常时应当抛出或返回空，如果有人改回返回示例数据，测试就该红。这类测试自身失去鉴别力的情况，测试全绿但上线就崩里有更系统的判断方法。

**坑六：只在代码里搜，不在产物里搜。**为什么会踩——默认「跑的就是我看的这份代码」，而构建缓存、旧产物、错误的分支来源都会打破这个假设。怎么避——发布流程里加一步产物侧检索，并把运行中服务的提交号暴露成一个可查询的接口，出事时第一时间确认跑的到底是哪份代码。

**坑七：清理时直接 DELETE，不留痕。**为什么会踩——现场压力大，想快点让线上干净。怎么避——先把待删行导出留档再删，删除按主键逐条执行并限制影响行数。一旦发现误删，你还有回头路。涉及生产数据的动手操作，配合 AI 代码安全审计怎么做里的审查思路会稳一些。

六、收束

这类故障的性质，说到底是「开发期的便利」没有在交付边界上被拦住。mock 让你在后端没就绪时能往前走，种子数据让新人一条命令就有可用环境，演示分支让销售能带着东西去见客户——它们本身都没错，错的是它们和生产之间没有一道明确的门。门可以很简陋，一条 grep、一个启动校验、一条分支单向规则，加起来不到半天工作量，但能把这类事故的概率压到很低。

出事时按这个顺序自检：

这条假数据落库了吗？查得到走数据侧，查不到走代码侧。
它是全环境还是单环境？单环境优先怀疑配置缺失导致的降级。
它是全量用户还是部分用户？部分用户优先怀疑开关灰度分支。
当前跑的产物提交号，和主干一致吗？
涉及金额、权限、身份吗？涉及就先回滚再查。
拿一个可疑值全仓精确检索，排除测试目录后还有命中吗？
这段兜底逻辑的测试，断言的是「返回示例数据」还是「抛出」？
修完之后，有没有加一道能让下次自动失败的检查？

最后一条最容易被跳过，也最值钱。定位一次假数据是运气，让它下次进不来才是收工。