“caveman”这个标题其实很有意思。我第一次看到这个项目的时候正好在处理一个老系统的线上问题——那个系统装了无数依赖、跑着一堆微服务结果一个配置文件的小错误导致整个服务链崩了。当时我就想要是当初有人把它做成一个“caveman”风格的系统就没这么多破事了。所谓caveman指的是那种刻意保持原始、简单、粗糙但能用的实现方式——不追求花哨的架构、不引入多余的抽象、不堆砌炫技的功能就用手边最朴素的工具把问题解决掉。这篇内容就基于“caveman”这个代号聊聊我把它当作一套极简技术理念来落地时的完整思考、实操过程和踩坑记录适合那些受够了复杂系统、想回归“能跑就行”路线的开发者也适合刚入行、被各种框架搞得一头雾水的新人。1. 为什么一个技术项目要叫“caveman”命名的底气与核心理念1.1 从原始人身上学到的第一课工具越少反而越可靠我见过太多项目死在“过度设计”这四个字上。一个新服务刚立项上来就规划六个微服务、三套消息队列、两个缓存中间件、一个Kubernetes集群。结果呢一个月的开发周期半个多月在搭基础设施和写配置文件真正的业务逻辑反而没写几行。等上了线光排查链路问题就够喝一壶的。相比之下caveman这个名字所代表的态度恰恰相反——穴居人没有那么多工具但人家活了几百万年。原始人手里只有石头和木棍却能打猎、生火、盖房某个功能没有精细化处理不影响生存。这套逻辑放到软件开发里太通用了。我理解的caveman风格不是“不会用高级工具”而是“刻意选择不依赖过多工具”。它不是一种无能而是一种克制。当你被微服务、Serverless、Service Mesh、可观测平台这些概念裹挟着往前跑的时候caveman帮你踩一脚刹车问一句我的业务真的需要这些东西吗还是说我只需要一个简单的脚本就能搞定这个项目——或者说这套理念——的核心就三点依赖最少化、逻辑朴素化、部署直接化。依赖最少化是指能不用第三方库就不用标准库能解决就绝不上框架逻辑朴素化是指能用循环解决的就不引入复杂的数据结构能用同步写的就不上异步部署直接化是指能一条命令跑起来就不写Dockerfile能裸机跑就不上编排平台。这三点做实了你手里这套东西的故障面就小得可怜因为每一个坑都是你自己挖的你清楚每一个角落是怎么长出来的。1.2 caveman不等于简陋而是砍掉99%的伪需求有人可能误会觉得caveman就是把代码写成一坨不管可维护性不写注释没有结构。这个理解是在给“原始”泼脏水。真正的穴居人其实是很精致的生存专家——他们知道哪种石头适合做斧头哪种骨头适合做针打磨工具的手艺可能比我们现在写代码还精细。所以caveman风格追求的是极致的简约而不是极致的粗糙。举个实际例子。有一个模块我需要处理定时任务用成熟的框架自然很爽几行配置就能搞定CRON表达式解析、并发控制、异常重试。但caveman的做法是一个daemon循环读取本地一个文本文件里面存着任务ID和执行时间戳到点就执行对应函数。把同步逻辑放在锁里防止同一个任务被并发触发。代码量不超过200行不需要Redis存状态不需要MongoDB记录日志系统重启了就从文本文件里恢复状态。跑了一年多出问题的概率是零因为状态都在盘上进程死了重启读文件就是一致状态。说真的很多复杂需求是我们在想象中造出来的。你说要在多个节点之间协调任务不重复执行——那你就得引入分布式锁。但如果你只需要在一台机器上跑呢那问题就简单到根本不需要“分布式”这三个字。caveman方法论里最重要的一条就是先问你的问题域有多大再决定用多大的工具。小问题用大工具除了增加自己的维护负担没有任何好处。2. 回归原始的第一步零依赖与最小工具链的落地姿势2.1 环境准备一台干净机器上能跑出东西才是真的能跑很多项目环境准备阶段就把人搞崩溃了。什么Node版本管理器、Python虚拟环境、Docker镜像、依赖缓存一套下来光装环境就能折腾两天。caveman风格的环境准备极其粗暴操作系统自带的解释器/编译器加上系统包管理器装的一个运行时没了。我推荐从Python 3自带的venv模块开始但说实话venv也算一个“依赖”如果系统Python版本够新我连venv都懒得用直接在系统环境里跑脚本。真的对于个人维护的小工具、内部自动化脚本系统环境根本没有你想象的那么脏。只要你控制住自己不随便pip install系统Python一年下来也就干干净净。命令大概长这样# 不需要虚拟环境直接系统Python python3 --version # 唯一允许的三方库requests如果标准库搞不定 pip install --user requests # 跑起来 python3 main.py如果你连requests都不想装Python标准库里的urllib也能发HTTP请求多少有点难用但对“发一个GET请求拿到JSON”这种需求完全够。我实测过urllib发请求的代码量只比requests多三行无非是手动处理一下URL编码和响应头。这种“什么都能凑合”的态度恰恰是caveman的精髓——不是没有更好的工具而是先用最简单的方案跑通出了问题再去升级。2.2 工具选型的终极标准能遁入文本就绝不搞二进制协议在我做的caveman系列里最核心的一个选型原则是能用纯文本存储的工作负载绝不能去搞二进制协议或者数据库格式。为什么因为文本文件是人类可读的、人类可改的、人类可debug的。一个JSON文件坏了你打开一眼就能看出来哪里写错了一个SQLite文件坏了你得装数据库工具、写SQL去查。二进制格式天然带一层黑盒属性这对排障是巨大的障碍。以配置管理为例。我不写YAML不写TOML就用JSON。因为Python标准库直接支持json不需要引入任何解析器。配置文件的读取逻辑朴素到了极致import json with open(config.json, r, encodingutf-8) as f: config json.load(f) # 校验所需key是否存在 required_keys [host, port, token] for key in required_keys: if key not in config: raise SystemExit(f缺少必要配置: {key})就这么十几行代码把配置文件的读取和校验解决了。没有pydantic没有schema定义没有环境变量解析框架。环境变量当然会支持但直接用os.environ.get就行import os host os.environ.get(HOST, config.get(host, 127.0.0.1))这两种方式都保留在代码里想用哪个用哪个。为什么优先选环境变量兜底而不是框架里的配置优先级机制因为环境变量是操作系统提供的零依赖任何人在任何环境里都能设置它。这就是caveman风格的工具选型标准每一个组件都必须是操作系统自带能力或者是标准库里的小模块。2.3 文件即数据库用最笨的存储方式扛过最惨的情况“文件即数据库”这个思路听着很反智但实际做下来会发现很多应用场景根本不需要数据库。我做过一个内网统计工具每个月要把各服务器的磁盘用量汇总、告警。数据量一台机器一个月一行记录整个内网几百台机器一年也就几千行。这种数据量用MySQL就是在开玩笑。我用一个CSV文件存储每天追一行月末轮转归档加上一个简单的Python脚本做分析、告警。实现起来核心是追加写和锁import csv import os import fcntl REPORT_FILE usage.csv def append_record(record: dict): with open(REPORT_FILE, a, encodingutf-8) as f: fcntl.flock(f, fcntl.LOCK_EX) # 进程间锁防止并发写乱掉 writer csv.DictWriter(f, fieldnamesrecord.keys()) # 文件为空则先写表头 if os.path.getsize(REPORT_FILE) 0: writer.writeheader() writer.writerow(record) fcntl.flock(f, fcntl.LOCK_UN)你说这个方案有什么高级的吗完全没有。但它的优点是不需要装数据库服务、不需要做数据迁移、不需要担心连接泄漏。而且重启机器、升级系统、换服务器把CSV文件拷走就完事了。真正要应对的难点只有并发写而fcntl就够用了不需要引入任何中间件。对这个体量的场景来说这已经是最优解。当然文件即数据库是有边界的。当你的数据量超过几十万行、需要频繁随机查询、需要事务保障的时候就得升级到SQLite。我把SQLite当成文件存储的“加厚版”——它底层还是一个单文件但提供了索引、事务、标准SQL查询。哪怕到了这一步依然没有放弃“单文件即可迁移”的caveman优势。再往上走才是PostgreSQL、MySQL的领域。分清这个阶梯你就不会动不动上一套数据库全家桶了。3. 用原始方法论解决现代问题的三个实战案例3.1 案例一零依赖的实时日志监控只用标准库就能实现公司有个老系统日志全部打到本地文件里不接入ELK、不接云日志平台。运维想要实时监控报错怎么办以前的做法是装Filebeat配Elasticsearch搭Kibana等于为一袋垃圾配了一套垃圾分类处理厂。我用caveman思路写了一个大约150行的Python脚本专门tail指定日志文件用正则过滤ERROR、WARN级别内容命中后调用webhook发到指定的通知群。核心逻辑其实就是打开文件、跳到文件末尾、不断读取新行import time import re import urllib.request LOG_FILE /var/log/app/error.log PATTERN re.compile(rERROR|WARN|Exception|Traceback) def notify(message: str): data f{{text: {message}}}.encode() req urllib.request.Request( https://example.com/webhook, datadata, headers{Content-Type: application/json}, ) urllib.request.urlopen(req) def follow(filepath: str): with open(filepath, r, encodingutf-8, errorsignore) as f: f.seek(0, 2) # 跳到末尾相当于 tail -f 的起点 while True: line f.readline() if line: if PATTERN.search(line): notify(line) continue time.sleep(0.5) # 没有新行时休息避免空转 if __name__ __main__: follow(LOG_FILE)这段代码No三方依赖、No_consumer组、No_Kafka只是一个进程盯一个文件谁都能看懂。上线三个月稳定得一批。唯一需要操心的就是进程守护用systemd配一个service文件就够了。这套方案的真实价值不在于技术含量而在于运维同学接手后能一眼看懂、敢改敢修——这比什么分布式日志链路都重要。3.2 案例二模拟并发压力的简易压测工具拷打自己写得最土的接口另一个例子是压测工具。你总不能让团队每个人都装JMeter或者熟悉wrk然后为了压测一个内部接口先去学一堆配置语法。caveman做法是写一个多线程脚本直接怼用标准库的threading和time就够了。import threading import time import urllib.request URL http://localhost:8080/api/test TOTAL_REQUESTS 1000 CONCURRENCY 20 errors 0 completed 0 lock threading.Lock() def worker(): global errors, completed while True: with lock: if completed TOTAL_REQUESTS: return completed 1 try: start time.time() urllib.request.urlopen(URL, timeout5) elapsed time.time() - start except Exception: with lock: errors 1 threads [] for _ in range(CONCURRENCY): t threading.Thread(targetworker) t.start() threads.append(t) for t in threads: t.join() print(f请求总数: {completed}, 失败数: {errors}, 成功率: {100 * (completed - errors) / completed:.2f}%)虽然Python的GIL导致线程并发度没那么猛但对于压测一个只做数据库查询的小接口几十并发完全够揭示问题了。真要测高并发强性能那是专门的压测平台该干的活这脚本的目标就是“快速判断自己的接口是不是shi”。一套JMeter环境加学习成本至少要半天这个脚本五分钟就能写出来还能按需改参数。这就是caveman方法在“够用”和“好用”之间做的精准取舍。3.3 案例三内网文件分发与定时同步rsync加bash脚本搞定很多团队做文件同步第一时间想到搭NFS、搭Ceph、搭对象存储网关结果是引入了一堆需要专职运维伺候的组件。但如果你只在几十台Linux服务器之间同步几个目录rsync就是那个被称为“caveman友好”的原始但强大的工具。它不需要任何守护进程除非要用daemon模式一条命令从源机器推到目标机器增量同步SSH加密。我的做法是写个bash脚本放到cron里每天跑#!/bin/bash # 文件同步脚本——不需要额外安装任何服务端 SYNC_SRC/data/shared/ SYNC_DSTusertarget-server:/data/shared/ LOG_FILE/var/log/file-sync.log # rsync 关键参数: -a 归档模式保留权限/时间戳, -z 压缩, --delete 删除源端不存在的文件 rsync -az --delete -e ssh -o ConnectTimeout10 -o StrictHostKeyCheckingno \ $SYNC_SRC $SYNC_DST $LOG_FILE 21 if [ $? -eq 0 ]; then echo [$(date)] 同步成功 $LOG_FILE else echo [$(date)] 同步失败请检查 $LOG_FILE exit 1 fi这里唯一依赖的就是系统自带的rsync和ssh这两样在绝大多数Linux服务器上都是预装的。你不需要在每台目标机上装agent不需要注册中心不需要任务调度平台。cron本身就是那个最古老、最可靠的任务调度器。很多人嫌cron精度只有分钟级于是去换XXL-Job、换Airflow。但你真有一个精确到秒的定时任务吗多数情况下没有。cron的分钟级精度对文件同步、备份、报表生成这类负载已经绰绰有余而且因为它长在操作系统里没有额外进程要照顾稳定性反而最高。4. 踩坑实录极简方案在真实环境中翻车的三个瞬间4.1 共享文件夹写入遇坑fcntl锁只在Unix下有效换到Windows就失效我以为文件锁这种东西是“写到哪都能跑”直到有一次把脚本移植到Windows服务器上才发现fcntl这个模块压根不存在。脚本在Linux上运行得好好的到了Windows直接ImportError。这是我吃过的第一个“标准库不等于跨平台库”的亏。排查过程其实很简单看到报错信息提示是fcntl找不到第一反应就是去Python文档里查这个模块的平台支持范围一查明明白白写着“Unix only”。解决方案有两个方向一是用跨平台的锁库比如portalocker但这就违背了零依赖原则二是针对Windows环境改写实现Windows下可以用msvcrt模块的locking函数来做类似的锁。import os import sys if sys.platform.startswith(win): import msvcrt def lock_file(f): f.seek(0) msvcrt.locking(f.fileno(), msvcrt.LK_LOCK, 1) def unlock_file(f): f.seek(0) msvcrt.locking(f.fileno(), msvcrt.LK_UNLCK, 1) else: import fcntl def lock_file(f): fcntl.flock(f, fcntl.LOCK_EX) def unlock_file(f): fcntl.flock(f, fcntl.LOCK_UN)这段代码花了半小时搞定但没有这个经历的话谁会意识到文件锁还会分平台这也验证了caveman方法论的另一个原则“零依赖”不等于“零平台差异”写任何存储层逻辑都要先问清楚自己跑在哪个系统上。踩过这次坑之后我把所有文件操作都封装成了独立模块平台差异集中处理业务代码里再不管这些破事。4.2 tail日志丢行事故f.seek到结尾的时机不对程序刚启动就漏过关键日志日志监控脚本上线后的第二天运维反馈说凌晨三点有一条致命错误日志没被通知到而脚本之前明明一直跑得好好的。排查下来发现了一个极其隐蔽的坑脚本是用systemd重启过的而重启时间正好在日志产生的前几秒。脚本一启动就执行f.seek(0, 2)直接跳到文件末尾此时文件末尾是“重启前”的位置但之间新写入的几行日志已经推进了文件指针结果这几行新日志就永远错过了。这个问题的根因在于“启动即跳尾”的设计假设——它假设脚本启动时日志文件是静止的但真实世界文件一直在动。修复方式不是消除这个竞争条件那几乎不可能而是加一个“冷却期”启动时不立刻跳尾先从文件开头读几秒、然后休眠、再跳尾留出缓冲窗口避免丢数据。def follow_safe(filepath: str, startup_grace: int 3): with open(filepath, r, encodingutf-8, errorsignore) as f: # 启动冷却期先从头读把启动前已有的日志刷掉 end_time time.time() startup_grace while time.time() end_time: line f.readline() if line: handle(line) else: time.sleep(0.1) # 冷却期结束后再跳到当前位置开始跟踪 f.seek(0, 2) while True: line f.readline() if line: handle(line) continue time.sleep(0.5)这个冷却窗口无法百分之百保证不丢数据如果日志在启动瞬间和冷却期之间被写入了但实际运行中冷却期内脚本已经在持续消费日志文件服务重启间隙产生的日志量远小于冷却期能读出的量因此这条修复足够务实。这件事让我意识到任何看似简单的tail操作背后都有一个“读取起点”的哲学问题——你到底从哪一行开始算新日志——不搞清楚这个定义后续全是bug。4.3 CSV并发写锁粒度翻车锁的是文件而不是文件内容多进程写完互相覆盖做文件即数据库的时候我在同一台机器上跑两个实例来分担任务结果发现CSV文件里的记录偶尔会丢失或者出现行错位。代码里明明加了fcntl.flock为什么还会出事查了半天发现问题出在锁的粒度上我是先把文件打开、用flock加锁但加锁之前文件已经被另一个进程打开并且写入了内容。两个进程各自持有一份文件描述符锁虽然会阻塞第二个进程的写入但第一个进程写入的内容未必已经刷到磁盘——换句话说锁保护了“写文件”这个过程却没有保护“读取旧状态”这个过程。这个问题的经典之处在于你以为锁住的是数据其实锁住的是一段代码执行区间。修复方式是调整顺序把锁和读改写全部放到同一个临界区里def append_record_safe(record: dict): with open(REPORT_FILE, a, encodingutf-8) as f: fcntl.flock(f, fcntl.LOCK_EX) f.seek(0) content f.read() # 基于最新的文件内容判断是否需要写表头 if content.strip() : f.write(,.join(record.keys()) \n) f.write(,.join(str(v) for v in record.values()) \n) f.flush() os.fsync(f.fileno()) # 确保落盘 fcntl.flock(f, fcntl.LOCK_UN)把“读旧状态”和“写新状态”放进同一个文件锁保护区间才真正做到了串行化。但这里有个心结a模式本身是追加写你怎么判断文件是否为空这就要先seek到文件头读内容但这样就破坏了追加语义。解决方式是改用r模式打开要求文件必须已存在不存在就先用open(..., w)创建。每次写入前都重新读一遍文件内容再追加虽然多了一次读I/O但对于小文件级别几MB以内完全不是问题。这一坑踩下来我对“文件即数据库”这句话的理解深了一整层文件系统提供的原子性、锁、可靠落盘每一个都和真正的数据库系统有微妙差异。你要么彻底接受这些差异要么就别用文件当数据库。caveman不是让你忽略风险而是让你在明白风险的前提下选择最简单的路径。5. 什么时候不该学穴居人极简主义的边界与灰度判断5.1 性能临界点文件存储和同步方案在数据量面前会迅速崩塌我也不是脑残粉不会在所有场景里强行caveman。需要认真说清楚的是极简方案是有明确的适用边界的。第一个边界就是数据量。文件即数据库的路数在数据量几百MB、操作频率每秒几十次的时候毫无问题但一旦到几GB以上、每秒上千次读写文件系统那套就顶不住了。不管是锁的争用、磁盘I/O还是随机查询的性能都会让你痛不欲生。这时候必须老老实实上真正的数据库——MySQL、PostgreSQL任选别硬扛。第二个边界是多人协作和强一致。文件同步方案适合“最多几十台机器、出错也无大碍”的场景但如果你在做的是交易系统、订单系统、库存系统数据错一条都是大事这时候就绝对不能靠rsync和CSV。数据库的事务、回滚、审计、权限每一个功能都是你用得上的拐杖。caveman的哲学在“低风险工具”里闪闪发光但它扛不住“高风险业务”的重量。判断阈值其实很简单当我发现我需要“锁”“事务”“回滚”“并发安全”这些词的时候就该立刻升级到专业组件了。严格地说上面的CSV并发修复已经是在用一种拧巴的方式模拟数据库能力拧巴到了某种程度就不能继续拧巴下去。5.2 团队协作与可维护性极简到只有自己看得懂也就变成了坑另一个边界是团队协作。我写过很多caveman风格脚本它们零依赖、能跑、稳定但最大的问题来了换一个人来看未必看得懂。因为这种代码往往利用了大量的系统底层机制、平台特性、编程语言的奇技淫巧代码量少了但理解成本并没有同比下降。我踩过的这个坑是离职交接后接手的人看到一段用sys.platform判断平台、再用msvcrt加锁的代码直接懵了。不是说这段代码不好——它非常好对极简主义来说简直是艺术品——但它相当于把一整套本该由数据库提供的保证手工实现了一遍而实现细节只有写它的人最清楚。这就违背了最初“人人可维护”的初衷。所以现在的caveman实践里我会为每一段“不那么显然”的代码写一个注释块解释清楚“为什么不用现成的库”“为什么是这个方案”“在什么条件下这个方案会失效”。这是极简主义必须支付的额外税——它省了外部依赖就必须多花在文档和理解上。有一个很有效的判断方法写完后把代码给一个水平和你差不多的朋友看如果他需要超过五分钟才能理解你为什么要这么写这代码就不够caveman——它不是简单是简陋。真正的简约应该让复杂的事物变得显然而不是把复杂藏在巧妙里。5.3 什么时候我依然会掏出现代工具链讲了半天caveman的好处也得聊清楚我什么时候会坚决放弃极简路线。第一个场景是数据管道和实时流处理。如果业务场景确实需要处理每秒几十万条事件、跨多个数据源做关联那么Kafka、Flink、Spark Streaming这些重武器就是对的选项caveman在这里一秒钟都活不下去——它的“简单”会变成“脆弱”。第二个场景是环境隔离与交付。当项目需要交付给客户、需要在不同操作系统上跑、需要在不保证有系统包管理器的环境里部署时Docker容器就不可或缺。我曾经硬着头皮让客户在自己的机器上手动装Python和依赖结果omg对方完全不会。后来老老实实写了Dockerfile。这不是背离caveman而是caveman理念在新环境下的正确延伸——把整个运行环境当作一个单一文件打包让部署变成“拉镜像加跑容器”两个动作这反而更符合“依赖最少化”的精神。第三个场景是复杂权限与审计。涉及合规需求的项目比如财务系统、医疗系统必须记录谁在什么时候改了什么数据。这些场景下操作系统级别的文件权限、访问日志都不够用需要专业的权限模型和审计日志。在这个赛道上自研的土办法永远追不上成熟系统的安全承诺。认清这一点很重要因为我见过太多人为了贯彻极简主义硬是把安全审计这块搞出漏洞反而更危险。6. 基于caveman理念的实操建议与进阶思路6.1 从一个“能跑”的脚本开始别让“完美架构”吓退你很多找我聊过项目的朋友都会陷入一个怪圈脑子里是几个近乎完美的架构手上却一行代码都没写。这件事在caveman理念下的解法特别简单先写一个能跑的脚本哪怕它只有三十行哪怕它没有异常处理、没有配置化只要它解决了眼前的问题这个系统就有了活的起点。之后再按需求增长逐步改造而不需要一步到位。我通常是这么开始的先写下这个程序最核心的三个动作是什么然后直接用Python一行行撸过程中不引入任何外部库。跑通了以后问自己三个问题——还是要让别人用还是需要配置化还是需要跨机器同步只有当某个问题的答案变成“是”才引入新的复杂度。这其实就是所谓“必要的复杂度”和“炫技的复杂度”的区分法。6.2 给caveman代码做“可拾起性”让未来的你和其他人快速接手正如前面说的极简代码最大隐患是只有写的人能看懂。我有一套自检清单每次写完都过一遍每个非标准用法有没有注释比如fcntl、msvcrt、f.seek(0, 2)这种不注释就是在埋雷。有没有一个文件说明“这个项目为什么存在”以及“它和正式系统的边界是什么”有时一句话就够但这句至关重要。有没有把“假设条件”写清楚比如“本脚本只支持一台机器”“本脚本在数据量超过XXX万行时需替换为数据库”“本脚本使用cron调用不接受外部触发”。这些边界如果不写改的人会在毫不知情的情况下跨过雷区。错误信息是否包含足够的上下文比如报错要带上文件名行号当前变量值而不是一个裸的Exception。在我实践了这套清单之后那些caveman脚本的交接成本大幅降低。新接手的人不再需要靠猜来理解代码里的巧妙设计而是直接读注释就能上手。这在某种意义上又让“简单”回归了它本来的意义——简单必须意味着容易理解否则就是伪简单。6.3 下一个可尝试的进阶方向把单一脚本演化为可插拔模块集当你把几个caveman脚本稳定跑起来后你会发现它们之间的逻辑可以抽取成公共模块慢慢就形成了一套轻量级的“工具包”。这不是让你搞微服务化、搞插件框架而仅仅是把重复出现的功能收拢到一起文件锁模块、日志tail模块、CSV读写模块、Webhook通知模块。每个模块保持短时间内能读完的体量模块之间用Python标准库的import机制连接不用DI容器、不用事件总线。这套东西在工程上有一个好处每个模块都可以单独被测试、被替换。某一天你想把Webhook通知从标准库urllib换成requests只需要改一个函数就行。这种“模块之间用最简陋的接口协作”的代码风格比什么整洁架构都更容易让新人上手因为你不需要理解任何魔法每一条数据流都在你眼皮底下流动。另外我建议在这个阶段给所有模块配上小而完整的自测脚本。caveman不代表不测试。恰恰因为模块少、依赖少写单元测试可以做到极高覆盖率。比如文件锁模块可以测并发写入不丢数据日志tail模块可以模拟文件追加来验证不丢行。有了测试兜底极简主义的信心才立得住否则往后改的时候会心虚。我个人在实际操作中的深刻体会是越是被各种框架和平台宠坏的开发者越容易低估手动掌控底层细节的价值。caveman并不拒绝现代工程实践它只要求每一样技术都经过“必须性检验”——如果你的问题域用不到它就坦率地把它放下哪怕是时下最炙手可热的新框架。坚持这样做下来我的系统变得越来越轻出问题越来越容易排查调试一个脚本往往打开浏览器看看输出日志就足够了再也不用钻进层层叠叠的容器和调用链里去大海捞针。最后再分享一个小技巧遇到棘手问题的时候花几分钟把系统里所有非必要依赖列一张清单逐个问自己“如果现在就删掉它会怎么样”大多数答案都是“其实也没怎么样”。这张清单往往就是你回归caveman的第一张去重表它帮我砍掉过不少自我感觉良好却始终没派上用场的组件。