《为什么你总是查不出问题？不是能力不行，是排查路径碎了》
在掘金看技术帖，大家都在聊高并发、架构设计。但回到工位上，我们 80% 的时间其实都在处理一种极其枯燥的情况：
“线上出问题了，你帮我看看。”
这时候，人和人的差距瞬间就拉开了：
有的人像没头苍蝇，日志看两眼、代码翻半天，最后憋出一句“我本地复现不了”；
有的人点开监控看一圈，拉个 TraceID，三分钟就敢下结论：“别查了，是下游那哥们接口超时的锅。”
这真不是聪不聪明的问题，而是你脑子里有没有一套“能收敛”的排查路径。
我这几年踩过无数坑，总结了一套“土但极度有效”的排查法，今天聊聊怎么把问题“查死”。
一、 看看你是不是这么“查”问题的？
很多同学查问题查到最后想砸电脑，通常是因为陷入了这几个真实坑位：
场景一：Redis 慢，还是应用慢？（对齐意识缺失）
现象： 接口耗时突然飙升。
对话：
应用端：“Redis 监控看着有点飘，是不是 Redis 慢了？”
DBA：“Redis 响应都在 1ms 以内，是你自己网络或者连接池有问题吧？”
最后： 互相甩锅，问题石沉大海。
真相： 很多人查半天，连**“慢的时间点”和“QPS 负载”**都没对齐。慢的时候是 1000 QPS 还是 1W？是整点慢还是持续慢？没这些数据支撑，所有的判断都是“我感觉”。
场景二：交易失败，死磕自己代码（信息孤岛）
现象： 某笔交易报错，返回“系统繁忙”。
做法： 盯着自己那几行业务代码反复看，日志翻烂了也没报错。
真相： 现在的系统全是分布式。你的代码没报错，不代表下游没吞掉异常；你的逻辑没问题，不代表网关没把你拦截。不去拿外围信息（网关、DB、第三方服务），你这辈子也定位不到真相。
二、 我的排查路径：拒绝“发散”，必须“收敛”
我给自己定了一条死规矩：
先锁现象 → 再看日志 → 再看代码 → 再查依赖 → 最后怀疑底层
顺序绝对不能乱。一旦乱了，你就是在“碰运气”，而不是在“解 Bug”。
1. 先锁“现象”，别急着翻代码
接到报警，别第一时间打开 IDE。先问三个灵魂问题：
-
是全量还是个案？ （全量看发布记录，个案看参数特征）。
-
能不能稳定复现？ （不能复现的多半是并发冲突或外部网络抖动）。
-
时间点有没有猫腻？ （是不是刚好有定时任务在抢资源？或者隔壁组偷偷上代码了？）。
本质： 先把范围卡死。像 Redis 慢那种问题，如果你先把“时间点 + 并发”对齐，很多锅当场就能甩出去。
2. 日志：别只搜 Error，要找“断层”
很多人查日志只看红色的。但真正的凶手往往藏在 Info 里。
我一般只看三样：
-
TraceID： 看链路全过程，到底是哪一步开始变慢的。
-
入参： 入参是不是空？是不是传了奇怪的特殊字符？
-
逻辑节点： 既然没报错，那它到底走到哪个分支去了？
核心：不要只看“报没报错”，要看“哪里开始不对劲”。
3. 逻辑验证：那个 7 秒 SQL 教会我的事
这里插一个我刚踩完的坑：
之前有个接口慢得离谱，一查是慢 SQL，执行竟然要 7 秒。
当时有人看了一眼说：“这字段不是有索引吗？应该不是索引问题。”
换做以前，我可能就信了，然后去翻代码逻辑。但我这次死磕了一下：
-
先证伪： 我把 SQL 和执行计划一起丢给 AI 深度分析。
-
抓现行： 结果发现，虽然有索引，但因为数据分布问题，优化器压根没走这个索引，而是选了全表扫描！
-
暴力解决： 我尝试强制走索引（Force Index），结果耗时从 7 秒直接降到几十毫秒。
教训： 永远不要相信“应该没问题”，你得亲手去验证预想。
4. 向上/向下求援：去拿你没有的信息
如果你代码逻辑天衣无缝，那问题一定在“外面”：
-
往上看： 网关有没有拦截？Nginx 有没有丢包？
-
往下看： 数据库有没有锁？连接池是不是爆了？
-
往外看： 第三方接口是不是偷偷改了返回格式，但没通知你？
真相： 很多人卡住，是因为手里只有 20% 的信息，却想推断出 100% 的结论。
5. 必要的时候，怀疑“底层”
这一步最难，但也最关键。如果上面都排除了，那就得看：
-
网络抖动、线程池打满、DNS 解析失败、甚至宿主机磁盘 IO 爆了。
如果你一直只在代码层转，有些 Bug 你一辈子也查不出来。
三、 排查的灵魂：必须“收敛”
排查问题最忌讳“发散”。
查着查着发现“这个 SQL 写得不太好”，就去优化 SQL 了，结果主线问题忘了。
每一次操作都要像漏斗一样：
从系统 → 服务 → 模块 → 代码 → 外部依赖。
每一步都要能排除掉一种可能性，而不是增加一种不确定性。
写在最后
我以前也觉得，那些查问题快的人是不是有什么“直觉”。后来发现，他们只是比我多了一套**“证伪路径”**。
查不出问题，真的不是你技术不行。
大多数时候是：你手里的信息不够，或者你在错误的路径上绕圈子。
