从标题拿到“caveman”这个单词的时候我脑子里先冒出来的画面是《摩登原始人》里 Fred Flintstone 踩油门那一下——轮子直接靠脚蹬。后来转念一想放在技术圈里“caveman”更像是一种态度不堆砌复杂工具坚持用最原始、最简单、但足够坚硬的方式解决问题。我最近就在折腾一个叫“caveman”的个人项目。听着像是复古行为艺术其实它是一套极简风格的本地工具集用纯 Shell 脚本加少量原生命令搞定日常的文件备份、日志整理、环境初始化这些破事全程不依赖重型框架不引入几十个依赖包也不碰云端服务。整套体系的核心诉求就一条在机器上能用十年不坏换电脑五分钟恢复战斗力。这篇博文我会从为什么会有这个项目、整体设计思路、核心脚本怎么写、踩过哪些坑到怎么把它扩展成一套个人工作流全部摊开讲清楚。如果你也在被各种框架、容器、编排工具折腾得头晕想找一个更“原始但稳”的路径这篇文章应该能给你一点启发。1. 内容整体设计与思路拆解1.1 核心需求把“简单”当作一辈子的课题先说说我为什么会动这个念头。前几年我给自己的工作电脑搭了一整套开发环境Docker 容器、Kubernetes 本地集群、Ansible 配置管理、Terraform 基础设施……工具越装越多光配置文件就有几百个。刚开始觉得很爽处处都是“自动化”后来发现每次升级系统、换一台电脑光恢复环境就要折腾一整天。更麻烦的是很多工具之间互相咬合得特别深某个依赖库升个版本整个编排流程就跟着崩。所以我给“caveman”定下的第一原则是能用三行脚本说清楚的事绝对不用三十个配置项去描述。这个项目不是一个开箱即用的框架也不是一套标准化的产品它更像一个武器库里面每一件工具都遵循同样的哲学单文件、无依赖、可读性优先。有人可能觉得这种思路是不是太“原始”了放在今天大家不都讲究云原生、声明式 API 吗我个人的体会是工具的价值在于完成你当下的目标而不是让你为工具本身打工。“caveman”这个项目做的第一个决定就是把所有花哨的东西砍掉只留下解决问题的最小路径。这不是反技术而是反“为了技术而技术”。1.2 方案选型为什么不用 Python、Ansible而用 Shell确定要做一个极简工具集之后第一个问题就是用什么语言来写我一开始确实考虑过 Python因为用它写脚本比较舒服效率也高。但仔细想想“caveman”的核心应用场景是全平台、零依赖、快速启动。如果我用 Python 写那目标机器上就必须有 Python 环境还得处理 Python 2/3 兼容、pip 依赖、虚拟环境这些事。这明显和“能跑十年”的理念有冲突。用 Shell 脚本就简单多了。macOS 自带 bash/zshWindows 上也有 Git Bash 或者 WSL几乎所有开发者的机器都能直接跑。而且 Shell 脚本本身就是系统命令的胶水语言它不需要额外安装任何运行时随便打开终端就能执行。更关键的一点是Shell 脚本是透明的打开文件就能看到每一行在做什么没有隐藏的抽象层。对“caveman”这个项目来说透明比强大重要得多。当然Shell 脚本有个短板处理复杂数据结构和并发任务比较吃力。我的解决方案很简单如果需要复杂逻辑就退回到 Python 写一个独立的小脚本然后由 Shell 负责整体调度和结果判断。这样既保持了外壳的简单又能在需要的时候借用更强的工具不会为了极简而刻意自残。2. 核心细节解析与实操要点2.1 目录结构一眼看穿所有文件的用途“caveman”的第一版目录结构非常直接当时我就是按照“把工具按功能分类”这个最朴素的思路来组织的。后来实际用了几个月发现有些脚本之间会相互调用但结构仍然保持清晰。现在的布局是这样caveman/ ├── bin/ │ ├── caveman-backup │ ├── caveman-log │ ├── caveman-init │ ├── caveman-tidy │ └── caveman-status ├── etc/ │ ├── aliases.sh │ └── config.sh ├── lib/ │ ├── common.sh │ └── logger.sh └── README.mdbin/下面放着所有可执行脚本整体设计遵循“单一职责原则”每个脚本只负责一个动作比如备份、清理日志、初始化环境。etc/里放的是配置和别名定义统一管理。lib/则是公共库包括日志输出、环境检测、路径计算这些会被重复用到的基础功能。这种结构的好处是你在任何一台新机器上 clone 下来打开 README 就能在五分钟内知道整个项目是干嘛的每个文件负责什么内容一目了然。不像有些工程化的项目光目录就有七层看一圈都不知道入口在哪。我觉得对个人项目来说目录结构最大的价值不是支撑什么复杂的架构而是减少自己下次维护时的认知负担。如果你自己也维护过项目一定深有体会三个月后回来看自己写的代码完全想不起来当初为什么这么设计。一个直观的目录结构能在一定程度上缓解这种尴尬。2.2 公共库设计日志、环境检测、辅助函数Shell 脚本里最容易被忽略、其实也最值得打磨的部分就是公共库。很多新手写 Shell 脚本往往是一个脚本从头写到尾需要输出提示时就 echo 一下遇到判断就 if 一下。这在小规模场景里没问题但脚本一多各种不一致的写法就会冒出来维护成本迅速上升。“caveman”在 lib/common.sh 里放了一个环境检测函数专门用来判断当前机器的操作系统、是否有某个命令、以及磁盘剩余空间。这是整套工具的基础因为所有脚本都需要知道自己运行在什么环境里才能决定后续怎么做。比如备份脚本在 macOS 和 Linux 上使用的命令细节不太一样提前做一次检测后面就能写出非常统一的逻辑。check_env() { if [ $(uname) Darwin ]; then OSmacos elif [ $(uname) Linux ]; then OSlinux else OSwindows fi if ! command -v $1 /dev/null 21; then echo [caveman] error: required command $1 not found 2 exit 1 fi }不要小看这个函数它解决的是依赖前置检查的问题。比如某些脚本一定要用到 rsync如果机器上没有这个命令与其等到脚本跑了一半才报错不如一开始就直接给出清晰的提示。lib/logger.sh 的作用更偏“体验”。它统一了日志输出格式用[caveman]前缀和不同的日志级别INFO/WARN/ERROR区分三个场景每次执行脚本的时候控制台输出都长一个样。别小看这个统一一旦你同时运行好几个任务一眼扫过去能分辨哪些步骤成功、哪些步骤失败效率会高不少。代码也很简单info() { echo [caveman] [INFO] $*; } warn() { echo [caveman] [WARN] $* 2; } error() { echo [caveman] [ERROR] $* 2; }2.3 关键脚本的功能边界与设计要点接下来逐个说说 bin/ 下这几个核心脚本的功能边界。caveman-backup是使用频率最高的一个它负责把指定的目录打包并复制到备份盘。设计上我不允许它做任何增量备份、版本管理、加密操作所有复杂需求都被砍掉只保留一条核心链路读取配置文件里的目录列表打包校验拷贝。这么做的原因很简单增量备份的逻辑容易出错一旦链路上哪个环节出问题你根本不知道最终备份是不是完整的。caveman-log的功能是整理日志文件。开发者的机器上通常堆满了各种临时日志有的甚至上百 MB。这个脚本做的事就是扫描指定目录把超过设定大小的日志文件压缩成.tar.gz并归档到 log 目录。它不是清理工具不会删除任何文件只是把“懒得多看一眼”的日志打包起来腾出空间。caveman-init是环境初始化脚本。我换了三次电脑之后发现每次重装系统最麻烦的其实不是装软件而是配置各种软链接、环境变量、SSH 配置、Git 全局配置。这个脚本就是把这些初始化工作固化成可重复执行的流程。它会在执行前自动检测哪些步骤已经完成做一个简单的幂等处理。caveman-tidy负责临时文件清扫caveman-status则是一个信息汇总面板显示当前关键目录的磁盘占用、备份时间戳、日志目录大小等。它们各自的职责都很单一但组合起来就能覆盖一个开发者最日常的维护需求。3. 实操过程与核心环节实现3.1 从零搭建 caveman 工具集逐步演示如果你也想搭一套类似的工具我可以把具体步骤拆开讲。这些步骤我实测过好几轮照着做基本不会卡住。第一步建立目录骨架。在终端里运行下面这条命令一次性创建所有目录mkdir -p caveman/{bin,etc,lib}第二步编写配置文件etc/config.sh。这个文件的作用是集中保存“哪些目录需要备份”、“日志目录在哪”、“备份盘路径是什么”。配置文件最大的价值在于你修改各种参数的时候不需要动脚本代码只改这一处就能全局生效。这样设计可能有点“原始”但确实很实用。# caveman config BACKUP_PATHS$HOME/Documents $HOME/Projects BACKUP_DEST/Volumes/BackupDisk/caveman-backup LOG_SOURCE$HOME/Library/Logs LOG_ARCHIVE$HOME/caveman-logs MAX_LOG_SIZE_MB5第三步把公共库lib/common.sh放进去。内容就是把上一节的环境检测函数搬进去再补一个load_config()函数load_config() { # shellcheck source../etc/config.sh source $(dirname $0)/../etc/config.sh }这里有一个新手特别容易踩的坑直接使用相对路径时如果从别的地方调用脚本路径就失效了。用$(dirname $0)先定位到脚本自身所在目录再往上找etc/config.sh这是一个比较稳的写法。第四步编写第一个脚本caveman-backup。初始版本可以很简单核心逻辑三步走加载配置、执行打包、复制到目标。#!/usr/bin/env bash set -euo pipefail source $(dirname $0)/../lib/common.sh load_config # 检查备份盘是否挂载 if [ ! -d $BACKUP_DEST ]; then error 备份盘未挂载: $BACKUP_DEST exit 1 fi STAMP$(date %Y%m%d-%H%M%S) TARBALL/tmp/caveman-backup-$STAMP.tar.gz # 打包所有需要备份的路径这里保持最简单 tar -czf $TARBALL $BACKUP_PATHS # 拷贝到备份盘并校验文件大小 cp $TARBALL $BACKUP_DEST/ info 备份完成: $BACKUP_DEST/$(basename $TARBALL)每一行代码我都可以解释清楚。第一行的#!/usr/bin/env bash确保脚本能找到正确的解释器。第二行的set -euo pipefail是很少在入门教程里出现、但极其关键的保命三件套有任何命令失败就直接退出、变量未定义就报错、管道命令中任意一环失败则整个管道判定失败。这个三件套可以保证你的脚本不会出错之后还在傻乎乎地往下跑。3.2 标杆案例如何用 caveman-backup 设计一套完整备份链路这个备份脚本看着简单但实际封装时需要的细节不止上面那几行。我分享一下在真实环境下使用的版本# 检查备份盘空间 AVAIL$(df -k $BACKUP_DEST | awk NR2 {print $4}) SIZE$(du -sk $TARBALL | awk {print $1}) if [ $SIZE -gt $AVAIL ]; then error 备份空间不足: 需要 ${SIZE}KB, 可用 ${AVAIL}KB exit 1 fi # 写入备份清单方便追溯 echo $(date) - $STAMP - $(hostname) - $BACKUP_PATHS $BACKUP_DEST/backup-log.txt为什么要加备份空间校验因为我遇到过备份盘快满了cp 命令跑了一半报错结果留下一个残缺的压缩包下次备份时新旧文件混在一起非常狼狈。提前做校验虽然只是几行代码但能避免一个特别灾难性的场景。还有一点默认的 tar 命令不会保留文件权限和扩展属性对开发者来说这可能意味着某些配置文件丢失了可执行权限。要保留权限需要加--preserve-permissions参数tar --preserve-permissions -czf $TARBALL $BACKUP_PATHS3.3 日志整理脚本与状态面板实用到不想再碰命令行外的工具写一手漂亮的日志整理脚本后你会有种“再也不用碰那些笨重的图形化磁盘清理工具”的感觉。caveman-log的整体思路很简单遍历日志目录里的文件找出体积超标的那几个压缩并挪走。让我把完整的实现思路写下来check_size() { local file$1 local size size$(du -m $file | cut -f1) if [ $size -gt $MAX_LOG_SIZE_MB ]; then gzip -c $file $LOG_ARCHIVE/$(basename $file).$(date %Y%m%d).gz truncate -s 0 $file info 已归档并清空: $(basename $file) fi }注意我用的是truncate -s 0而不是rm因为日志文件通常被后台进程占用直接删除可能会造成写入冲突而且会让某些进程一直持有已删除的句柄。清空而不是删除是处理活跃日志文件的常见做法这也是一个从实际运维场景中沉淀下来的细节。状态面板caveman-status更适合做成一个“快速巡检”工具它把备份目录大小、日志目录占用、备份时间戳这些信息一次性列出来。它不解决具体问题但能帮你早上坐下来的时候用一分钟快速判断“机器状态健不健康”。这件事看起来小体验提升却非常明显。4. 常见问题与排查技巧实录4.1 典型问题速查表破案思路要清晰这里把我在开发和使用“caveman”过程中实际遇到过的、具备代表性的问题整理成一张表。真实排错时这些条目可以帮你快速缩小范围。问题现象可能原因排查命令解决办法备份脚本报“备份盘未挂载”外置硬盘未连接df -h查看磁盘列表连接硬盘或修改BACKUP_DESTtar 打包时提示“file changed as we read it”被备份目录里有活跃文件检查是否有服务正在写入先停掉相关服务再备份脚本在 cron 中不执行PATH 环境变量不同找不到命令在脚本开头 echo$PATH脚本开头显式设置 PATHset -e下脚本意外退出grep 或 find 没有匹配到任何内容返回非零bash -x script.sh跟踪执行在需要的命令后加 备份文件损坏无法解压拷贝过程中磁盘空间不足检查backup-log.txt里的文件大小记录新增备份空间校验逻辑第一行“备份盘未挂载”是我遇到最多的情况。因为外置硬盘平时不一定接着而这个脚本设计上强制要求目标路径存在。后来我在脚本里加了一个更明确的提示直接把“插上硬盘再跑一次”这句话写进去省得每次都要自己猜。关于排错方法我想分享一个小技巧让脚本支持 verbose 模式。新手常犯的错误是脚本报错了就干瞪眼然后用 echo 到处插桩。更好的做法是在公共库里定义一个变量所有关键行动点都打日志然后在跑脚本的时候用bash -x观察发生了什么。bash -x是 Shell 脚本排查环境里最粗暴但也是最好用的工具它会显示每一行命令及其展开后的具体参数。4.2 避坑技巧让 Shell 脚本长期稳定运行的小细节除了上面的问题速查表再分享几条我自己用血泪总结出来的避坑心得。第一条永远使用绝对路径。Shell 编程里“当前目录”是一个随时可能变化的幽灵。脚本的pwd取决于你从哪里调用它。如果脚本里出现相对路径很可能十分钟前还能跑换个目录就彻底歇菜。我现在的习惯是所有脚本开头都会加上cd $(dirname $0)确保运行目录稳定在脚本所在位置。这个习惯帮我在无数次“换目录就崩溃”的窘境里捡回了尊严。第二条仔细处理文件名的空格。很多人觉得给文件名加引号是特别啰嗦的事直到他们遇到了一个叫做My Project Final(1).tar.gz的文件然后被莫名的报错折磨半天。Shell 脚本中只要涉及变量展开就一律用双引号包裹这是一个可以刻进肌肉记忆的习惯。养成这个习惯之后那些因为空格捣的乱纷纷消退。第三条对set -e有敬畏之心。前面强调set -e很重要但它有时候也会成为隐患。比如一个循环里某个文件不存在导致rm或ls返回非零状态整个脚本会立刻退出。这在批处理场景下尤其麻烦你永远不知道半路掉链子的原因是什么。应对方案是关键位置使用条件表达式而不是裸命令或者加|| true明确告诉脚本“这里失败也没关系继续往下走”。这种做法让脚本的行为变得可以预测。4.3 平滑扩展给“原始工具”增加高级能力“caveman”虽然以简单为出发点但使用一段时间后你会发现它也能平滑地混合进一些更进阶的能力不必引入重型框架。最典型的一个扩展是接入定时执行。macOS 的launchd或者 Linux 的cron都能在很底层的位置运行 Shell 脚本。我当时用一条纯粹的脚本实现了“每天凌晨 2 点自动备份”30 2 * * * /Users/me/caveman/bin/caveman-backup /tmp/caveman-cron.log 21这一条 cron 记录背后的逻辑是把日志重定向到文件里方便后续排查。如果你打算把“caveman”的脚本纳入定时任务务必注意 cron 环境里的 PATH 变量。我踩过的坑是在终端手动执行一切正常一交给 cron 就报找不到 rsync最后发现是 PATH 不同所致。解决办法是在脚本开头处强制设置export PATH/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:$PATH另一个值得推荐的扩展是把它接入 Git 管理的 dotfiles 仓库。这意味着你可以在任何一台新电脑上一条命令拉下所有配置并用“caveman-init”完成软链接。我已经这么用了几个月效果很棒。有人可能会想“这些功能是不是交给专门的 dotfiles 管理工具更合适”但在我看来自己写逻辑能精确控制每个步骤的执行方式也让整个过程随时可以被打开看一眼这种掌控感在使用“caveman”的过程里会持续拉满。5. 写在最后一点真实感受我一开始做“caveman”的动机是对日益膨胀的开发工具体系产生了对抗情绪。但做完之后再回头看我发现它带给我的东西远不止“一套方便的小脚本”更是一种工作习惯的重塑每次遇到新问题我的第一反应已经不再是“找找看有没有一个现成工具”而是“这问题到底能不能用三行代码解决”。如果你正在被各种复杂工具折磨或者总是觉得自己的开发环境重得跑不动我特别建议你试着做一套自己的“caveman”——不需要叫这个名字也不一定全是 Shell 脚本。关键是牢牢守住那条底线任何一个工具如果它的维护成本已经超过它帮你省下的力气那它就该被砍掉不用犹豫。最后再分享一个小技巧给每个脚本都画一个“十行版本”的草稿。如果一件事无法用十行描述清楚说明你的思路还需要再梳理。“caveman”这个名字看着像调侃背后的原则却是真的很严肃的复杂会生长简单需要时刻捍卫。