“caveman”这个词最近在技术社区有点意思。以前大家看到它，想到的是《疯狂原始人》里那个壮汉Grug，但如今在程序员圈子里，这个词代表一种非常硬核的调试流派——Caveman Debugging，原始人调试法。说实话，这名字听着像是嘲讽，但它背后是一套我自己用了很多年、而且几乎每次线上故障都能救命的方法论：不打断点、不跑调试器，就是在代码里到处插日志，把程序运行过程中的关键状态打出来。这篇文章我就想围绕caveman这个话题，把它的本质、适用场景、实操套路和坑，原原本本梳理一遍。不管你是刚入行的新手，还是已经被线上偶发Bug折磨到怀疑人生的老兵，这篇内容应该都能给你一点参考。
1. Caveman Debugging到底是个什么方法
1.1 为什么“最土的方法”反而最可靠
很多人第一次听说Caveman Debugging，第一反应是：这不就是print大法吗？有什么好讲的。确实，从表面看，它做的事就是往代码里加print、加日志，然后运行程序看输出。但我要说，这个方法的本质不是“偷懒”，而是对程序行为的一种客观记录。
调试器的问题在于，它依赖一个前提：你能够在关键位置停住程序，并且能够复现问题。本地开发的时候，这个前提基本成立。但一旦到了线上，尤其是分布式系统、多线程并发、第三方接口联调这些场景，调试器几乎派不上用场。你不可能在线上服务器上挂一个断点然后等人触发Bug，就算你想这么做，也往往无法复现问题。而日志是程序运行过程中留下的唯一客观痕迹，是程序自己讲述它经历了什么的方式。
从这个角度看，Caveman Debugging的本质，是承认一个事实：程序在真实环境里的行为，只有靠它自己“说”出来才是最可靠的。你的推理、你的代码审查、你的经验，都只是假设。日志才是证据。原始人不一定笨，他只是选择了最直接有效的方式。
1.2 适合什么场景，不适合什么场景
我这些年用下来，Caveman Debugging适合解决这几类问题：
第一类是线上偶现Bug。你压测都正常，但生产环境隔三差五出问题，重启一下又好了。这种问题你根本没法在本地复现，唯一能依赖的就是日志。
第二类是第三方接口联调。对方的系统像个黑盒，你不知道它内部发生了什么。你能做的，就是在自己调用它的前后把出入参、耗时、返回码都记下来，以此推断问题出在哪一侧。
第三类是多线程并发问题。死锁、资源竞争、队列积压，这些问题对时序敏感，用调试器打断点会改变时序，反而更难复现。日志因为侵入性低，相对能还原真实情况。
第四类是性能瓶颈的初期定位。你不确定瓶颈在IO、CPU还是锁竞争，先打几个耗时日志，看看时间都花在哪，比直接上性能分析工具更快更直观。
但话说回来，Caveman Debugging也不是万能的。如果你的问题纯粹是算法逻辑复杂、数据结构没想清楚，那在本地用调试器逐步跟踪可能效率更高。还有内存泄漏、GC问题，这类问题用日志不是不行，但通常得配合专门的工具才能定位准确。所以我的态度是：caveman是一招鲜，但不是唯一的招。
1.3 一个容易被人忽视的认知：这不是技术债
网上偶尔会有人吐槽，说代码里全是日志、print，调试完也不删，搞得代码很脏。对这个观点我一半同意一半反对。
调试完临时加的print确实应该清理，但那些有信息量的日志，是你系统可观测性的基石，是资产不是负债。真正的问题不在于“打日志”这个行为，而在于“没有章法地打日志”。如果你只是随手打一句“here1”“here2”，那当然是垃圾。但如果你在关键路径上、关键决策点、外部调用边界上留下了结构化、有上下文的日志，那这些东西下次排查问题的时候就是救命稻草。
2. 核心实操：如何在代码里用好“打印大法”
2.1 埋点位置怎么选
很多新手打日志是随缘的，想到了就加一行，什么都没想就加一行。这样做的结果就是，日志倒是打了很多，真出事的时候一条有用的都没有。
我给自己总结了一套埋点规则，基本上覆盖了80%的场景。你照着这个思路去加日志，大概率不会白打。
第一，入口和出口。一个方法进来了，参数是什么；返回了，结果是什么。这两个位置各打一条，你就知道这个方法的调用是否成功，入参出参是否匹配预期。
第二，分支边界。代码里走到if还是else，走的是哪个分支，这个决策点非常重要。因为很多时候Bug就是分支判断条件写错了，走到你没想到的那条路上了。
第三，循环内部和批量处理。注意，这种地方打日志要控制频率，否则数据量大了一秒几百万条日志直接把你磁盘打爆。我的做法是：每处理N条打一条，或者只打印异常和特殊状态。
第四，外部调用的前后。调用数据库、Redis、第三方HTTP接口的前后，必须打日志。一来你能看到耗时，二来你能看到入参出参，这是排查上下游问题最关键的证据。
第五，异常捕获处。catch块里一定不要只写一句log.error(e.getMessage())，要带上当时的上下文，比如正在处理哪条数据、用户是谁、请求参数是什么。没有上下文的异常日志，基本等于没打。
第六，关键状态变化。比如订单状态从待支付变成了已支付、线程池触发了拒绝策略、缓存发生了穿透，这些状态迁移和风险点，必须有日志。
2.2 日志内容怎么写才算合格
光有位置还不够，日志内容才是灵魂。我见过太多这样的日志：log.info("success")。这条日志你告诉我成功了，但成功的是什么事？参数是什么？耗时多少？通通没有。这种日志在排查问题的时候一点用都没有。
一条合格的日志，至少应该包含三样东西：这是谁（业务标识），发生了什么（关键参数和状态），花了多久（耗时）。我举个例子，假设你在做一个订单超时关单的任务，好的日志应该长这样：
orderId=123456, action=timeoutClose, status=PAID->CLOSED, cost=32ms, triggerReason=paymentTimeout
这条日志你一看就明白：处理的是哪个订单，做的什么操作，状态怎么变化的，消费了多长时间，为什么触发。下次要是有人投诉说订单被误关了，你拿这条日志一眼就能看出是不是超时导致的。
如果是在多线程环境里，你还得加一个traceId。什么是traceId？说白了就是一次请求的身份证号。一个请求从前端进来，到后端各个服务处理，一直到返回，期间产生的所有日志都带上同一个traceId。这样你把日志收集起来一搜，就能把所有环节串成一条线。没有traceId的分布式日志，就是一堆碎片，拼不出完整故事。
2.3 日志级别与输出方式的讲究
日志级别这件事，很多人觉得没什么好学的，不就debug、info、warn、error四种嘛。但实际用起来，级别选不对会造成两种恶果：一种是该看的看不到，一种是不该看的刷屏。
我自己的习惯是这样的。debug级别，只记录那些对普通人没意义、但排查问题时可能需要的信息，比如详细的循环变量、中间计算结果。info级别，记录关键业务动作，比如下单、支付、退款、关单，这种日志应该默认开着，方便随时看业务流转。warn级别，记录那些不致命但需要关注的情况，比如接口调用超时了但重试成功了、缓存穿透了但DB还是扛住了。error级别，记录确实出错了、需要人工介入的情况。
有一种很典型的错误：程序员习惯把所有日志都打成info。结果就是pro环境日志量大得惊人，真正重要的error被淹没在里面。还有一种错误是反过来，把什么日志都打成debug，线上默认级别一过滤，啥都没了。
再说输出方式。很多语言的日志框架支持按级别拆分输出，比如info及以上打到stdout，error单独打到stderr或者一个错误日志文件。这个配置建议你花时间搞一下，排查问题的时候效率会高很多。另外，日志框架基本都支持运行时动态调整级别，比如你可以在管理后台把某个类的日志级别从info调成debug，不用重启服务就能拿到更细的信息。这个功能实测非常香，线上排查问题的时候，先用info粗筛，锁定了怀疑范围再把那个包的级别调成debug，精准打击。
2.4 性能与安全：日志不能乱打
打日志是有成本的。别小看这一行输出，在高并发场景下，日志就是磁盘IO杀手。我自己就见过一次事故：某团队在循环里打了info日志，结果活动流量一上来，QPS才几千，磁盘IO直接打满，整个服务都被拖垮。所以打日志之前，心里要有根弦：这个位置一分钟会被执行多少次？如果确认是高热路径，要么不打，要么打debug级别，要么做采样。
采样的意思很容易理解，不是每次都打，而是比如每100次打一次，或者每秒钟最多打N条。很多日志框架自带采样器，不需要自己实现。
安全方面更要上心。密码、token、身份证号、手机号这些敏感信息，千万不要打到日志里。这不是说你不小心，而是有一天你排查问题打了一条log.info("login user: " + user.getPassport())，日志文件里就存了明文密码，到时候安全事故回溯时你就是第一责任人。我自己处理敏感字段的逻辑是：统一用脱敏工具，比如姓名只保留姓、身份证号只留前后两位，手机号中间四位打星号。这个习惯早养成早省事。
3. 实操过程回顾：一次“幽灵超时”排查实战
3.1 现象与初步假设
去年我维护过一个订单服务，功能很简单，用户下单后要调用仓库系统的库存扣减接口。问题很诡异：系统平时好好的，压测也通过，但每天总有那么几单会超时。用户没收到下单成功的反馈，后台一查订单状态却是正常的。客服那边陆续收到投诉，说下了单但页面转了十几秒才跳转。
一开始团队里有几种猜测：有人说是网络抖动，有人说是下游库存系统不稳定，还有人怀疑是网关超时设置不合理。你问我信哪个？我哪个都不信，因为都是猜。这种场景就是典型的“幽灵Bug”——偶发、无规律、重启就好转。遇到这种问题，我脑子里第一时间浮现的就是caveman三个字：上日志，别废话。
3.2 埋点设计与上线观察
我把排查范围锁定在“下单接口从入口到调用仓库系统的整个链路上”。然后按前面说的埋点规则，加了几条info日志。
第一条，订单中心收到下单请求：记录订单号、用户ID、商品SKU、请求参数。第二条，在调用仓库扣减库存之前：记录将要发送的出参数据。第三条，在调用仓库扣减库存之后：记录返回结果、耗时、状态码。第四条，在下单接口返回之前：记录整个方法总耗时和最终订单状态。
这几条日志加完，发布上线。剩下就是等。大概过了一天多，我捞到了几条耗时异常的单子，日志链路是这样的：
orderId=898989, receive request, user=333, sku=88888, cost=2msorderId=898989, before call stock-service, param: sku=88888,num=1orderId=898989, after call stock-service, result=success, cost=4500msorderId=898989, return response, finalStatus=PAID, totalCost=4520ms
看到没有，问题不在网络，也不在下游系统本身，而是卡在“调用库存接口”这个环节，一次调用花了4.5秒。如果只是第一次网络超时，第二次重试应该很快；但现在不是超时，是长时间未返回，说明问题出在下游服务的线程池上。
3.3 深入定位与验证
为了验证这个猜想，我又补了一步日志：在库存扣减接口的provider端，也加上了接收请求的时间戳、开始处理时间戳和完成处理时间戳。同时，我把跨服务调用的链路ID打通，保证我在订单服务和库存服务看到的是同一条请求。
第二天，再次抓到一条慢单，节奏完全对上了：
订单服务侧：before调用时间戳 T1，after调用时间戳 T4。 库存服务侧：接到请求时间戳 T2，开始处理时间戳 T3，完成处理时间戳 T5。
时间线一拉出来就清楚了：T1到T2之间就隔了将近3秒。也就是说，请求已经发出去了，但是服务端迟迟没有从网络缓冲区里取出来处理。这说明请求到达了库存服务，但库存服务的线程池已经全部被占满，请求只能在队列里排队等待。
那队列为什么会积压？继续看日志，发现库存服务里有几个批处理任务，每天固定时间跑，把线程池的核心线程全部占住，而且池队列是无界的。批处理一跑，在线订单请求就只能在队列里慢慢排队，排队时间一长，一个下单请求耗时几秒甚至十几秒也就不奇怪了。
为什么是偶发？因为批处理任务也不是每次都占满，还要看当时的业务请求量。有时候批处理跑得快，队列还没来得及积压就结束了，订单请求就不会明显变慢。这就是“幽灵超时”的真相。
3.4 修复与复盘
定位到根因之后，修复方案就很清晰了：把库存服务的线程池从无界队列改成有界队列，加上拒绝策略，并且把批处理任务挪到凌晨低峰期，或者单独用一个隔离的线程池来跑，避免和在线业务抢资源。
这个排查过程中，我用到的工具就只有日志，没有调试器、没有火焰图、没有复杂的镜像分析。整个过程大概花了三天，其中一半时间在等日志自然收集。事后我在复盘文档里写的第一句话就是：这个Bug是靠几行info日志打的，不是靠猜打的。
4. 常见问题与排查技巧实录
4.1 日志常见的坑，一个一个踩给你看
日志打得不好，排查问题的时候反而更痛苦。我整理了我自己踩过以及帮别人排查过的一些高频问题：
第一个坑，日志打了但不输出。最常见的原因是级别不对。你打的是debug，线上配置的级别是info，那debug日志当然不会出现。这种情况正确做法是：确认当前环境日志级别，如果怀疑某个包有问题，手动调低级别。
第二个坑，日志量太大导致磁盘打爆。这个前面也提过，循环里打日志、大对象toString打到日志里、HttpServletRequest直接打出来，这些都是磁盘杀手。一旦磁盘满了，服务直接不可用，比原来的问题还严重。我的解决思路是：任何日志输出前先问有没有必要，有没有频率控制，有没有大小限制。
第三个坑，日志内容和上下文脱节。很多异常日志就是log.error("exception")，你不看堆栈不知道错在哪，连哪个用户触发都不知道。正确做法是异常日志必须带业务标识，比如当前订单号、用户ID、处理的数据主键，这样一搜就能定位。
第四个坑，traceId没打通。在分布式系统里，每个服务各打各的日志，没有traceId串联，你看到的就是一堆断线索。排查问题的时候，你根本不知道哪个请求对应哪个环节。解决方式很粗暴：统一接入全链路追踪中间件，或者在每次调用的公共里强制带上traceId。
第五个坑，时间格式不统一。有的服务用毫秒时间戳，有的用带时区的字符串，有的字符串还不带时区。一对比日志，时间都对不上，白忙活一场。建议所有日志时间统一用ISO 8601格式，并且统一到同一个时区。
4.2 排查思路：从现象逆向推，而不是正向猜
排查问题的效率差异，主要取决于思路对不对。我见过很多人，一上来就猜：是不是代码写错了？是不是数据库慢查询？是不是网络问题？然后各种查，查了一整天也没结论。
我自己更倾向的做法是：先从现象出发，列出所有可能的位置，然后用日志一层层排除。还是拿刚才那个超时案例来说，用户看到的是“下单超时”，那超时可能发生在哪？从用户点击提交到请求到网关，到订单服务，到库存服务，到数据库，每一个环节都可能是瓶颈。这时候正确的动作不是猜，而是在每一个环节的入口出口打好日志，看时间消耗在哪一段。日志就像一张张检查点，哪一个点之间耗时异常，问题就在哪一段。
这个方法我用了很多年，有个很明显的感受：它逼着你去接近证据，而不是相信直觉。很多老程序员经验丰富，直觉往往很准，但偶尔也会翻车。caveman思路就是帮你把翻车概率降到最低。
4.3 合理和调试器配合：不是水火不容
前面把caveman吹了一通，但我也要客观说一句，它和调试器不是二选一的关系。本地开发、单元测试阶段，调试器效率高得多，因为你能实时看到变量值变化。但线上问题、环境问题、并发问题，调试器基本无能为力，这时候就用caveman打法。
两者结合的最佳实践是：本地用调试器把逻辑问题在开发阶段就消灭干净；线上只用日志和监控，不指望调试器。把调试器当外科手术刀，把caveman当野战医疗包。多数的故障，用野战医疗包就能救回来，备着手术刀也不用天天带着。
5. 从“原始打印”走向现代可观测性
5.1 结构化日志，让日志变成数据而不是文本
很多人打日志还停留在纯字符串拼接，比如log.info("orderId=" + orderId + ",status=" + status)。这种日志人能看懂，但机器很难聚合分析。如果有一天你需要在成千上万条日志里按订单号检索、按状态统计、按耗时排序，纯文本日志会非常痛苦。
结构化日志的核心做法是，把日志输出成JSON格式。比如上面那个订单日志，打出来是：
{"time":"2024-05-20T10:15:30.123Z","level":"INFO","traceId":"a1b2c3","service":"order-service","orderId":"898989","action":"timeoutClose","status":"PAID->CLOSED","cost":32}
这种日志，Elasticsearch可以很轻松地按任意字段索引，Grafana和Loki可以直接按字段过滤。你在排查问题的时候，一个搜索框输入orderId:898989，所有相关日志全出来了。用一个词说，这就是把原本要人肉翻的文本，变成了能自动查的数据。
5.2 日志收集、检索与告警，搭一个朴素版可观测性体系
日志打好只是第一步，收集和检索才是放大器。我的建议是，哪怕你们团队再小，也要搭一个日志收集平台。方案有很多很多：ELK生态、Loki、LPG轻量级组合，都行，关键是别用“直接ssh上服务器用grep翻日志”这种原始办法。
为什么强烈建议搭平台？因为你在生产环境排查问题的场景通常是：问题发生在凌晨，你早上才看到报警，日志在服务器上还在轮转，也许刚好被滚动覆盖。如果日志都进了集中式平台，你可以直接把时间范围拉长，翻到凌晨那几分钟的日志，定位效率天差地别。
有了集中式日志平台之后，告警规则也要跟上。不是所有错误都需要你半夜爬起来处理的，但有几类必须告警：error级别日志突增、某个接口的平均响应时间超过阈值、日志量突然下降（有可能是采集挂了，也可能是服务挂了）。这些规则可以慢慢加，先告警后精细。
5.3 工具再怎么换，方法论还是caveman
你可能觉得，都上了log平台、trace中间件了，还算什么caveman？算，非常算。因为本质上，你还是把关键路径上的证据留下来了，还是通过日志在还原问题现场。变的只是存储和检索的方式，不变的是“你永远要相信日志告诉你的事实，而不是猜测”。
我见过很多团队，工具很豪华，一字排开的dashboard，恨不得每个请求都能追踪到变量级别，但事故一来，照样手忙脚乱。为什么？因为他们的核心业务代码里，该打的日志没打，或者打了也是垃圾日志。工具能放大的，是你日志里已有的信息量；如果日志本身没有信息量，再贵的平台也只是在帮你快速浏览一堆废话。
所以我的建议是：先从业务代码的日志做起，把日志当代码功能的一部分来对待，每个新增功能都要问一句，这条路径上出了事，日志够不够我定位？当这个习惯养成之后，再去上工具，你会发现自己搭建的可观测性体系比那些大而全的框架有用得多。
最后再分享一个我这些年坚持的小习惯：每次修完一个线上问题，我都会回头看一下，这个问题如果一开始有好日志，是不是能少花一半时间？如果答案是肯定的，我就顺手在问题代码附近补一条日志。时间久了，那些容易出问题的位置，日志会越来越齐全，系统也变得越来越“透明”。做这一行的都知道，一个能随时讲清楚自己状态的系统，比一个看起来完美但出事全靠猜的系统，要值钱得多。
