工具与资源daniel.haxx.se
Curl 与 Wget 的对比（curl 作者亲述）
Curl vs. Wget
2010 — 2016，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
curl 作者 Daniel Stenberg 撰写的经典对比文，从起源、功能到设计理念逐条梳理 curl 与 wget 这两个命令行下载工具的异同。文章的结论是两者定位不同——wget 偏向交互式下载和网站镜像，curl 更像带命令行前端的通用 HTTP 工具——并非非此即彼的竞争关系。
为什么经久不衰：命令行下载工具该用哪个的争论多年不休，这篇由 curl 作者亲自执笔的对比客观厘清了两者定位，至今仍是回答这个问题时最常被引用的参考。
HN 评论精选
wget 适合交互式下载，curl 适合脚本开发，两者各有所长，无需二选一。
就我的用法而言：wget 是面向最终用户的交互式工具，只想下载个文件时我首选它——默认设置更合理，命令行用法更直观，文档组织更好，还能断点续传，curl 做不到。curl 则是开发者工具——写需要下载功能的 shell 脚本时我会用它，默认更符合 Unix 风格（输出到 stdout），选项更灵活，而且预装在更多系统上（macOS 自带 curl 却不带 wget）。这没必要变成“emacs vs. vim”式的对立：两者各有所长，完全可以在同一个工作流里共存。
JonathonW查看英文原文
For my usage: * Wget's the interactive, end-user tool, and my go-to if I just need to download a file. For that purpose, its defaults are more sane, its command line usage is more straightforward, its documentation is better-organized, and it can continue incomplete downloads, which curl can't. * Curl's the developer tool-- it's what I'd use if I were building a shell script that needed to download. The command line tool is more unix-y by default (outputs to stdout) and it's more flexible in terms of options. It's also present by default on more systems-- of note, OSX ships curl but not wget out of the box. Its backing library (libcurl) is also pretty nifty, but not really relevant to this comparison. This doesn't really need to be an "emacs vs. vim" or "tabs vs. spaces"-type dichotomy: wget and curl do different things well and there's no reason why both shouldn't coexist in one's workflow.
wget 镜像文档很好用且默认处理重定向；curl 配合 jq 则适合调试 REST 接口。
我最喜欢 wget 的用途：把网页文档镜像到本地。wget -r -l5 -k -np -p https://docs.python.org/2/ 它会把链接改写为本地路径（无法本地化的仍指向在线文档），浏览起来非常顺畅。一般文件下载我也更愿意用 wget 而非 curl -O，因为 wget 默认处理重定向，curl -O 不会——当然我可以再记一个 curl 参数……但何必呢？不过调 REST 接口时我还是爱用 curl（配合 jq）。
falcolas查看英文原文
My favorite use of wget: mirroring web documentation to my local machine. wget -r -l5 -k -np -p https://docs.python.org/2/ Rewrites the links to point local where appropriate, and the ones which are not local remain links to the online documentation. Makes for a nice, seamless experience while browsing documentation. I also prefer wget to `curl -O` for general file downloads, simply because wget will handle redirects by default, `curl -O` will not. Yes, I could remember yet another argument to curl... but why? That said, I love curl (combined with `jq`) for playing with rest interfaces.
curl 的错误码适合写脚本（尤其 cron 任务），wget 胜在简单，适合手动下载。
我的做法：bash 脚本一律用 curl，命令行手动下载用 wget。curl 输出的错误码让它在写脚本时非常强大——尤其是跑在 cron 里的任务，失败时你能知道原因。wget 胜在简单，在 shell 里手动下载我总是用它。唯一会在脚本里用 wget 的情况，是写个简单的爬虫。
mikeytown2查看英文原文
What I do * curl for any bash scripts * wget for downloading via command line The error codes that curl output make it very powerful when creating a script. Something that gets run on cron & you want to know why it failed if it did. Wget is simple, and for a shell it's what I always turn to. The only time I would use wget in a script is if I was making some sort of simple web crawler script.
curl 默认向 stderr 输出进度统计，管道使用时很碍事，默认应像 curl -s -S 那样静默。
我对 curl 的主要不满是它默认往 stderr 打一堆乱七八糟的东西（严格说是统计信息）。对一个号称“传统 Unix 风格”的工具来说，这似乎不太应该。执行 curl $URL | less 时，分页器里会混进垃圾信息，很烦。默认行为应该更像 curl -s -S——静默，但出错时打印错误，就像其他所有正常的命令行工具一样（我的 curl 别名就是这么设的）。wget 当然也打印统计信息，但正如作者所说，它不是那种“面向管道”的工具，所以问题不大。
1amzave查看英文原文
My main complaint about curl is that it prints a bunch of crap (well, statistics technically) to stderr by default. Especially for something claimed to be (at least in this article) "traditional unix style", that seems undesirable. It's annoying when I do 'curl $URL | less' and end up with garbage in my pager that I have to scroll around a bit to make disappear. It seems like default behavior should be more like 'curl -s -S' -- silent, but print errors if they occur, just like...well, every other sensible command-line tool in the world (so that's what I have curl aliased to). wget of course prints statistics too, but it's not such "pipe-oriented" tool, as the author points out, so this isn't as big of a deal.
历次讨论
同类还值得读
直接在浏览器中启动 Linux 内核
Boot a linux kernel right inside your browser.
Fabrice Bellard 的 JSLinux 页面，用 JavaScript 在浏览器里启动一个 Linux 内核，并提供一个可交互的终端环境。
工具与资源上首页 5 次 · 2011–2025bellard.orgHacker News 未公开功能与行为清单（2018）
A List of Hacker News's Undocumented Features and Behaviors (2018)
数据科学家 Max Woolf 整理的 Hacker News 未公开功能与行为清单，涵盖投票机制、排名算法、账号惩罚等社区运作细节。
工具与资源上首页 5 次 · 2019–2025github.comMapSCII：在终端中用盲文和 ASCII 渲染地图
MapSCII – Braille and ASCII map renderer for the console
MapSCII 是一个在命令行终端里渲染地图的开源工具，用盲文字符和 ASCII 字符把地理数据画成可交互浏览的字符地图。
工具与资源上首页 5 次 · 2017–2025github.com顶尖大学的免费在线课程
Free Online Courses from Top Universities
Open Culture 整理的一份免费在线课程合集，汇集了全球顶尖大学（如 MIT、斯坦福、耶鲁等）向公众开放的网络课程资源，涵盖音频、视频等多种形式。
工具与资源上首页 5 次 · 2010–2022openculture.com淘气字符串：容易引发用户输入问题的字符串清单
Naughty Strings: A list of strings likely to cause issues as user-input data
一个 GitHub 仓库，收录了大量容易让程序出问题的用户输入字符串，如特殊字符、emoji、SQL 注入片段、系统命令等，供开发者用于测试输入处理逻辑。
工具与资源上首页 4 次 · 2015–2020github.com