不建议且不该在 composer 中设置 disable-tls=true，因其并非合法配置项，composer 2.0+ 已彻底移除，实际无效；内网 tls 错误主因是 ca 证书缺失或自签名证书未信任，应导入根证书或临时使用 composer_disable_tls=1 单次绕过。
直接说结论：不建议、也不该在 Composer 中设置 disable-tls=true，哪怕是在内网。
为什么 disable-tls 不是 Composer 的合法配置项
Composer 官方从 2.0 开始彻底移除了 disable-tls 这个配置选项。它从未出现在正式文档中，只在早期开发分支或某些错误博客里被误传。你执行 composer config disable-tls true 看似成功，其实只是把一个无效字段写进了 composer.json 或 auth.json，实际运行时完全被忽略——TLS 依然强制启用，或者更糟：请求直接失败。
- Composer 2.x+ 所有网络请求（包括 packagist.org 和私库）都强制走 HTTPS + TLS 1.2+
-
disable-tls在源码里没有对应逻辑，既不会跳过证书校验，也不会降级到 HTTP - 试图伪造这个配置，反而可能干扰后续调试：你以为关了 TLS，其实根本没生效，问题还在别处
内网私库报 TLS 错误的真正原因和解法
内网环境常见的 Curl error: SSL certificate problem 或 Peer's Certificate issuer is not recognized，根本不是因为“想关 TLS”，而是本地 CA 证书链缺失或私库用了自签名证书。
- 确认私库地址是否真是 HTTPS：如果用的是
http://repo.internal，Composer 会直接拒绝，必须改用 HTTPS（哪怕自签） - 把私库的根证书（.crt 文件）加入系统信任库，Linux 上常用：
sudo cp repo.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates - 或临时指定 CA 包路径：
export COMPOSER_CAFILE=/path/to/repo.crt（注意：不是cafile配置项，是环境变量） - 不推荐用
git config --global http.sslVerify false，这会影响所有 Git 操作，且对 Composer 的 HTTPS 包下载无效
想绕过证书校验？只有两个可控出口
极端调试场景下确实需要跳过验证，但必须明确知道风险，并只作用于当前命令，不污染全局。
- 仅对单次命令禁用：在命令前加环境变量
COMPOSER_DISABLE_TLS=1，例如：COMPOSER_DISABLE_TLS=1 composer require vendor/pkg - 该变量只影响 Composer 自身的 HTTP 客户端，不影响 Git 或其他工具
- 它等价于 curl 的
--insecure，会跳过证书链和域名匹配检查，但连接仍是 HTTPS（即加密通道仍在，只是不验身份） - 不能写进配置文件，也不能设为永久环境变量——每次使用都要显式带上，避免遗忘
最常被忽略的一点：很多所谓“内网 Composer 失败”，其实是 DNS 解析不到私库域名，或反向代理（如 Nginx）没透传 HTTPS 头导致 Composer 误判协议。先抓包看真实请求 URL 和响应状态码，比急着关 TLS 有用得多。
