wget下载需显式用-O指定文件名防乱码或通配符问题，HTTPS需--no-check-certificate临时跳过证书验证，-c续传仅在服务器返回206且本地文件存在时生效，批量下载应使用xargs -P并发而非串行。
直接用 wget 就能下，但多数人第一次跑就卡在文件名、覆盖、证书或重定向上——不是命令不对，是默认行为和现实场景不匹配。
下载带查询参数的 URL 时文件名乱码或含问号
比如 wget https://example.com/file.zip?token=abc，实际保存为 file.zip?token=abc，Linux 下问号是通配符，后续 ls 或脚本会出错。
- 必须用
-O显式指定输出名：wget -O file.zip https://example.com/file.zip?token=abc - 如果想自动推断主文件名（去掉参数），
wget本身不支持，得靠 shell 处理，例如：wget -O "$(basename 'https://example.com/file.zip?token=abc' | cut -d'?' -f1)" 'https://example.com/file.zip?token=abc' - 注意：
-nc（no-clobber）不能和-O同时用，否则报错；要防覆盖，得自己test -f file.zip || wget -O file.zip ...
HTTPS 下载失败：证书不可信或重定向后文件名丢失
常见错误信息：ERROR: cannot verify example.com's certificate，或下载完发现是 index.html.1 而不是预期的 PDF。
- 内网/测试环境临时跳过证书检查，加
--no-check-certificate，但生产环境绝不能用 - 重定向导致文件名丢失，是因为服务器没返回
Content-Disposition头；此时-O是唯一可靠解法，别指望wget自动猜 - 某些 CDN 或反向代理对
User-Agent敏感，加--user-agent="Mozilla/5.0"可绕过拦截
大文件中断后续传失败，但命令看起来没错
wget -c 不是万能的——它只在服务器支持 Range 请求时才生效。GitHub Pages、Netlify、很多静态托管服务默认不支持，续传会静默退回到 0%，而不是报错。
- 先确认服务器是否支持：
curl -I -H "Range: bytes=0-99" https://example.com/large.bin，若响应含206 Partial Content才真支持 - 不支持时，
-c没用，得换方案：用aria2c或分段下载脚本 - 即使支持，也要确保本地已有同名文件且大小 > 0；空文件或权限不对（如只读）会导致续传失败
批量下载多个文件却慢得像单线程
wget -i list.txt 是串行执行，一个接一个，网络空闲率高，耗时翻倍。
- 用
xargs并发最稳妥：cat list.txt | xargs -n1 -P4 wget -q（-P4表示最多 4 个并发） -
-q必须加，否则各进程日志混在一起，失败了都找不到是哪条 URL 出问题 - 别用
wget -b启一堆后台任务：日志分散、无并发控制、容易触发目标站限速甚至封 IP
真正麻烦的从来不是命令记不住，而是服务器返回的 HTTP 状态、头字段、CDN 行为这些看不见的东西——wget 不报错，不代表它做对了。
