devgo.cn如果你每天都在命令行里敲 curl，或者在代码里用 libcurl 做 HTTP 请求，可能觉得它就是个“稳如老狗”的工具——功能多、兼容性好，但性能上似乎没什么可折腾的。毕竟它已经二十多岁了，该优化的早优化完了。但 curl 团队最近用一套新搭建的自动化性能测试，在短短两个月里又扣出了不少性能空间，这些改进都进了明天（10月14日）发布的 8.23.0。
先说个最反直觉的：**base64 编码快了不止一倍，解码也快了 40%**。为什么一个下载工具要关心 base64？因为 curl 内部很多地方要用它，比如处理 HTTP 认证头、某些协议的数据编码，还有上传时的 chunked 编码。平时你可能感受不到差异，但量大了之后，每个 base64 转换多花 0.1 微秒，累积起来就是可感知的延迟。优化方式不是换算法，而是重写了内部循环——用查表法替代逐位判断，减少分支跳转。
另一个很“内部”的改进是 URL 解析。curl 要做的不是简单拆分字符串，而是要严格校验 URL 合法性，并且把协议、主机、路径、参数等拆成独立字段。这个函数是 libcurl API 暴露的核心能力，每次请求几乎都会调用。在测试几百个不同 URL 时，8.23.0 比之前快 20-30%，而且当 URL 非法时，能更精确地告诉你错在哪——比如是端口号不对，还是缺少协议头，而不是笼统的“invalid URL”。
日期解析也是容易忽略的环节。Cookie 头里的日期是纯文本格式，比如 `Wed, 09 Oct 2024 07:00:00 GMT`，curl 需要把它转成 epoch（1970年1月1日以来的秒数）。旧实现里星期的英文名、月份、时区都是挨个字符串匹配，新实现换成了直接查表，整体快了不止一倍。
再说一个你可能没意识到的点：**curl 自己有一套 printf() 实现**。为什么不用系统的？因为要保证在所有平台（Windows、macOS、各种 Unix）上行为完全一致，比如浮点格式、指针打印等。但自研就要自己背性能债。这次优化把原来的“逐个字节输出”改成了“按块写入”，底层缓冲区一次性拿够数据，printf 调用普遍提速 5-15%。别小看这个数字，curl 内部有大量日志、报错、格式化输出，积少成多。
数字解析也快了几乎一倍。curl 内部有个通用函数，把 ASCII 形式的十进制、十六进制、八进制数字转成二进制整数，支持 64 位、溢出检测和最大值限制。它用了一招很朴实的技巧：在大多数循环里预先排除边界检查，只在最后做一次完整校验——类似把“每步看路”改成“直线走，终点验证”，省了很多分支判断。
真正显功夫的是内存结构瘦身。curl 处理每个并发传输时都要分配一个 `easy handle`（libcurl 对外操作的基础对象），两个月前它占 4256 字节，现在压到 3064 字节，减了 28%。每个传输集合还有 `multi handle`，从 900 字节降到 656（-27%）。每个连接一个的 `connectdata`（保存 TCP/TLS 连接状态的内部对象）也从 824 降到 656（-20%）。这些结构体是每次请求的“固定成本”，虽然单看不大，但如果你在高并发下跑几千个连接，省下来的内存相当可观。
配套地，分配次数也降了。官方用一个基准测试：用 curl 工具通过明文 HTTP 下载一个 512MB 文件，统计整个过程中发生的所有内存分配。两个月前是 100 次，现在 96 次——别嫌少，这已经是挤牙膏挤到极限了。峰值内存占用从 130,622 字节降到 126,875，其中下载缓冲区本身占 102,400 字节，如果把这块固定分配踢掉，curl 的额外内存开销实际上减少了 15%。
这些改进背后的支撑是 curl 团队从 8 月开始跑的一套自动化性能测试。测试本身放在 git 仓库里，任何贡献者都能拉下来跑，对比自己的改动是提速还是拖慢。这套测试之所以能立刻见效，是因为它把“性能”从模糊的直觉变成了可量化的数字——以前你说“我感觉更快了”，没人信；现在你跑一遍基准，一清二楚。
对我这种写工程代码的人来说，这个案例的启发是：**不要等到性能成为瓶颈才去优化，而是先搭好测量工具**。curl 团队把测试跑起来后，很快在 base64、URL解析、结构体大小上找到了优化点——这些地方平时根本不会被人注意，但因为测量精准，任何微小提升都能被看见。另外，结构体瘦身靠的是仔细审查字段布局、压缩无用位、去掉重复信息，这种“结构性减肥”对长期项目非常有用，因为每个对象的内存成本在千级并发下会被放大。
如果你想亲自验证这些改进，等 8.23.0 发布后，直接跑到仓库里跑 `./configure && make && make test`，或者看测试目录里的 `perf` 相关脚本。另外提醒一句：base64 和 URL 解析的优化对普通用户来说几乎无感，但如果你是做嵌入式开发或者高并发网关，这些小数字就是你的大福音。唯一要小心的是，这些优化用了很多查表和特殊循环技巧，外部贡献者如果要改动相关代码，一定要先跑性能测试，别用感觉说话。
内容与图片版权归原作者所有 · 原文: https://daniel.haxx.se/blog/2026/10/13/a-slightly-faster-slimmer-curl/