一、这个参数做了什么

wget 的 --no-check-certificate 会让客户端跳过对服务器证书的校验。原文的描述很准确：wget 仍会与 443 端口建立加密连接，但不执行任何安全检查。

这句话值得拆开看。TLS 握手包含两件事：协商出加密通道，以及验证服务器身份。前者解决"路上别人看不懂"，后者解决"对面是不是真的它"。跳过校验只放弃第二件事——所以数据依然加密，但你无法确认自己有没有连到钓鱼站点或中间人。

二、四种常见用法与各自的适用边界

原文还提到可以把结果另存为指定文件名（下载过期证书站点上的文件并重命名），这类用法常见于脚本化下载。一旦写进自动化流程，就意味着每次运行都在无校验地信任目标站点。

三、为什么"能连上"反而是坏消息

证书报错是浏览器和命令行工具在替你拦一道。绕过它，等于把这道拦截拆掉——攻击者最希望你这么干。

常见误解是"我们内网，不会有中间人"。但中间人不必来自外部：代理服务器、企业网关、运营商劫持、公共 Wi-Fi 的强制门户，都可能插入一张自制证书。校验被关掉后，这些环节都能无痕接管你的连接。

四、更稳妥的四种替代做法

1. 更新根证书库。老系统报错多半是 CA 证书过期，更新后问题自然消失。
2. 把自签名证书加入信任库。开发环境一次性导入，比每次关校验安全得多。
3. 只对特定主机放行。如果工具支持按域配置，把例外范围压到最小，而不是全局关闭。
4. 先验证指纹再下载。自签名场景下，人工核对证书指纹，成本很低。

五、什么时候可以接受

• 本地开发机访问自己的测试服务，且不涉及真实数据；
• 内网一次性排障，事后立即恢复；
• 下载公开的、可校验哈希的静态文件（可用哈希兜底）。

反过来，凡是涉及账号、支付、个人信息、生产数据的请求，都不该走这条路。判断标准不是"能不能连上"，而是"这次连接失败会不会造成数据泄露"。

一句话：这个参数是排障工具，不是部署方案。留在脚本里的 --no-check-certificate，迟早会被某次安全审计揪出来。