折腾过Hugo、Hexo、Jekyll的人大概都经历过一种微妙的不满足功能是够多了但一个node_modules动辄几百兆、一个二进制几十MB总让人觉得哪里不对劲。我这两年一直在找返祖一点的工具最后留在身边的是一个叫caveman的极简静态网站生成器。它用C语言写的编译出来就一个几十KB的可执行文件没有任何运行时依赖连模板系统都是靠Makefile硬凑出来的。听起来很野蛮但用顺手之后你会发现这种原始反而是一种难得的清醒。这篇文章就把我完整的使用过程写出来。从为什么选它、怎么装、怎么写文章、怎么部署到实际踩过的坑一次性讲透。如果你也是个受够了复杂工具链的人想把博客或者文档站重新拽回自己手里或者单纯想看看一个真正极简的站点生成器长什么样这篇文章应该能帮到你。1. 在2025年为什么我反而回头用原始人工具1.1 caveman到底是什么一句话版本caveman是一个静态网站生成器。它读入你写好的Markdown文件套上HTML模板在public目录里吐出一堆可以直接扔到Nginx上的静态页面。和Hugo、Jekyll那类大而全的生成器相比caveman最大的区别是薄。它没有插件生态没有主题市场甚至没有完整的模板语言。它的核心逻辑就是遍历源文件→用内置的极简Markdown解析器转HTML→按占位符塞进HTML骨架里→完事。我第一次跑通它的时候编译加建站整个过程不到一分钟。一个博客生成器居然可以用make干净地装上这种体验在今天几乎算得上奢侈了。1.2 为什么是C语言为什么是Makefilecaveman选择C语言和Makefile不是偶然而是刻意的返璞归真。C语言保证了它没有任何运行时依赖——不需要Node.js不需要Ruby不需要JVM。Makefile则把构建站点这件事重新定义为构建项目你写文章、生成页面、清理输出本质上都是在跑一个最普通的构建流程。这套设计的直接好处是你能看懂它的一切。不夸张地说一个基础的C语言阅读者花一个晚上就能把它的源码从头到尾捋一遍。这种情况在小而美的开源项目里越来越稀缺了。1.3 几款主流静态站点生成器的对比我把常用方案做了一张粗略的对比表数据来自我自己的实际使用体验不一定绝对准确但方向上能说明问题工具依赖二进制/核心体积构建100篇文章耗时学习成本适合场景caveman仅C编译器Make约50KB亚秒级极低个人博客、文档站、极客玩具Hugo无但二进制约70MB70MB左右亚秒级中大规模内容站、企业站HexoNode.js数百个npm包node_modules数百MB数秒到数十秒中高插件生态丰富的博客JekyllRuby环境依赖多数秒中GitHub Pages默认方案从这张表能看出来caveman的性能和体量优势其实不是最重要的。真正让我留下来的是它那种一切都在掌控中的安全感。2. 从安装到建站三个命令和一个目录结构2.1 编译安装标准C项目三连caveman的安装过程是我见过最省心的之一。前提条件只有两个一个能用的C编译器gcc或clang都行一个GNU make。Debian/Ubuntu上装好build-essentialmacOS上装好Command Line Tools然后执行git clone https://gitlab.com/cavemandotorg/caveman.git cd caveman make sudo make install装完之后你会在系统里多一个caveman命令。注意一下它不是常驻服务不是守护进程就是一把瑞士军刀式的小工具随用随走。2.2 工程目录比想象中还简单我建站时用的目录结构是这样约定的my-blog/ ├── Makefile # 站点构建脚本也是模板拼接的入口 ├── config.mk # 站点标题、作者、URL等元信息 ├── src/ # 所有Markdown源文件 ├── layout/ # HTML模板骨架 └── public/ # 生成的静态站点部署时直接传这个目录src里放文章layout里放模板public是产物。没有奇怪的隐藏文件夹没有几十层的目录嵌套。你第一次打开这个项目时五分钟就能搞清楚每个文件是干什么的。我一开始犯过一个错误把public也当成普通目录往里手动塞了一些图片和CSS结果下次构建时被清掉了。后来学乖了静态资源要么放在src同级的assets目录里并在构建时拷贝要么就明确约定public是不允许手动改动的生成目录。2.3 文章书写最简单的元信息约定caveman对文章元信息的处理非常原生态。不需要Jekyll那种复杂的Front Matter我通常直接在Markdown文件的第一行写# 标题然后依赖文件名里的日期来排序归档。一个标准文章文件长这样# 用caveman建站的三个月 正文内容从这里开始…… ## 第一个小节 这里是正文……文件名我习惯于用2025-06-01-hello-caveman.md这种格式。文件名里的日期既能用来排序又能在生成归档页时被脚本提取一举两得。这种约定虽然原始但好处是任何文本编辑器都能打开就写不用记一堆参数有没有拼错。2.4 模板骨架把{占位符}换成真内容caveman的模板走的是最朴素的替换路线。你在layout目录下放一个HTML骨架里面填上{TITLE}、{CONTENT}之类的占位符构建时它会把真实内容替换进去。我的一个极简模板大概长这样!DOCTYPE html html langzh-CN head meta charsetutf-8 title{TITLE}/title /head body header h1{TITLE}/h1 /header main {CONTENT} /main /body /html如果你懂一点点Makefile就能把所有页面的公共框架抽出来再按需拼接。它没有现代模板引擎那些继承、嵌套、过滤器的概念但反过来想哪一页长什么样你心里一清二楚。3. 实操过程我真的用它把博客跑起来了3.1 从零初始化一个站点如果你想直接上手最快的方式是新建一个目录手动创建上面那套结构。没有初始化的交互式命令没有caveman new之类的脚手架——至少我用的时候没有。这种不提供脚手架的设计反而让我养成了好习惯所有东西都自己搭也就不会出现项目能跑但不知道怎么回事的情况。我的Makefile里有一段核心构建逻辑PAGES : $(wildcard src/*.md) HTML_FILES : $(PAGES:.md.html) all: $(HTML_FILES) echo Build complete.逻辑很简单找到src下所有.md文件把它们逐个替换成对应的.html然后交给caveman去渲染。这段配置差不多是我从官方示例抄过来改动最小的部分。3.2 构建与本地预览感受一下亚秒级一切就绪之后直接运行make你会看到类似src/hello.md - public/hello.html这样的输出。由于每个文件都是独立处理的构建速度非常快。我往src里塞了大概两百篇文章整个构建过程依然在1秒内完成。这个成绩在今天的静态生成器里不算出奇但考虑到它只有几十KB还是让人挺感慨。本地预览我习惯用Python自带的HTTP服务器cd public python3 -m http.server 8080然后打开浏览器访问http://localhost:8080。这里有个小细节千万别用file://协议直接双击打开HTML因为caveman生成的是相对路径链接有些资源跨目录可能加载不出来。3.3 部署两种最顺手的姿势静态站点的部署没什么玄学主要就是把public目录原封不动传到某个地方。姿势一自己的服务器Nginx我最常做的还是用rsync推到VPS上rsync -avz --delete public/ userserver:/var/www/myblog/--delete参数保证服务器上不会残留旧文件。然后在Nginx里指一下站点根目录一个博客就算上线了。姿势二GitHub Pages不想碰服务器的话可以把public目录push到GitHub Pages分支。我个人的做法是建一个gh-pages分支把public里的内容放进去。这样每次make之后一条脚本就能完成提交和推送。对caveman这种简单工具来说功能完全够用。3.4 一次真实构建的记录为了给读者一个更直观的感受我贴一段当时构建时终端的输出大概形式是这样具体时间数字会因为机器不同有波动$ make cc -O2 -o build/caveman src/caveman.c src/2025-06-01-hello.md - public/2025-06-01-hello.html src/2025-06-05-second.md - public/2025-06-05-second.html ... Build complete.从输出能看到真正做事的还是底层的C程序Makefile只是把流程串起来。这种每个环节都看得见的体验对我这种喜欢刨根问底的人来说实在是一种享受。4. 常见问题与排查技巧实录4.1 中文乱码全都是编码的锅这是新手最容易撞上的坑。caveman内部对字符串的处理很透明如果你的文件是带BOM的UTF-8或者系统locale不是UTF-8生成的页面就可能出现乱码。我的排查路径分三步第一步确认所有Markdown文件都是UTF-8无BOM。在Linux下可以用file src/*.md快速查看。第二步确认HTML模板里的meta charsetutf-8没有写错。第三步如果还是乱码检查一下运行make时终端的环境变量LANG确保它是zh_CN.UTF-8或C.UTF-8。4.2 模板占位符不生效空格是隐形杀手我踩过一次特别蠢的坑。在layout里把占位符写成了{ TITLE }多加了空格结果页面标题死活不替换。查了半天源码才反应过来占位符内部不能有空格{TITLE}和{ TITLE }是两回事。4.3 Markdown解析的边界别拿它当全功能解析器caveman内置的Markdown解析器非常轻支持标题、粗体、斜体、链接、列表这些常用语法但遇到更复杂的嵌套时可能会犯迷糊。比如行内代码里出现**它可能还是会当成加粗渲染。我的应对方案是在文章里尽量少用复杂嵌套真遇到了就改用HTML实体或者直接手写HTML标签。反正Markdown本来就允许内嵌HTML这是最保险的处理方式。4.4 发布路径错误子目录部署的注意点如果你不是部署在域名根路径而是放在https://example.com/blog/这样的子路径下那所有的内部链接都要加上前缀。我在部署到服务器子目录时就因为忘了检查模板里的相对路径导致CSS文件全部404。解决方法是模板里的样式和脚本引用全部用相对路径并且保证生成的HTML和前两者在同一个层级或者干脆把站点部署在根路径下省心。4.5 问题速查表现象可能原因解决办法中文乱码文件带BOM或locale不对转UTF-8无BOM设LANGC.UTF-8标题不替换占位符写了空格确保{TITLE}无空格代码块渲染异常极简解析器不支持复杂嵌套改用HTML标签或简化语法部署后JS/CSS 404子路径部署未处理相对路径修正模板中的资源引用public里的文件被清掉手动了生成目录把持久资源放assets并拷贝进去5. 进阶玩法让原始人工具也能干现代活5.1 分类与标签用脚本凑一个归档页caveman本身没有分类系统但这难不倒我。我的做法是文章文件名用统一前缀比如blog-category-slug.md然后写一个简单的shell脚本从文件名里提取分类名称批量生成归档列表页。刚开始我觉得这是缺功能就得自己补用久了反而发现这种自由度比分类插件更符合自己的习惯。想按时间归档就按文件名里的日期想按分类归档就改一下脚本里的分隔符规则15分钟改完完全可控。5.2 生成RSS Feed给没有RSS的极简生成器加Feed也不算难。只要在Makefile里加一个目标让它遍历所有页面抽出标题、链接和正文前N个字符拼成一个XML文件就行。我这里没有贴完整代码但思路和写归档脚本一模一样把渲染页面和生成元数据拆成两件事前者交给caveman后者交给shell脚本。各司其职互不干扰。5.3 自动发布inotifywait rsync本地改完文章想自动同步到服务器可以用inotifywait监听src目录的变化一旦有.md文件变动就触发make然后rsync到服务器。while inotifywait -r -e modify,create,delete src/; do make rsync -avz --delete public/ userserver:/var/www/myblog/ done用的时候记得加一个冷却时间控制防止你连续保存时触发太多次同步。我实际跑下来这个方案的延迟基本就是rsync传输的那几秒。5.4 源码阅读最好的C语言教材如果你想深入学习C语言我特别推荐读一遍caveman的源码。它的Markdown解析器部分是很好的手写解析器入门素材代码量不大但逻辑完整。读完之后你再去看那些复杂框架的实现接受度会高很多。我读源码时最享受的一点是每一个函数你都知道它被谁调用为什么存在。没有像某些大型项目那样几十层的抽象整个程序就是一条清晰的主线。这种纯粹的工程快感在今天的开源世界里已经不多见了。6. 从工具到理念caveman的另一种精神6.1 caveman debugging不用调试器的原始排错法多说一句caveman衍生出的概念——caveman debugging。它指的是不用断点、不用DEBUG工具全靠printf打日志、靠二分注释代码来排错。这种原始排错方式在多线程问题、线上偶发bug、性能瓶颈排查时反而比IDE里的交互式调试器更有效。这和caveman这个工具给我的感觉是一致的先把复杂的壳剥掉回到最本质的因果关系上去。当你删掉所有干扰项问题往往就自己浮出来了。6.2 对现代开发者的启示少即是多用过caveman之后我对多和少有了新的判断。今天很多工具的功能增长其实是在替用户做选择但也剥夺了用户理解底层的能力。caveman不是告诉你我有100种主题供你选择而是告诉你这就是HTML结构你想改哪里就改哪里。我不是说所有项目都应该返祖成C语言Makefile。这个时代选择Hugo、Hexo完全合理它们解决的是规模问题。但如果你想重新掌控自己的内容想找回构建的确定感那caveman这个级别的工具值得你体验一次。6.3 最后分享一个我自己留到现在的小技巧用caveman这种极简工具真正受益的是它逼我建立了内容即文件、文件即内容的习惯。我现在写博客草稿都用纯Markdown放在src里任何一台机器只要装了git和make就能完整复现整个站点。换电脑、迁移服务器成本低到忽略不计——这比任何云端编辑器都让我安心。在写这篇文章的时候我还顺手整理了一下旧机器上的站点脚本把归档页的生成规则从按月份改成了按分类整个过程重新编译加改动只花了一个下午。要在Hugo里改归档策略我大概得先翻半天主题文档。这种工具跟着人走而不是人跟着工具走的感受就是我一直留着caveman不换的原因。
折腾过Hugo、Hexo、Jekyll的人大概都经历过一种微妙的不满足功能是够多了但一个node_modules动辄几百兆、一个二进制几十MB总让人觉得哪里不对劲。我这两年一直在找返祖一点的工具最后留在身边的是一个叫caveman的极简静态网站生成器。它用C语言写的编译出来就一个几十KB的可执行文件没有任何运行时依赖连模板系统都是靠Makefile硬凑出来的。听起来很野蛮但用顺手之后你会发现这种原始反而是一种难得的清醒。这篇文章就把我完整的使用过程写出来。从为什么选它、怎么装、怎么写文章、怎么部署到实际踩过的坑一次性讲透。如果你也是个受够了复杂工具链的人想把博客或者文档站重新拽回自己手里或者单纯想看看一个真正极简的站点生成器长什么样这篇文章应该能帮到你。1. 在2025年为什么我反而回头用原始人工具1.1 caveman到底是什么一句话版本caveman是一个静态网站生成器。它读入你写好的Markdown文件套上HTML模板在public目录里吐出一堆可以直接扔到Nginx上的静态页面。和Hugo、Jekyll那类大而全的生成器相比caveman最大的区别是薄。它没有插件生态没有主题市场甚至没有完整的模板语言。它的核心逻辑就是遍历源文件→用内置的极简Markdown解析器转HTML→按占位符塞进HTML骨架里→完事。我第一次跑通它的时候编译加建站整个过程不到一分钟。一个博客生成器居然可以用make干净地装上这种体验在今天几乎算得上奢侈了。1.2 为什么是C语言为什么是Makefilecaveman选择C语言和Makefile不是偶然而是刻意的返璞归真。C语言保证了它没有任何运行时依赖——不需要Node.js不需要Ruby不需要JVM。Makefile则把构建站点这件事重新定义为构建项目你写文章、生成页面、清理输出本质上都是在跑一个最普通的构建流程。这套设计的直接好处是你能看懂它的一切。不夸张地说一个基础的C语言阅读者花一个晚上就能把它的源码从头到尾捋一遍。这种情况在小而美的开源项目里越来越稀缺了。1.3 几款主流静态站点生成器的对比我把常用方案做了一张粗略的对比表数据来自我自己的实际使用体验不一定绝对准确但方向上能说明问题工具依赖二进制/核心体积构建100篇文章耗时学习成本适合场景caveman仅C编译器Make约50KB亚秒级极低个人博客、文档站、极客玩具Hugo无但二进制约70MB70MB左右亚秒级中大规模内容站、企业站HexoNode.js数百个npm包node_modules数百MB数秒到数十秒中高插件生态丰富的博客JekyllRuby环境依赖多数秒中GitHub Pages默认方案从这张表能看出来caveman的性能和体量优势其实不是最重要的。真正让我留下来的是它那种一切都在掌控中的安全感。2. 从安装到建站三个命令和一个目录结构2.1 编译安装标准C项目三连caveman的安装过程是我见过最省心的之一。前提条件只有两个一个能用的C编译器gcc或clang都行一个GNU make。Debian/Ubuntu上装好build-essentialmacOS上装好Command Line Tools然后执行git clone https://gitlab.com/cavemandotorg/caveman.git cd caveman make sudo make install装完之后你会在系统里多一个caveman命令。注意一下它不是常驻服务不是守护进程就是一把瑞士军刀式的小工具随用随走。2.2 工程目录比想象中还简单我建站时用的目录结构是这样约定的my-blog/ ├── Makefile # 站点构建脚本也是模板拼接的入口 ├── config.mk # 站点标题、作者、URL等元信息 ├── src/ # 所有Markdown源文件 ├── layout/ # HTML模板骨架 └── public/ # 生成的静态站点部署时直接传这个目录src里放文章layout里放模板public是产物。没有奇怪的隐藏文件夹没有几十层的目录嵌套。你第一次打开这个项目时五分钟就能搞清楚每个文件是干什么的。我一开始犯过一个错误把public也当成普通目录往里手动塞了一些图片和CSS结果下次构建时被清掉了。后来学乖了静态资源要么放在src同级的assets目录里并在构建时拷贝要么就明确约定public是不允许手动改动的生成目录。2.3 文章书写最简单的元信息约定caveman对文章元信息的处理非常原生态。不需要Jekyll那种复杂的Front Matter我通常直接在Markdown文件的第一行写# 标题然后依赖文件名里的日期来排序归档。一个标准文章文件长这样# 用caveman建站的三个月 正文内容从这里开始…… ## 第一个小节 这里是正文……文件名我习惯于用2025-06-01-hello-caveman.md这种格式。文件名里的日期既能用来排序又能在生成归档页时被脚本提取一举两得。这种约定虽然原始但好处是任何文本编辑器都能打开就写不用记一堆参数有没有拼错。2.4 模板骨架把{占位符}换成真内容caveman的模板走的是最朴素的替换路线。你在layout目录下放一个HTML骨架里面填上{TITLE}、{CONTENT}之类的占位符构建时它会把真实内容替换进去。我的一个极简模板大概长这样!DOCTYPE html html langzh-CN head meta charsetutf-8 title{TITLE}/title /head body header h1{TITLE}/h1 /header main {CONTENT} /main /body /html如果你懂一点点Makefile就能把所有页面的公共框架抽出来再按需拼接。它没有现代模板引擎那些继承、嵌套、过滤器的概念但反过来想哪一页长什么样你心里一清二楚。3. 实操过程我真的用它把博客跑起来了3.1 从零初始化一个站点如果你想直接上手最快的方式是新建一个目录手动创建上面那套结构。没有初始化的交互式命令没有caveman new之类的脚手架——至少我用的时候没有。这种不提供脚手架的设计反而让我养成了好习惯所有东西都自己搭也就不会出现项目能跑但不知道怎么回事的情况。我的Makefile里有一段核心构建逻辑PAGES : $(wildcard src/*.md) HTML_FILES : $(PAGES:.md.html) all: $(HTML_FILES) echo Build complete.逻辑很简单找到src下所有.md文件把它们逐个替换成对应的.html然后交给caveman去渲染。这段配置差不多是我从官方示例抄过来改动最小的部分。3.2 构建与本地预览感受一下亚秒级一切就绪之后直接运行make你会看到类似src/hello.md - public/hello.html这样的输出。由于每个文件都是独立处理的构建速度非常快。我往src里塞了大概两百篇文章整个构建过程依然在1秒内完成。这个成绩在今天的静态生成器里不算出奇但考虑到它只有几十KB还是让人挺感慨。本地预览我习惯用Python自带的HTTP服务器cd public python3 -m http.server 8080然后打开浏览器访问http://localhost:8080。这里有个小细节千万别用file://协议直接双击打开HTML因为caveman生成的是相对路径链接有些资源跨目录可能加载不出来。3.3 部署两种最顺手的姿势静态站点的部署没什么玄学主要就是把public目录原封不动传到某个地方。姿势一自己的服务器Nginx我最常做的还是用rsync推到VPS上rsync -avz --delete public/ userserver:/var/www/myblog/--delete参数保证服务器上不会残留旧文件。然后在Nginx里指一下站点根目录一个博客就算上线了。姿势二GitHub Pages不想碰服务器的话可以把public目录push到GitHub Pages分支。我个人的做法是建一个gh-pages分支把public里的内容放进去。这样每次make之后一条脚本就能完成提交和推送。对caveman这种简单工具来说功能完全够用。3.4 一次真实构建的记录为了给读者一个更直观的感受我贴一段当时构建时终端的输出大概形式是这样具体时间数字会因为机器不同有波动$ make cc -O2 -o build/caveman src/caveman.c src/2025-06-01-hello.md - public/2025-06-01-hello.html src/2025-06-05-second.md - public/2025-06-05-second.html ... Build complete.从输出能看到真正做事的还是底层的C程序Makefile只是把流程串起来。这种每个环节都看得见的体验对我这种喜欢刨根问底的人来说实在是一种享受。4. 常见问题与排查技巧实录4.1 中文乱码全都是编码的锅这是新手最容易撞上的坑。caveman内部对字符串的处理很透明如果你的文件是带BOM的UTF-8或者系统locale不是UTF-8生成的页面就可能出现乱码。我的排查路径分三步第一步确认所有Markdown文件都是UTF-8无BOM。在Linux下可以用file src/*.md快速查看。第二步确认HTML模板里的meta charsetutf-8没有写错。第三步如果还是乱码检查一下运行make时终端的环境变量LANG确保它是zh_CN.UTF-8或C.UTF-8。4.2 模板占位符不生效空格是隐形杀手我踩过一次特别蠢的坑。在layout里把占位符写成了{ TITLE }多加了空格结果页面标题死活不替换。查了半天源码才反应过来占位符内部不能有空格{TITLE}和{ TITLE }是两回事。4.3 Markdown解析的边界别拿它当全功能解析器caveman内置的Markdown解析器非常轻支持标题、粗体、斜体、链接、列表这些常用语法但遇到更复杂的嵌套时可能会犯迷糊。比如行内代码里出现**它可能还是会当成加粗渲染。我的应对方案是在文章里尽量少用复杂嵌套真遇到了就改用HTML实体或者直接手写HTML标签。反正Markdown本来就允许内嵌HTML这是最保险的处理方式。4.4 发布路径错误子目录部署的注意点如果你不是部署在域名根路径而是放在https://example.com/blog/这样的子路径下那所有的内部链接都要加上前缀。我在部署到服务器子目录时就因为忘了检查模板里的相对路径导致CSS文件全部404。解决方法是模板里的样式和脚本引用全部用相对路径并且保证生成的HTML和前两者在同一个层级或者干脆把站点部署在根路径下省心。4.5 问题速查表现象可能原因解决办法中文乱码文件带BOM或locale不对转UTF-8无BOM设LANGC.UTF-8标题不替换占位符写了空格确保{TITLE}无空格代码块渲染异常极简解析器不支持复杂嵌套改用HTML标签或简化语法部署后JS/CSS 404子路径部署未处理相对路径修正模板中的资源引用public里的文件被清掉手动了生成目录把持久资源放assets并拷贝进去5. 进阶玩法让原始人工具也能干现代活5.1 分类与标签用脚本凑一个归档页caveman本身没有分类系统但这难不倒我。我的做法是文章文件名用统一前缀比如blog-category-slug.md然后写一个简单的shell脚本从文件名里提取分类名称批量生成归档列表页。刚开始我觉得这是缺功能就得自己补用久了反而发现这种自由度比分类插件更符合自己的习惯。想按时间归档就按文件名里的日期想按分类归档就改一下脚本里的分隔符规则15分钟改完完全可控。5.2 生成RSS Feed给没有RSS的极简生成器加Feed也不算难。只要在Makefile里加一个目标让它遍历所有页面抽出标题、链接和正文前N个字符拼成一个XML文件就行。我这里没有贴完整代码但思路和写归档脚本一模一样把渲染页面和生成元数据拆成两件事前者交给caveman后者交给shell脚本。各司其职互不干扰。5.3 自动发布inotifywait rsync本地改完文章想自动同步到服务器可以用inotifywait监听src目录的变化一旦有.md文件变动就触发make然后rsync到服务器。while inotifywait -r -e modify,create,delete src/; do make rsync -avz --delete public/ userserver:/var/www/myblog/ done用的时候记得加一个冷却时间控制防止你连续保存时触发太多次同步。我实际跑下来这个方案的延迟基本就是rsync传输的那几秒。5.4 源码阅读最好的C语言教材如果你想深入学习C语言我特别推荐读一遍caveman的源码。它的Markdown解析器部分是很好的手写解析器入门素材代码量不大但逻辑完整。读完之后你再去看那些复杂框架的实现接受度会高很多。我读源码时最享受的一点是每一个函数你都知道它被谁调用为什么存在。没有像某些大型项目那样几十层的抽象整个程序就是一条清晰的主线。这种纯粹的工程快感在今天的开源世界里已经不多见了。6. 从工具到理念caveman的另一种精神6.1 caveman debugging不用调试器的原始排错法多说一句caveman衍生出的概念——caveman debugging。它指的是不用断点、不用DEBUG工具全靠printf打日志、靠二分注释代码来排错。这种原始排错方式在多线程问题、线上偶发bug、性能瓶颈排查时反而比IDE里的交互式调试器更有效。这和caveman这个工具给我的感觉是一致的先把复杂的壳剥掉回到最本质的因果关系上去。当你删掉所有干扰项问题往往就自己浮出来了。6.2 对现代开发者的启示少即是多用过caveman之后我对多和少有了新的判断。今天很多工具的功能增长其实是在替用户做选择但也剥夺了用户理解底层的能力。caveman不是告诉你我有100种主题供你选择而是告诉你这就是HTML结构你想改哪里就改哪里。我不是说所有项目都应该返祖成C语言Makefile。这个时代选择Hugo、Hexo完全合理它们解决的是规模问题。但如果你想重新掌控自己的内容想找回构建的确定感那caveman这个级别的工具值得你体验一次。6.3 最后分享一个我自己留到现在的小技巧用caveman这种极简工具真正受益的是它逼我建立了内容即文件、文件即内容的习惯。我现在写博客草稿都用纯Markdown放在src里任何一台机器只要装了git和make就能完整复现整个站点。换电脑、迁移服务器成本低到忽略不计——这比任何云端编辑器都让我安心。在写这篇文章的时候我还顺手整理了一下旧机器上的站点脚本把归档页的生成规则从按月份改成了按分类整个过程重新编译加改动只花了一个下午。要在Hugo里改归档策略我大概得先翻半天主题文档。这种工具跟着人走而不是人跟着工具走的感受就是我一直留着caveman不换的原因。
