“secure-http: false”只是临时诊断手段，不能解决TLS握手失败、SNI拦截或证书链不信任等根本问题；应先用composer install -vvv和curl -I定位真实URL与响应，再修复镜像配置、CA证书或权限问题。
“secure-http: false”不是万能开关，而是临时诊断手段
Composer 默认强制 HTTPS，一旦遇到 file could not be downloaded 或 Connection refused 且日志显示 URL 是 http:// 开头，说明某处配置或镜像源偷偷降级到了 HTTP。但直接执行 composer config -g secure-http false 只是绕过校验，并不解决根本问题——它可能掩盖 TLS 握手失败、SNI 被拦截、或证书链不被信任等真实缺陷。
真正该做的是：
- 先运行
composer install -vvv，观察日志中实际尝试访问的 URL 是什么协议、哪个域名、是否拼接错误（比如镜像 URL 缺末尾斜杠导致变成https://mirrors.aliyun.com/composerpackages.json） - 用
curl -I https://mirrors.aliyun.com/composer/packages.json手动验证该地址能否正常返回200 OK和有效 JSON - 若
curl也失败，检查系统时间是否严重偏差（TLS 依赖准确时间）、是否启用了企业级中间人代理（需额外配置 CA 证书）
镜像源配置写错一个字符就静默失效
Composer ≥ 2.2 对键名极其敏感：repo.packagist（单数）会被完全忽略，必须是 repos.packagist（复数）。更隐蔽的是，只要项目根目录 composer.json 中存在 "repositories": []（哪怕空数组），全局镜像就彻底不生效——此时 composer config -g 的任何设置都白搭。
验证是否真生效的唯一方法是加 -vvv 看日志里出现的域名：
- 看到
https://packagist.org/packages.json→ 镜像没生效 - 看到
https://mirrors.aliyun.com/composer/packages.json→ 镜像已生效
修复方式分场景：
- 全局生效：确保命令是
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/（注意末尾斜杠） - 项目级生效：进项目目录，运行
composer config repos.packagist composer https://mirrors.aliyun.com/composer/ - 删掉项目
composer.json里的"repositories"字段（或清空为null），避免覆盖全局
证书信任链断裂在 Docker/CI 中高频出现
本地能通、CI 流水线却报 cURL error 60: SSL certificate problem，大概率是基础镜像里缺失 CA 证书包。Alpine Linux 尤其典型——它的 ca-certificates 包默认不预装，或版本过旧。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
不同环境修复方式差异很大：
- Alpine 镜像：在
Dockerfile中加apk add --no-cache ca-certificates && update-ca-certificates - Ubuntu/Debian：运行
apt-get update && apt-get install -y ca-certificates - GitHub Actions：用官方
actions/setup-php动作，它会自动处理证书；若自定义 runner，需手动安装ca-certificates
别用 composer config -g secure-http false 一劳永逸——这会让整个依赖下载链暴露在中间人攻击下，尤其当项目含私有包或敏感配置时。
权限错位 + HTTPS 失败 = 双重故障叠加
当 Permission denied 和安全连接失败同时出现，往往是因为之前用 sudo composer install 污染了 vendor/ 或缓存目录，导致当前用户无法读取其中的 HTTPS 证书缓存文件，或 Composer 进程因属主不一致而放弃加载系统 CA。
必须同步处理两件事：
- 修复所有权：
sudo chown -R $USER:$USER $(composer config --global cache-dir) vendor/ - 确认 PHP CLI 加载的
openssl.cafile路径正确：运行php -r "print_r(openssl_get_cert_locations());"，检查default_cert_file是否指向一个可读的有效 PEM 文件 - 如果使用自签名证书或公司内部 CA，需把对应 PEM 文件路径写入
php.ini的openssl.cafile，而非依赖系统默认位置
最易被忽略的是：PHP CLI 和 Web Server（如 Apache/Nginx）可能加载不同的 php.ini，而 Composer 只走 CLI 配置。查错时务必用 php -i | grep 'Loaded Configuration File' 确认实际生效的配置文件路径。
