1. Caveman是什么被嘲笑了十年却依然能打的调试哲学做后端开发的年头一长你会发现一个奇怪的现象越是资深的工程师越喜欢在一些看起来很低级的手段里找答案。两年前我把自己的一套排障方法整理成一个小项目名字就叫caveman——不是石器时代考古而是一种原始人调试法。简单说就是不依赖花哨工具靠打印、二分、最小复现这些笨办法把线上疑难杂症揪出来。这套方法在不少人眼里属于段子级别但说实话它帮我解决过太多IDE断点和APM都搞不定的实际问题。为什么叫caveman因为真的很像原始人手里就一根棍子不搞那些复杂的机械看到猎物就是一棍子。编程世界里的“猎物”就是那个藏在某行代码、某个数据、某个边界条件里的bug。棍子就是printf。你不需要什么花里胡哨的招式一步步走一棒子一棒子敲总能把问题敲出来。1.1 一个自嘲的梗一套严肃的方法论caveman这个词在程序员圈子里最早是一个自嘲的梗叫caveman debugging。很多开发者都有这种经历代码出了问题你懒得去断点调试直接在关键位置打一行print看看变量到底变成了什么。老手看到会笑着说你“原始人”。可几十年过去了print大法依然是很多一线工程师排查问题的首选。你可以说这是习惯但行为背后一定有可复用的逻辑。我把自己理解的方法论拆成三条信条第一不信任工具对状态的抽象直接观察原始数据第二一次只改变一个变量第三把复杂问题拆成可以手工枚举的小问题。这三条听起来简单真正做到的人并不多。很多人在排查问题的时候习惯把IDE断点撒得到处都是或者打开一堆面板结果鼠标点来点去问题反而看不清楚。注意这里的“不信任工具”不是指不用IDE而是指不要在不理解原理的情况下乱按按钮。caveman不是反智是反“迷糊”。1.2 为什么越复杂的工具越容易让你离真相更远调试的本质是什么是建立一个假设然后去验证它。可现代工具交给你的不是真相而是经过多层加工后的“数据投影”。APM面板告诉你接口变慢了但不会告诉你慢在哪一行IDE断点能命中却很难复现生产环境里的偶发现象。工具的抽象层越多你离事实的距离就越远。caveman方法论恰恰相反它要求你看最原始的输出用最原始的逻辑推演反而更容易靠近真相。我经常用生活里的例子来解释这件事。家里电灯不亮了一个靠谱的电工不会先搬来一堆检测仪器而是先看灯泡是不是烧了、开关是不是断了、零火线有没有电。他会用最直接的方式逐项排除。caveman就是这种电工思维——别急着上复杂度先用眼睛看用手摸用最基础的手段确认边界。1.3 这套方法的核心信条如果要用三句话概括caveman的哲学我会选这三句观察优先于猜测二分优先于扫描简化优先于堆砌。观察优先于猜测意思是任何假设都要先有数据支撑。你不知道问题在哪就先不要断言“一定是缓存问题”先去看缓存命中率、键值、过期时间看完再说。二分优先于扫描意思是不要从头到尾一行行读代码而是通过探针把问题范围一分为二每次排除一半。简化优先于堆砌意思是能用一个脚本复现的就不要开三个服务能用一条命令观察的就不要上全家桶监控。这套思路可以应用在几乎所有脑力劳动里不只是编程。2. 实操用Caveman三板斧定位真实Bug理论讲再多不如手上过一遍。下面这“三板斧”是我每次排障都会用的固定动作观察中间状态、手工二分、最小复现。这三招按顺序配合绝大多数bug在半小时内会被逼到墙角。下面我会用真实的排查场景来演示而不是只讲概念。2.1 第一板斧把系统停下来观察中间状态排查bug的第一步永远是复现。无法复现的bug你的一切假设都是空中楼阁。但生产环境的bug往往很难复现所以你要把现场拉回到眼前把关键的入参、数据库查询结果、外部接口返回值、临时变量全部打印出来让系统运行的每一步都留下脚印。不要小看这一步八成以上的问题在你把关键中间状态打印出来的那一刻答案就已经摆在脸上了。举个例子之前有个支付回调接口偶尔出现金额不对。我就在扣费前后各打了一行def handle_payment(user_id, order_id): print(f[caveman] start user{user_id} order{order_id}, flushTrue) user db.get_user(user_id) print(f[caveman] user loaded: {user.to_dict()}, flushTrue) price calc_price(order_id) print(f[caveman] price{price}, flushTrue) balance user.balance - price print(f[caveman] balance after deduct{balance}, flushTrue) ...结果一看两次calc_price返回的price不一致。原来是订单价格在首次计算后会被后台任务修改而这个回调走了缓存。问题不在扣费逻辑而在价格来源。如果没有中间状态的打印我可能会在扣费函数里抠半天。这段实操我在最后加了个flushTrue这个细节很多人会忽略。Python的print默认有缓冲如果你是在高并发或消息队列环境里排查缓冲区未刷新会导致你看到的日志顺序和真实执行顺序不一致反而误导判断。加flushTrue能确保每条日志立即落盘虽然性能有一点损耗但调试期间无所谓。2.2 第二板斧手工二分一小时缩小到一行如果打印所有状态太费劲就用二分法。向系统输入一个可控样本在中间位置加一个探针判断问题发生在探针之前还是之后。一次能排除一半代码三次就能缩小到一个函数再用两三次就能定位到一行。这个方法的价值在于你不需要理解全部代码只需要在关键节点判断“对/不对”。举一个搜索接口超时的例子。用户反馈某个列表查询偶尔卡住时长达到20秒。我采用的步骤是在入口、ORM查询前、SQL执行后、序列化完成前分别打点记录时间戳。日志显示耗时几乎全在ORM查询那一段于是再把ORM实际生成的SQL打印出来直接拿到数据库客户端执行发现它走了全表扫描。最后定位到是联表查询的关联字段没建索引。这里有个心得二分探针不要一次加太多。最理想是每次只加一个跑一次看结果再决定下一步在左半边还是右半边加探针。如果你一口气加了二十个print输出信息又乱又长反而失去了二分的效率。一次一针稳准狠。2.3 第三板斧最小复现让偶发变必现偶发bug是最讨厌的线上有报错本地就是复现不了开发环境和生产环境明明“一样”结果就是不一样。这时候你得想办法做最小复现。核心思想只有一个不断削减无关变量。把外部服务换成mock把随机数固定住把并发线程数降到2把数据量从一百万砍到一百条让问题可以在一条命令里稳定触发。一旦能必现这个bug基本就修好一半了。我之前遇到过一个定时任务每天凌晨随机挂掉手动一执行又是成功的。当时我用caveman思路做了一个重放脚本把最近七天触发失败的历史任务输入全部记录下来固定时间点、固定数据顺序循环重放。到第37次重放时问题稳定出现了——原来某个字段在业务上永远不该为None但这条脏数据里它就是None后续计算直接除零。这个案例说明一个道理偶发不等于随机它只是你还没找到触发条件。最小复现的过程本质上就是帮你把“偶发”翻译成“必现”的过程。一旦触达必现剩下的就是纯手工活。2.4 一个完整的排查实录这里我再演示一个完整流程方便你直接套用。假设你运维一个Python服务线上日志里有客户投诉“下单偶发失败”错误信息是网关超时。按caveman方式操作第一步拿到最近10条失败请求打印完整的请求头、业务参数和异常堆栈。很多团队第一时间只看异常信息不看入参这是不对的。入参决定了一切后续行为先确认入参没有异常。第二步在调用第三方API之前和之后分别打点记录请求ID、耗时和返回状态# 排查脚本重放历史请求寻找失败规律 for payload in replay_data: try: resp session.post(API_URL, jsonpayload, timeout2) print(f[caveman] id{payload[id]} status{resp.status_code} cost{resp.elapsed.total_seconds():.3f}s) except Exception as e: print(f[caveman] id{payload[id]} ERROR {type(e).__name__}: {e})第三步重放后发现失败请求都是发生在同一批keep-alive连接被复用之后。也就是说连接池里的某个连接被服务端悄悄关闭但客户端不知道复用时直接收到RST。定位到这一层修复方案就简单了给session加上重试机制并且在ConnectionError时丢弃这个连接重新建立。整个过程大概四十分钟一个IDE断点都没用全是print和重放脚本。这就是caveman的威力。3. 把Caveman用在开发里极简主义的编码实践Caveman不只能用来调试它也是一种写代码的态度。软件开发里有一种病叫“框架上瘾”需求刚下来先不管业务复杂度先开个工程拉一堆依赖。而caveman提醒我们棍子能解决的事不要急着造投石车。保持简单不只是一种审美更是一种对故障率的控制。3.1 能print的先print能写脚本的不要上框架很多时候我们接收到一个简单需求比如“每天统计一下订单量并且发个邮件”这点事用Python标准库加一个crontab就够了。但有些同学上来就是Flask加APScheduler加Docker加K8s折腾了一天邮件还没发出来。这不是开玩笑我见过太多“毕业设计式”代码为了用某个框架而写业务而不是为了业务选框架。我个人的原则是先写一个能跑通的最小脚本再考虑要不要封装。如果这个脚本未来三个月都不会变复杂那保持脚本就好。如果发现多处模块要复用再拆函数、再上合适的框架。这样做的最大好处是你的核心业务逻辑不会被框架的启动流程和配置项淹没出了问题也特别好排查——因为代码本来就少一眼就能看完。当然这并不是说框架不好。当项目真的进入多人协作、需要鉴权、需要单元测试、需要部署编排的阶段框架带来的统一约束能省很多事。caveman式的极简指的是“不提前加载复杂度”而不是“永远拒绝复杂度”。判断标准就一句话当前这个需求最朴素的实现能不能满足能满足就先别加东西。3.2 用断言把“没想到”变成“必现”好的调试者是预防型的。在写代码的时候就把那些“不可能发生”的情况变成显性检查。断言的本质是把假设写进代码一旦假设破裂它会立刻发出警告而不是让错误漂移到三天之后才爆雷。比如你写了一个状态机老手会加一句assert user.status in (active, disabled), funexpected status: {user.status!r}你可能会觉得多此一举但在真实系统里就是会有某个历史数据status为banned而你所有的if/else都没处理它。不加断言它可能在某次统计里悄悄出错加一句断言它当场现形。这种“早失败”哲学和caveman的“先观察再猜测”是一致的不要相信假设让假设接受检验。当然断言也有使用边界。Python里的assert在-O优化模式下会被移除所以如果这个检查线上必须生效不能用assert要写显式的if-raise。这个坑我踩过以前天真地以为assert在所有环境都会执行后来才发现生产环境可能被优化。caveman式的排查有时候会让人觉得玄学其实不是是你对运行环境的基础知识不够扎实。3.3 打点与采样的艺术如何不淹没在日志里print大法虽好但如果无脑print日志会变成噪声最后什么都看不清。这里我分享几个实用技巧都是我踩坑踩出来的。第一所有临时调试输出统一加前缀[caveman]方便grep。第二用logging模块而不是裸print把级别设为DEBUG线上运行时不输出排查时动态打开。第三只打印节点信息不要打印全量数据。比如打印字典的key列表、列表长度、耗时毫秒数而不是把整个大对象怼进日志。第四循环里不要每条都打做采样打印每100条打一条既能看到趋势又不拖垮性能。示例import logging logging.basicConfig(levellogging.DEBUG, format%(asctime)s %(levelname)s %(message)s) logger logging.getLogger(caveman) # 在关键节点采样 for i, item in enumerate(items): if i % 100 0: logger.debug([probe-01] processed%d last_id%s, i, item.id)这样一套下来日志既是排障工具又具备监控打点的雏形。很多线上问题事后看这些日志能直接还原当时的现场比事后问同事“你刚才做了什么”要靠谱得多。我自己的习惯是给这些调试日志设计一个固定的“探针编号”之后在日志平台里按编号搜索几秒钟就能把一次完整调用的路径串起来。4. 常见问题与排查技巧实录这一节写一些我实际遇到的问题以及对应的caveman处理方式。不算完整教程更像是你手边的速查手册。碰到类似的场景先别慌翻一翻这张表再决定从哪里下棍子。4.1 这些问题第一反应就该用Caveman第一种偶发超时。很多服务都有偶发超时第一反应不是去调超时时间而是打印每次调用的耗时和返回码画一个简单的耗时分布。如果发现99%请求都在50ms只有1%在5秒再去查那1%是不是应用层重试、GC暂停、慢SQL思路会清晰很多。第二种数据不一致。两个服务对同一份数据怎么算都对不上那就打印双方拿到的原始值以及每个值对应的对象id。很多时候你会发现“同一个订单”在两边根本不是一个对象只是用了相同的主键字段版本完全不同。第三种并发竞态。现象是多线程下偶尔状态错乱。别急着上锁先打印线程id和关键状态观察一下发生错乱时的线程交错序列。你可能会惊讶地发现错乱只发生在某一个特定顺序下而那个顺序在单线程里永远不可能出现。第四种缓存和数据库不同步。这是数据不一致的一个特殊版本。做法是打印缓存的写入时间、数据库的最后更新时间、以及对应的业务主键确认到底是谁覆盖了谁。很多时候问题根源根本不是缓存过期时间设短了而是写入顺序反了。4.2 问题速查表现象大概率原因Caveman排查法接口偶发500连接池耗尽或网关超时打印连接创建时间、归还状态、每次请求耗时数据库数据错乱共享可变对象或缓存穿透打印对象id、缓存key、查库结果响应慢但不报错N1查询或锁等待分段打点二分定位最长耗时区间本地正常线上失败环境差异或时序问题录制线上输入到本地重放定时任务凌晨挂掉脏数据或依赖服务维护固定时间、固定顺序重放历史数据多线程状态错乱竞态条件打印线程id观察交错序列这张表不是让你照抄而是给你一个思考框架。关键在于无论现象多诡异总要找到一个可观察的最小切入点然后再扩展。只要你还有办法打印出变量的值这个bug就还没有到无解的地步。4.3 几个越早知道越好的避坑心得第一生产环境永远不要用裸print。裸print默认走stdout线上日志采集系统可能根本不会收你还得去容器日志里翻效率极低。请使用logging接入统一日志平台。第二打印不要只打印结果要打印关键条件。比如“任务被跳过”这种日志不要把日志写成skip task要写成skip task reasonxxx last_runxxx否则你根本不知道为什么会跳过。第三临时调试代码删除前先想一下这条日志能不能固化成永久监控指标。能的话就翻译成结构化字段不能的话再删。这样可以积累一份属于自己的“系统体检日志”。第四别在循环体里打印大对象这会卡死性能。我见过有人在一个万级循环里打印整个请求体结果本来2秒的任务跑了40分钟。改为采样打印后问题很快就定位了。5. 什么时候该放下棍子从Caveman到更专业工具caveman不是万能药。写到这里我要说几句实话免得你回去迷信print、放弃学习现代工具。原始人最终也要学会农耕工具升级是必然的。棍子能打猎但打不了天上的飞机print能查逻辑错误但有些问题天生需要重型武器。5.1 边界判断这些场景别硬用printprint适合逻辑错误、状态错误、外部交互问题。但遇到内存泄漏、死锁、性能热点时单靠print真的很难搞。比如内存泄漏print只能让你看到对象越来越多却看不到是谁在持有引用这时你需要pympler、tracemalloc或heap profiler。又比如死锁print只能告诉你卡住了但要看到线程栈才能知道互相等待的锁这时py-spy dump或gdb更直接。我的判断标准很简单三分钟之内print打不出任何有用信息就换工具。工具不是敌人盲目坚持旧方法才是。caveman的意义在于提供一条低成本的起点而不是阻止你成长。现代工具和caveman并不矛盾它们应该配合使用先用最便宜的手段建立假设再用专业工具去验证假设。我接触过很多年轻工程师他们最好的习惯就是遇到问题先自己搭一套最小复现脚本这个习惯会让他受用很久。5.2 我的个人体会调试的本质是提出好假设有一次线上服务OOM所有人都在讨论扩容、换语言、上容器我却在日志里发现某段代码在不断向一个列表追加元素且列表竟然被定义在全局变量里。那个bug不是内存分析工具直接丢给我的而是我先用caveman式的日志采样发现了可疑模式再用profiler去验证最后一锤定音。这些年我的体会是调试工具再先进也代替不了观察和推理。大多数bug的根源其实不在代码而在你没有观察到的中间状态里。先学会像一个原始人那样老老实实看数据再去驾驭那些华丽的现代工具你才能真正做到“稳、准、狠”。下次再有人嘲笑你print调试你可以大方告诉他这叫caveman debugging是原始但有效的生存本能。棍子拿好了比什么花架子都实在。