软件工程师视角。两者都是 1990s 老牌工具，今天还在用 —— 说明各有所长。
一、一句话对比
工具 一句话定位
wget “下载器”—— 专做下载这一件事，默认就把文件存下来
curl “数据传输瑞士军刀”—— 支持 30+ 协议，默认输出到 stdout，可当库用
二、核心差异速览
维度 wget curl -o
出生年 1996 1998
设计目标 下载、镜像、离线浏览 通用数据传输
默认输出 保存到文件（URL basename） 输出到 stdout
保存到指定文件 -O 文件 -o 文件
协议支持 ~5 种（HTTP/HTTPS/FTP/FTPS） 30+ 种（HTTP/HTTPS/FTP/FTPS/SFTP/SCP/SMB/LDAP/SMTP/POP3/IMAP/RTSP/DICT/FILE/TFTP/GOPHER…）
平台 Linux/Unix 标配 全平台
作为库 ❌ 不行 ✅ libcurl（行业标准，被无数软件用）
大小 几十 KB 几百 KB
许可证 GPLv3 MIT-like（更宽松）
三、详细优缺点对比
wget 优点

优点 详细

1 默认存文件 一行命令就下完，不写 -o 不写 -O
2 断点续传强 -c 自动检测，能续传多少算多少
3 重试机制 默认重试 20 次，断网恢复自动接
4 递归下载 -r 整站镜像（curl 没有）
5 批量下载 -i 列表文件 一行一个 URL
6 后台模式 -b 下载到日志
7 简单直观 学习曲线低，新人友好
8 HTML 解析 能解析 HTML 找链接（-r 时用）
wget 缺点

缺点 详细

1 协议少 只支持 HTTP/HTTPS/FTP/FTPS，SFTP/SCP 没有
2 不能做库 不能嵌入其他程序
3 管道不友好 默认存文件，要 -O – 才能输出到 stdout
4 不支持更多协议 SMTP/POP3/IMAP 收发邮件？不行
5 不能发送 POST 数据体（–body-data 较新版本才有） —
6 GPLv3 协议 部分商业项目避免用
7 大文件并行下载弱 单连接，要并行需 xargs
curl 优点

优点 详细

1 协议广 30+ 协议，SFTP/SCP/SMTP 都能用
2 管道友好 默认 stdout，可直接管道给 grep/jq/python
3 可作库 libcurl 是行业标准（Git、Python requests、Node fetch 都用）
4 API 调试神器 看 header（-I /-v）、看完整请求（–trace）
5 灵活文件名控制 -o file1 -o file2 … 多文件、-O 沿用 URL 名
6 跟随重定向 -L 自动跟 3xx
7 更宽松许可证 MIT-like，商用友好
8 多 URL 一次命令 curl URL1 URL2 -o a -o b
9 细粒度控制 超多 flag（-H/-X/-d/-u/-k/…）
curl 缺点

缺点 详细

1 默认不存文件 必须 -o 或 -O 才会保存
2 不会自动重试 要 –retry N 显式指定
3 不会自动续传 要 -C – 显式指定
4 没有递归下载 不能整站镜像（wget 有 -r）
5 新手要记更多 flag 学习曲线略高
6 错误处理要手动 不会像 wget 自动重试多次
四、实战对比（同一任务）
任务 1：下载文件

wget – 直接存

wget https://example.com/file.zip

→ 当前目录的 file.zip

curl – 必须指定

curl -o file.zip https://example.com/file.zip

或

curl -O https://example.com/file.zip # 用 URL 的 basename
结果：两者结果一样。wget 更短。
任务 2：下载并查看内容

wget – 需 -O –

wget -O – https://api.example.com/data | jq .

curl – 默认就输出

curl https://api.example.com/data | jq .
结果：curl 更直接。
任务 3：断点续传

wget – 自动检测

wget -c https://example.com/bigfile.iso

curl – 显式指定

curl -C – -o bigfile.iso https://example.com/bigfile.iso
结果：wget 更省心。
任务 4：下载整站

wget – 内置支持

wget -r -np -k https://example.com/

curl – 没有递归！要自己写循环

结果：wget 完胜（curl 真的没有递归下载）。
任务 5：API 调用

curl – 灵活

curl -X POST -H “Content-Type: application/json” \
-d ‘{“key”:”value”}’ \
https://api.example.com/endpoint

wget – 也可以但更绕

wget –post-data='{“key”:”value”}’ \
–header=”Content-Type: application/json” \
-O response.json \
https://api.example.com/endpoint
结果：curl 完胜。
任务 6：发邮件（SMTP）

curl – 直接支持

curl smtp://smtp.example.com –mail-from me@example.com \
–mail-rcpt to@example.com \
–upload-file email.txt

wget – 不支持 SMTP

结果：curl 完胜。
任务 7：SFTP 下载

curl – 支持 SFTP

curl -u user:pass -o file.txt sftp://server/path/file.txt

wget – 不支持

结果：curl 完胜。
五、选哪个？
🎯 选 wget 的场景
场景 原因
下载大文件、可能要续传 -c 自动续传，省心
整站镜像 -r -np -k 一行搞定
批量下载 -i 列表文件
简单下载、不想记 flag 默认就存
后台跑下载任务 -b
网络不稳，需要自动重试 默认重试 20 次
🎯 选 curl 的场景
场景 原因
API 测试 / 调试 看 header、trace、详细请求
写脚本处理数据 默认 stdout，管道友好
需要 SFTP/SCP/SMTP 等协议 wget 不支持
多文件一次下载 多 URL 多 -o
嵌入到其他程序 libcurl 是行业标准
商用项目 MIT-like 许可证更友好
处理 JSON/HTML 直接管道 jq/python
🎯 现实经验
场景 多数人怎么用
下载文件 / 镜像 wget
API 调试 curl
写脚本 **curl（管道友好）
整站爬 wget
看 header 排错 curl
六、对比速记表
任务 wget curl -o
下一行存文件 ✅ 默认 ⚠️ 需 -o
管道给 grep ⚠️ -O – ✅ 默认
断点续传 ✅ -c ⚠️ -C –
自动重试 ✅ 默认 ⚠️ –retry
整站镜像 ✅ -r ❌ 没有
API 调用 ⚠️ –post-data ✅ -X -d
SFTP/SCP ❌ ✅
SMTP/IMAP ❌ ✅
商用友好 ⚠️ GPL ✅ MIT
库嵌入 ❌ ✅ libcurl
新版本活跃度 ⚠️ 较慢 ✅ 活跃
学习曲线 🟢 简单 🟡 略陡
七、给软件工程师的最终建议
维度 建议
主力工具 🟢 curl（协议广、管道友好、行业标准）
辅助工具 🟢 wget（大文件下载、镜像、续传）
写脚本 🟢 优先 curl（除非要递归下载）
个人习惯 两者都学，按场景选
Shell 学习路径 1. 学会 curl 基础 2. 学会 curl -X POST 3. 学会 curl -H/-d/-u 4. 学会 wget -c/-r
八、一句话总结
wget 是 “下载器”—— 专一下载，默认存文件，递归镜像强；curl -o 是 “数据传输瑞士军刀”——30+ 协议，管道友好，libcurl 是行业标准。 简单下载两个都行；写脚本、API 调试、多协议用 curl；整站镜像、大文件续传、批量下载用 wget。给软件工程师建议：主力 curl（写脚本 / API 调试），辅以 wget（大文件 / 镜像 / 批量）。两者不冲突，按场景切换即可。