搞懂Caveman：框架、排序算法与调试法的极简智慧

如果你在代码仓库里看到一个叫caveman的目录，先别急着猜它是某种远古文明考古项目。我第一次听到这个词，是在跟一个老同事争论要不要给项目引入重型框架的时候。他丢过来一句话：“你就是想得太现代化了，很多场景其实当个穴居人挺好。”后来我去翻了翻资料，发现caveman在程序员圈子里居然有三个完全不同的指向：一个轻量级 Web 框架、一个被当成段子的排序算法、还有一种靠打印日志走天下的调试习惯。这篇东西，就是想把这几个容易混淆的“穴居人”捋清楚，顺便聊聊我在实际项目里当“穴居人”的几次真实体验——哪些做法是返璞归真，哪些纯粹是给自己挖坑。

1. "caveman"在代码圈里到底指什么：三个容易混淆的指向

1.1 一个叫Caveman的Web框架

在 Common Lisp 生态里，Caveman是一个真实存在的 Web 框架，走的是轻量、简单、不包装复杂概念的路线。它不是让人重新发明轮子，而是把已经成熟的分层工具拼起来，自己只做路由定义、应用骨架、上下文管理这几件最核心的事。

很多没接触过 Common Lisp 的人会好奇：这个古老得常被归为“古董语言”的圈子，怎么会有一套现代 Web 框架？实际上 Common Lisp 的 Web 技术栈非常完整，底层有Lack这个类似 WSGI/Rack 的中间件分层标准，上层有Clack负责启动 server、处理请求生命周期，Caveman只是坐在这两者之上的一层薄薄的“人格化接口”。

用官方文档里常见的示例来说，路由定义可以写成这样：

(defroute "/" () "Hello, Caveman!") (defroute "/hello/:name" (name) (format nil "Hello, ~A" name))

就这么几行，一个能响应动态路径参数的最小服务就出来了。它没有像很多现代框架那样给你六个内置 ORM 选项、三套模板引擎、自动路由扫描、代码热重载全家桶，而是默认你只需要这一点点，剩下的按需自行加载。

说得更直白一点：Caveman这个名字本身就带着自嘲气质——“我们就是个穴居人框架，别指望我帮你解决所有问题”。但恰恰是这种克制，让它在一大堆“全家桶式”框架中间显得非常清醒。

1.2 一个被当成反面教材的排序算法

另一个“caveman”指的是Caveman Sort，也叫Bogosort，算法界的半开玩笑式反面教材。它的排序逻辑简单到令人发指：每次随机打乱整个数组，然后检查它是不是已经有序了，如果没有，再随机打乱，继续检查，直到某一次运气好，恰好打出了一个有序序列。

import random def is_sorted(arr): return all(arr[i] <= arr[i+1] for i in range(len(arr) - 1)) def caveman_sort(arr): while not is_sorted(arr): random.shuffle(arr) return arr

如果你把这个算法当真拿去做生产排序，结果是灾难性的。我们来算一笔账。

对一个 n 个元素的数组，单次检查“是否有序”的代价是 O(n)，每次随机洗牌后恰好得到正确有序序列的概率是 1/n!，于是期望尝试次数就是 n! 次。所以总的期望时间复杂度是：

O(n × n!)

当 n = 10 时，10! = 3,628,800，乘上 n 之后就是 3600 多万次操作，勉强还能忍。但 n = 15 时，15! 已经到 1.3 万亿级别，等待时间足够你睡一觉再醒来。n = 20 时，20! 约等于 2.43 × 10^18，这个数量级已经不是“慢”，而是“物理意义上不可能等完”。

我第一次给团队讲这个算法时，很多人的第一反应是“这玩意儿有什么好学的”。但我认为它其实是理解算法复杂度最好的教材：同样一个“功能正确”的算法，因为设计思路的差异，运行时间可以从毫秒膨胀到宇宙寿命级别。你会非常直观地认识到，复杂度不是代码风格问题，是你能不能活下去的问题。

1.3 一种被称为"穴居人调试法"的工作习惯

第三个“caveman”用法更口语化，指的是Caveman Debugging，也就是传说中“上不了台面”的打印调试法。现代 IDE 里的断点调试器、内存查看器、性能剖析器功能越来越强，但你真正去一线排查问题时，会发现大量程序员最信任的仍然是那句：

print("debug: here, value =", something)

这词听起来像在骂人，实际却是在描述一种务实到极点的态度：不求工具炫酷，只求最快定位问题。Caveman Debugging不跟你谈断点条件、调用栈可视化、火焰图，它的信条只有一个——“把数据打到屏幕上，肉眼看”。

我刚工作那几年特别鄙视这种做法，觉得不用调试器是能力不足的表现。后来被线上问题教育了几次，才慢慢理解：调试器的存在是有前提的，你得能复现、能断点、能进入交互环境；而很多生产环境问题恰恰不具备这些条件。这时候要么靠日志，要么靠在全流程里补打印，再一步步缩小范围——这正是穴居人调试法一直在做的事。

这三个“caveman”表面上毫无关联，一个框架、一个恶搞算法、一种调试习惯，但它们共同指向同一种气质：面对复杂问题时，优先考虑最简单粗暴、最不依赖环境条件的方案。这也是我接下来想重点展开聊的东西。

2. 我为什么会重新审视Caveman框架：重框架时代的一场逆行实验

2.1 主流框架带来的隐性成本

先交代一下背景，我在业务里用主流 Web 框架的时间不短，Rails、Express、Spring Boot 都深度用过。在最开始接触它们时，我和大多数人一样，冲着“快速搭建、生态齐全”去的。但用了几年后，我越来越意识到一个被忽略的问题：框架的每一项便利都是有代价的，只不过代价不是即时扣款，而是延后分期。

最常见的隐性成本有几个：

• 依赖树膨胀。一个初始项目光安装依赖可能就是几百 MB，其中八成你根本不知道是干什么的，只知道不装某些代码就跑不起来。
• 约定优于配置带来的心智负担。默认约定确实省事，但一旦你需要“反着约定”来一次，往往要翻文档、翻源码、翻 issue，最后可能还不得不写一段丑陋的绕过代码。
• 升级的破坏性。框架三年升一次大版本，每个版本都有 breaking change，而项目里依赖它的替换逻辑也会跟着推翻重来。很多老项目的技术债，本质就是框架升级欠下的。
• 新手层级的“伪理解”。用脚手架生成项目的人很多，但真正出事时能讲清楚“请求从进入到返回，中间经过哪些环节”的人很少。框架越是自动化，开发者对底层理解就越薄弱。

我绝对不是说框架没用。大型业务系统里，框架帮你统一规范、节省协作成本，价值非常大。但当我接手的是一些内部服务、小工具、一次性脚本的 Web 壳时，我开始认真计算这些成本值不值得付。

2.2 Caveman框架做"减法"的底气

回头看Caveman这类极简框架，它做减法是有底气的，底气来自 Common Lisp 本身的工程传统。

Common Lisp 社区的做事风格一贯如此：标准库能解决的不额外抽象，真正需要复杂方案时，直接给你语言级的能力，而不是框架级的面包屑。Caveman不需要实现自己的请求解析、服务器适配、会话管理，因为它可以直接跑在Clack上，而Clack后端支持 Hunchentoot、Woo、AllegroServe 等多个服务器实现。它也犯不着硬造一套模板语言，嵌入式 HTML 的方案已经足够覆盖大多数场景。

我需要明确一点：Caveman的减法不是“功能残缺”，而是“只保留 Web 应用骨架里最本质的部分”。你依然可以往中间件链里挂各种东西，想加认证、加日志、加静态资源服务都很方便，只不过这些都不是框架默认强塞给你的。

它给我的体感是：路由写起来很直接，控制器就是普通的函数，请求上下文是一个可以随时访问的对象，没有依赖注入容器、没有服务提供者、没有注解扫描。想理解一个请求走到哪里，顺着代码看就行，不需要在框架的黑盒里面猜“它到底帮我做了什么”。

2.3 什么情况下我会把Caveman推荐给别人

因为Caveman的小众，我不会逢人就推荐，但它确实有非常清晰的适合场景。我建议你按这张表来自我诊断：

我自己用得最多的是“当我要为某个脚本做一个 Web 操作界面”的场景。以前用 Spring Boot 起这种项目，光初始化到能跑就要二十多分钟，依赖下载还时常让人心焦。用Caveman之后，从打开编辑器到本地服务跑起来，通常就是一杯咖啡没喝完的事。

3. 一次完整的Caveman实战：从空白环境到一个可运行的Web服务

3.1 环境准备：最容易翻车的地方

先说我踩过的坑。Common Lisp 的环境搭建，最容易翻车的地方反而不是语言本身，而是操作系统的原生依赖。SBCL（Steel Bank Common Lisp）在编译某些库时需要一些 C 库头文件，比如 zlib、libssl、libffi，如果你在 Debian/Ubuntu 上漏装了这些，Quicklisp 加载库时会出现一堆莫名其妙的编译报错。

我常用的准备步骤是这样的，先装系统包：

sudo apt-get update sudo apt-get install -y sbcl libz-dev libssl-dev libffi-dev

这里要留意：不同发行版的软件包含义不太一样，Arch 上是sbcl openssl zlib libffi，macOS 上则看你用 Homebrew 还是 MacPorts。SBCL装好后，需要安装Quicklisp，它相当于 Common Lisp 的包管理器，把quicklisp.lisp下载下来之后用 SBCL 执行：

curl -O https://beta.quicklisp.org/quicklisp.lisp sbcl --load quicklisp.lisp

然后会进入一个交互式会话，在里面执行(quicklisp-quickstart:install)并执行(ql:add-to-init-file)，这样以后每次启动 SBCL 都能直接使用ql:quickload。

第一次加载Caveman时，Quicklisp 会把所有依赖自动拉到本地：

(ql:quickload :caveman)

由于需要编译的依赖库很多，首次等待时间可能接近十分钟，这是正常现象。很多人到这里会以为卡住了，其实只是Caveman的依赖树在默默编译。

3.2 项目初始化与目录结构

Caveman自带项目生成器，大多数版本里对应的命令是：

caveman create my-app

如果你更习惯在 SBCL 里直接操作，也可以在当前目录通过系统函数调用生成器，效果一致。生成完的项目目录风格非常有“在 Common Lisp 社区里过日子”的味道：

my-app/ ├── my-app.asd # 系统定义文件，相当于项目的构建脚本 ├── src/ │ ├── config.lisp # 应用配置 │ ├── app.lisp # 主应用入口，定义路由挂载点 │ └── main.lisp # 启动入口 ├── templates/ # 模板文件 ├── static/ # 静态资源（CSS、JS、图片） ├── test/ # 测试目录 └── my-app.lisp # 加载入口

注意一下my-app.asd，这是 Common Lisp 的“系统”定义文件，各个源码文件打包成一个系统单元。你可以用(asdf:load-system :my-app)来加载，也可以直接在交互环境里把它加入 Quicklisp 的本地项目路径。后续每增加一个.lisp文件，都要在.asd的:components里登记，不然加载时会找不到。这跟 Java 项目自动扫描 classpath 很不一样，刚开始容易忘。

3.3 路由、控制器与参数处理

Caveman的核心入口是app.lisp。它最常用的用法就是defroute定义路由，支持路径参数、请求方法约束以及简单的控制器逻辑。

我搭一个示例服务，包含两个接口：一个返回纯文本，一个返回参数化的 JSON：

(defroute "/health" () "OK") (defroute "/user/:id" (id) (format nil "{\"id\": \"~A\", \"source\": \"caveman\"}" id))

如果你需要限制方法，可以在路径后面声明，比如：

(defroute ("/user/:id" :method :POST) (id) (or (get-user id) (make-http-response :status 404 :body "Not Found")))

这里有一个值得注意的细节：defroute默认对多个方法都会响应，如果你只希望接受 POST，最好显式写:method :POST，否则 Get 请求也会命中这个路由，这在排查接口 405/404 问题时经常是隐藏原因。

参数方面，id这类路径参数默认拿到的是字符串，即使 URL 里看起来是数字。我建议在控制器里自己做类型转换，或者写一个工具函数统一处理：

(defun parse-id (string-id) (let ((value (parse-integer string-id :junk-allowed t))) (when (null value) (make-http-response :status 400 :body "Bad Request")) value))

这点很重要，因为很多现代框架会自动做类型转换和校验，Caveman不会。它不是做不到，而是把选择权交还给你。

3.4 模板与静态资源：怎么处理前端部分

Caveman默认的模板方案走的是嵌入式 HTML 路线，模板文件放在templates目录，语法风格类似 ERB，用<% %>嵌入 Lisp 代码。一个简单的模板可能是这样的：

<h1>用户列表</h1> <ul> <% (loop for name in *names* do %> <li><%= name %></li> <% ) %> </ul>

模板渲染的方法在配置里可以指定，通常通过cl-emb这类库完成。如果你和我一样更喜欢现代前端的打包工具，也可以不使用它的模板能力，只把Caveman当作 API 后端的容器，前端单独用 React/Vue 构建，两边通过 JSON 通信，静态文件交给 Nginx 托管。我用下来觉得这种“只取所需”的组装方式最舒服。

需要注意一点，templates目录下的文件路径默认是相对于项目目录的。如果你改了启动方式，比如换了一个 cwd 环境，模板找不到的概率会明显上升。建议在config.lisp里把模板根目录设置成绝对动态路径，然后基于ASDF的系统目录拼接：

(defparameter *template-directory* (merge-pathnames #p"templates/" (asdf:system-source-directory :my-app)))

这是我记录在案的一个高频踩坑点。

3.5 数据库集成：一个保存用户数据的接口

最后给服务配上数据库。Common Lisp 里我常用Mito作为 ORM，操作习惯类似 ActiveRecord，但更轻。以 SQLite 为例，连接和建表大概是这样：

(mito:connect-toplevel :sqlite3 :database-name "my-app.db") (defclass user () ((id :col-type (:serial 8) :primary-key t :auto-increment t) (name :col-type :text :initarg :name) (created-at :col-type :timestamp :initarg :created-at)))

如果你想保证模型对应的表存在，可以在应用启动时做一次表结构同步：

(mito:ensure-table-exists (find-class 'user))

再写一个真正往数据库里插入数据的 POST 接口：

(defroute ("/users" :method :POST) () (let* ((body (make-http-body)) (name (getf body :name))) (unless name (make-http-response :status 400 :body "missing name")) (mito:create-dao 'user :name name :created-at (local-time:now)) (make-http-response :status 201 :body "created")))

这里的make-http-body我是示意写法，实际项目中你可能要从请求流里读取并解析 JSON，具体取决于你用的 JSON 解析库。整个接入过程能看出Caveman的策略：ORM 可以用 Mito，也可以完全不用，纯写 SQL 也可以。它不会替我决定“你必须用哪套持久化方案”。

4. 建议配置与常见踩坑：Caveman实际跑起来会遇到的问题

4.1 端口、热加载与进程管理

Caveman的默认开发端口在示例配置里通常是5000，但生产环境我会显式指定端口，而不是依赖默认值。启动方式也分成两种：开发时用交互式 SBCL 里直接加载，边改边运行；线上用已编译的二进制并通过守护进程管理。

如果你在开发模式里改了源码，别期待它会自动热重载。Caveman不默认提供热加载，你需要手动重启进程或调用对应的重新加载函数。我一开始不适应，后来反而觉得这样更踏实：每次重启都是干净的，不会像某些框架的热加载一样留下一堆僵尸状态，改了没生效还以为是代码错了。

线上启动时，我建议编译后启动。SBCL 可以把整个应用 dump 成二进制，启动后直接从主入口进入，内存和启动速度都更可控。大致流程是：

(sb-ext:save-lisp-and-die "my-app" :executable t :toplevel #'start-app)

之后就能./my-app直接跑。配合 systemd 或 supervisord 做进程守护非常顺手。

4.2 路由参数的类型与边界

开头说过，路由参数默认是字符串。不要假设1会被自动解析成数字。我遇到过一个典型事故：接口文档里写着id是整数，前端传1，服务端也用(format nil "~D" id)拼 SQL，结果一切正常。后来有人传了个1%27进来，由于代码里没有类型校验，它被直接拼进了 SQL 字符串，差点造成注入问题。

从那以后我养成了两个习惯：

1. 任何从 URL 拿到的参数，先做类型白名单检查，再进入业务逻辑。
2. 凡是参数不符合预期的情况，统一返回 400，而不是让后续代码去承受不可预期输入。

这一条对任何学过安全测试的人来说可能都算是基础，但说实话，在简单内部服务里最容易偷懒的就是这类细节。

4.3 中文与响应的编码处理

另一个容易踩的坑是编码。Caveman返回纯文本响应时，默认的Content-Type如果没带charset=utf-8，浏览器在解析中文时可能乱码，而控制台里打印的内容明明是正确的。

我现在的做法是在需要返回文本的接口上显式设置响应头：

(defroute "/chinese" () (setf (getf (lack-response:response-headers (lack:current-response)) :content-type) "text/plain; charset=utf-8") "你好，穴居人")

如果你统一用 JSON API，那更要记得把响应Content-Type设成application/json; charset=utf-8。这问题在本地 curl 测试时不一定暴露，但浏览器一打开就会露馅。

4.4 静态文件路径与中间件挂载

Caveman对静态资源的默认约定是static目录，访问路径通常是/static/...。之前我遇到过一次“前端样式全丢了”的问题，排查到最后发现是中间件挂载顺序错了。

Lack/Clack的中间件策略和 Rack 类似：中间件是一个洋葱圈结构，请求从外层往里走，响应从里层往外走。如果某个中间件在静态文件中间件的外层提前关闭了请求，静态资源就永远不会被正确处理。我的建议是：

(lack:builder static session *app*)

把静态资源中间件放在最外层，让它最先尝试处理；一旦命中文件就直接返回，不再往内层业务路由走。同时，如果你自己注册了类似/*catchall*的路由，注意别劫持了静态资源的路径前缀，否则你会在“路由明明没问题但文件始终 404”这种怪圈里浪费不少时间。

5. 穴居人调试法：为什么我至今还在用最"原始"的方式定位Bug

5.1 一个用print定位线上问题的完整案例

这一节我想回头认真聊聊穴居人调试法。以我经历过的真实案例为例：一个接口在线上间歇性返回旧数据，明明代码已经改过，缓存也清理过，但它就像薛定谔的猫，一会儿新一会儿旧。

一开始我用调试器，在本地复现了十几次都是正确结果。又用 profiler，也没发现异常。最后我没办法，只能“穴居人式”地在可能的数据入口加了一堆打印输出，比如接口入口打一次、查询前打一次、缓存读取后打一次：

print("[DEBUG] entering endpoint, params:", params) print("[DEBUG] cache key after build:", cache_key) print("[DEBUG] cache value:", cached_value) print("[DEBUG] db value:", db_value)

上线之后看了两轮日志，真相很快浮出水面：缓存的 key 在拼装时漏掉了一个查询参数。当参数缺失时，退化的 key 正好命中全局默认缓存项，导致所有“无参数”请求共享同一份数据。这个 bug 的本质很简单，但被工具的高级功能挡在了后面——调试器和 profiler 都给了我大量数据，却没有直接告诉我“这里构建的 key 和你想的不一样”。

从那次之后，我对 print 调试法的看法彻底变了。它最厉害的地方不是简单，而是直接把数据流每一步的输入输出暴露到眼前。就像洞窟里的原始人钻进水管，用手摸到哪一节是堵的，比站在外面用仪器听声音更快。

5.2 日志打印的正确姿势

如果你的第一反应是“打印谁不会”，那请等一等。我在代码评审里看过太多无效的打印语句，它们的问题不是不够用，而是不需要被 print 的东西打了一堆，真正需要的上下文全被漏掉了。

我给自己总结了一套日志打印的姿势，基本适配所有语言：

• 打入口不打全过程。一个函数只打一次入口信息，变量名和关键参数值放进同一条日志里，而不是在函数体里每隔几行打一条。
• 区分前缀。把[DEBUG]、[WARN]、[ERROR]严格分层。别小看这个，线上日志检索时，分层就是第一道过滤器。
• 打出口不打变量名。对于返回值，我只打印预期的核心结果，而不是把所有局部变量全部 dump 出来。每次打印前问自己：“如果另一台机器只能收到这三行日志，我能不能推理出问题？”
• 不打印密钥与敏感字段。这个不用多说，但每次写完日志自己检查一遍，特别是临时调试时很容易顺手把完整数据带进去。

以 Python 为例，一个我觉得还算靠谱的模板长这样：

import logging logger = logging.getLogger("api") def get_user(user_id): logger.debug("get_user enter, user_id=%s", user_id) user = query_db(user_id) logger.debug("get_user query done, found=%s", user is not None) return user

多打一条出口信息的好处是，当函数异常时你能直接看出“是入口没进，还是出口没出”，排查范围立刻缩小一半。

5.3 调试器和打印之间，我什么时候选打印

调试器和打印之间不是敌对关系，它们只是适用场景不同。我的经验可总结为：

• 本地、可稳定复现的问题：优先用调试器。打断点、看调用栈、动态改变量值，效率最高。
• 线上、间歇性、环境相关的问题：优先打印。因为断点会停在交互式会话里，阻塞线上服务，这在多数场景下不可接受。
• 自己刚写完的代码：多用调试器，趁记忆还在，快速验证逻辑。
• 接手别人的代码，且对流程完全不熟：先打印入口和出口，把整条链路摸熟，再考虑用调试器深入细节。

说白了，打印调试法的地位有点像是“最后的通用方案”：它不需要 IDE、不需要能复现的环境、不需要你完整理解框架内部结构，只要代码在跑，它就能给你反馈。这是一种朴素的兜底能力。

6. 该穴居人时就穴居人，该现代时就现代：我的几个判断标准

6.1 三个判断维度：依赖数量、团队上下文、改动频率

聊到这里，可能有人会觉得我是在全盘鼓吹“非常不起眼的技术方案”。不是。工程决策最怕的是单极思维。我给自己定了三个判断维度，用来决定项目该走“穴居人路线”还是“现代框架路线”。

第一个维度是你要交付的输出形态。如果是一个长期演进的业务产品，需要同时被多个前端团队依赖、涉及复杂权限模型、需要完整的监控告警链路，那重型框架的约定和生态是必需的。如果是一个内部工具、脚本外壳、定时任务的 Web 控制台，那超过两个外部依赖其实已经是在付不必要的税。

第二个维度是团队里有多少人需要理解它。一个人维护的五年期自动化工具，用冷门但简单的方案，不可维护的风险很低。一个十人团队协作的核心服务，用个人风格很重的极简方案，那才是真正的灾难。“冷门”本身不是问题，“让十个不熟悉 Common Lisp 的人维护同一个服务”才是问题。

第三个维度是改动频率。越是一次性、短期、事毕即弃的代码，越应该当穴居人，能少依赖就少依赖，能不通机房就不通机房。越是会持续迭代、多人长期改动的代码，越要在早期把结构铺开，该进框架生态就进。

6.2 一句话总结我的选择逻辑

很长时间里，我做技术选型的默认动作是“引入一个成熟的框架，然后再往里面填业务”。现在我的默认动作变成了：先问自己，这个需求真正需要多少复杂度？

复杂度应该由收益买单，而不是由惯性买单。

如果一个项目连需求都还没写清楚，就先因为“大家都在用”而引入了几个 MB 的依赖，那它从一开始就背负了至少两位数百分比的冗余成本。反过来，如果一个项目的失败本身就是灾难级损失，那再夸张的工程化投入都不为过。

我自己现在的习惯是：每接到一个新任务，先在文本文件里把需求拆成三五行，然后对照那些需求，逐个检查“为了满足它，我真的需要框架的什么能力”。能用一个标准库的没必要求框架，能用一个函数的没必要求模式，能写 30 行原生请求处理的没必要起一个全家桶工程。

这个习惯不保证快乐，但能保证你对自己正在写的每一行代码都知道它为什么存在。

说实话，我写这篇东西的动机并不是号召所有人都去用Caveman，也不是让大家都回归打印调试。我只是越来越觉得，程序员群体里关于“好工具”的讨论总是过度聚焦在“功能多不多”上，很少有人关心“用起来蠢不蠢”。一个工具如果让你在 80% 的场景里摸不着头脑，只为了 20% 场景的便利而存在，那它对你的真实价值可能是负的。

穴居人的生活方式听起来落后，但它有一个现代工具链常常不具备的优点：你手里东西少，心里反而很清楚每一样东西是干嘛的。写代码这回事，其实也一样。

如果你手里恰好有一两个“用现代框架折腾半天、换一个极简方案十分钟跑通”的项目，不妨从这个角度再审视一遍。哪怕最后你还是选择留在舒适区，那个“先拆解需求、再匹配复杂度”的思考过程，本身就是一件很值的事。