用户截图里写着 2021 年
我拿到用户发来的截图，第一反应是翻错页面了------日期栏显示 2021 年，这是当初的设计原型图，不是当前线上页面。确认完这个之后，真正的问题浮出来：用户说「条数栏看不到、化学成分查不出来、模拟数据没有」，但我翻代码发现前端 9 个子页早就加了 query-count-bar 组件，后端对应接口也写好了。
「代码在，效果不在」------这句话是这轮排查的起点。我建了任务清单，准备逐项剥。
116 测试库没跑增量 SQL
前端 commit 0418113、后端 commit 27c6b3，都是当天 10:45 提交的，属于上一轮会话的产物。代码本身没问题，但 116 测试库的增量迁移脚本从未执行过。
后果很直接：新加的列在库里不存在，后端查询语句一跑就报 Unknown column 'sample_make_time' in 'field list'，接口返回空数组，前端拿到空数据自然什么都不渲染。
我连上 116 库跑了一遍 SHOW COLUMNS FROM material_testing_result，确认新列确实缺失。执行完迁移脚本后，接口立刻返回了 200 和正常 JSON。
旧数据的 apply_time 全是 NULL
迁移做完，化学成分查询通了，但模拟数据还是没。我翻了数据表，发现一个坑：早期灌入的模拟记录里，apply_time 和 make_time 两个字段绝大多数是 NULL。
当前页面的筛选逻辑是按申请时间/制样时间做范围查询。WHERE apply_time BETWEEN ? AND ? 遇到 NULL 字段，SQL 语义直接把它排除了------不是报错，是静默返回 0 行。用户以为「没数据」，实际上是查询条件把旧数据全过滤掉了。
解决方案不是改查询逻辑，而是补数据：跑脚本把 NULL 字段的记录按 created_at 回填一个合理的 apply_time。另外，IoTDB 里实时监控的源测点数据是上午 10:29 一次性灌进去的，模拟脚本没有持续运行，所以 10:29 之后的时间轴是空的。我把脚本改成每 30 秒追加一条，跑在后台进程里。
横向溢出把条数栏裁没了
数据问题解决了，用户还是说「条数栏看不到」。这时候我意识到布局层有独立问题。
前端跑在本机 3000 端口的 vite dev，热更新是通的，排除「改了没生效」。我直接用 CDP（Chrome DevTools Protocol）连上用户浏览器里已经打开的 localhost:3000/sj-material-testing 页面，读真实 DOM。
结果：query-count-bar 节点确实渲染了，高度 36px，但被父容器的 overflow-x: auto 横向滚动区裁掉了。根因是一个宽度写死的 1400px 表格撑开了布局，触发横向溢出，条数栏被挤到可视区域之外。把表格改成 min-width: 100% 并加 table-layout: fixed 后，溢出消失，条数栏回到视口内。
排查顺序比修 bug 本身重要
这轮折腾下来，真正耗时不是写代码，而是判断「问题到底在哪一层」。我给自己定了一个固定顺序：
- 先确认代码提交到了没有（git log 看 commit hash）；
- 再确认数据库迁移跑了没有（连库
SHOW COLUMNS）； - 再确认数据本身是否满足查询条件（手动 SELECT 几条看看 NULL 分布）；
- 最后才看前端渲染和布局（CDP 连真实浏览器）。
大多数「改了没效果」的问题，卡在前两层，根本轮不到调 UI。反过来，如果一上来就死磕组件代码，容易在布局上多花一小时，回头发现是数据库没迁移。
还有一个教训：模拟数据脚本别写成 one-shot。我这次 IoTDB 的数据 10:29 之后就是空白，用户下午来验收时时间轴全是灰的，看起来就像「监控坏了」。哪怕只是开发联调，脚本也该有个循环或者 cron 兜底。
做自动化这几年，最耗时间的从来不是写代码，是摸清每个平台的脾气。
这篇里提到的坑，都是真金白银踩出来的。 如果你手上也有重复度很高的活儿------批量发布、数据搬运、有固定规则的机械操作 ------可以在评论区说说你的场景，我看看能不能自动化掉。