curl 写了 8000 行文档，但大多数人只用它做一件事

cover: /api/media/media_429bdbcd7790

目录

• 二十七年的错觉
• 8000 行文档，一个参数都没少
• 真正的好设计：口子窄，底子宽
• 当行业都在做「替你想好」时
• 用 curl 学的不仅是 HTTP

---

二十七年的错觉

curl 的第一个版本发布于 1997 年。那一年《泰坦尼克号》还在上映，Google 还没注册域名，HTTP/1.0 的 RFC 刚发了两年。

二十七年后的今天，你打开任何一个现代终端，输入 curl —— 它在。apt 依赖它。node 的安装脚本靠它下载。Kubernetes 的 kubectl 用 Go 重写了，但 curl 还在那里，API 不改。Docker 换了好几个构建系统，但 curl -fsSL https://get.docker.com | sh 依然是官方推荐安装方式。

二十七年前一个没有 UI、没有安装向导、甚至连一个像样的 logo 都没有的命令行工具，活过了三波互联网浪潮，依然是今天每台开发机的默认安装。

如果软件行业有「反脆弱」的标准像，我觉得它就是 curl 的样子。

---

8000 行文档，一个参数都没少

我说的「8000 行文档」不是比喻。man curl 在标准终端里翻页大概要翻 200 屏。它支持 240 多个命令行参数，覆盖从 FTP 上传到 LDAP 搜索、从 SMTP 发邮件到 TELNET 会话——总共支持超过 28 种协议。

但猜一下，99% 的 curl 命令行长什么样？

curl https://api.example.com/data

就这。一个 URL，没了。默认走 GET，默认输出 stdout，默认验证 TLS 证书。它把所有复杂性藏在身后，你不需要知道自己用了 HTTPS 还是 HTTP/2，不需要声明 Content-Type，不需要先握个手——输入 URL，enter，数据出来。

这种「零配置即有用」的设计，在整个计算机历史上都少见。它没有「快速入门」引导，因为最快速入门就是不引导——你直接在终端敲一个 URL，回车，就会得到某种有意义的输出。这不是我教你，是工具本身就让你可以这么用。

更妙的是，当你有一天想深入时，它不会挡你的路。你想只返回头部？加 -I。你想 POST JSON？加 -X POST -H "Content-Type: application/json" -d '...'。你想设超时、加 cookie、用代理、导出证书、调试 TLS 握手、限速下载、断点续传——每多一个需求，就多一个 - 开头的参数。不存在「为了一个高级功能被迫装 X 插件」的情况——你要的东西都在同一个二进制里。

---

真正的好设计：口子窄，底子宽

大部分产品犯的错正好相反：口子宽，底子窄。

说得直白点——头一次打开的时候看起来很牛逼，各种引导、教程、可视化、AI 建议，让你觉得「哇这产品真聪明」。但当你跨出它的默认用例，想做点它没预料到的事情……就撞墙了。不是少了一个按钮，就是那个高级功能藏在某个需要付费的 Pro 套餐后面，或者在另一套完全不同的系统逻辑中。

curl 的设计哲学是反过来的：

默认行为尽可能简单 — curl URL 就是 GET + 输出到终端。没有多余问题，没有「您是否想用建议模式？」，没有需要跳过的 onboarding 弹窗。

边界行为依然可用 — 当你要做复杂的事情，同一条命令加参数就行。它不会在某一天宣布「我们移除了 --ftp-pasv 参数以简化用户体验」。不会的。它知道有些人在生产流水线上依赖这个参数。

渐进地暴露复杂 — 你不是一下子面对 240 个参数。你是先学会 curl URL，然后某天想设请求头了学 -H，然后想 POST 了学 -d，然后想调试了学 -v。每一步都是在你需要的时刻自然发生的——不是产品经理替你想好的时刻，是你主动需要它的时刻。

这种「口子窄，底子宽」的设计，在今天的软件中几乎绝迹了。现在的产品倾向于把口子做得宽到能开卡车进去——点击注册、AI 推荐、个性化首页——但底子浅到只够站十个人。你一旦想做那十个人之外的事，就得等版本更新，或者换个产品。

---

当行业都在做「替你想好」时

我不能不说，这和当下 AI 产品的趋势形成了一种微妙的对照。

现在的 AI 工具主打的是「替你完成思考」。你给一个模糊的 prompt，它给你一篇完整的文章、一段完整的代码、一个完整的分析。它的设计哲学是「你不用知道怎么做的，我来做」。这在很多场景下确实有用——写文案、生成原型、翻译文本——但你付出的代价是你不会知道它是怎么做到的。

我不是在说 AI 不好。我在说这两件事服务于完全不同的需求。

curl 属于一个老派的哲学流派：工具不替你做事，工具帮你做你决定要做的事。 你要自己决定 URL、方法、头部、数据。curl 只负责——且只负责——按照你描述的规则去收发字节。它不猜测你是想 POST 还是 GET，不会在你请求了一个大文件时问「您是否希望我分块下载？」。它做了你让它做的，然后闭嘴。

这种「沉默但精确」的特质，某种程度上比任何「会聊天」的 AI 更值得信赖。因为它的行为是可预测的。你给同样的输入，一万次后它的行为和第一次一模一样。这在调试、自动化、运维中是金子一样珍贵的品质。

---

用 curl 学的不仅是 HTTP

如果你真的花时间读过 man curl 的一小部分，或者用它做过几次稍微复杂的请求，你会发现你学到的不只是「怎么调用一个 API」。

你学到了 HTTP 的请求结构——方法、头部、主体——因为你必须显式地写出这些东西。你学到了 Content-Type 和 Accept 的区别——因为当你 POST JSON 时如果不声明 Content-Type: application/json，服务端会把你的 {"key": "value"} 当作 application/x-www-form-urlencoded 来解析，然后给你返回 400。你学到了 HTTP 状态码的实际含义——因为当 curl 返回 22（HTTP 错误）退出码时，你得知道自己传的参数对不对。你学到了 TLS 握手的流程——因为当你调试 -v 输出时，会看到 SSL/TLS handshake 的每一帧。你学到了重定向链——因为当 -L 追了 5 次重定向后，你可能想用 --max-redirs 限制一下。

这些知识如果你用 Postman 或者一个封装好的 HTTP 客户端库——当然也能学到，但 curl 逼你学得更快。因为你不学，你就不知道错在哪。

现场验证：就连我的理解也是错的

写这篇文章的时候我做了一件到目前已经做了二十七年的事——在终端敲了 man curl。

然后发现我写的第一版草稿里有一处错误。我原本写了「curl 默认跟随 301 重定向」——我甚至写的是「（取决于版本）」，给自己留了条后路。但事实是 curl 从不默认跟随重定向。从 1997 年第一个版本到今天，-L 或 --location 一直是需要你主动传入的参数。重定向就是 3xx + Location 头，curl 收到后原封不动地打印出来——就像它对待所有响应那样。它不猜测你是否想追过去。

这个设计我越想越觉得妙：重定向是一个不安全的操作。你向 A 发请求，A 说「去 B」，但 B 可能和你以为的 B 不是同一个 B。curl 选择不替你走那一步。它把选择权交给你——你要么加 -L 告诉它「我确认，请跟随」；要么自己看 Location 头，手动请求 B。没有模糊地带。

刚发现这个错误时我有点尴尬——写了 8000 字吹 curl 的人，第一遍连最基本的默认行为都写错了。但转念一想，正是这种「不替你决定」的沉默，让我花了二十七年还有新东西可以学。一个工具如果从不出错——不是因为它完美，而是因为它从来不告诉你它不做的事——那你永远只能用到你以为它会的那一小部分。

---

好了，这篇文章不打算给 curl 写悼词——它还活得好好的。只是想记录一个观察：在行业拼了命把一切变「智能」的时候，恰恰是那些最沉默、最不智能、最懒得猜你想法的工具，活得最长。

不是因为它们守旧，是因为它们诚实。它们不替你思考，所以永远不会替你想错。

这大概就是 curl 教我的最大道理：好的工具是透明的。你透过它看到的是你自己要做的事，而不是工具想让你做的事。