composer config -g repo.packagist会放大劫持风险，因其彻底替换官方源，导致跳过packagist.org提供的signature字段校验；国内镜像不生成/透传签名，污染或延迟时将静默安装篡改包。
直接换镜像源不防劫持，反而可能绕过签名校验，让恶意包畅通无阻。
为什么composer config -g repo.packagist会放大风险
执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/会彻底替换官方源，导致 Composer 完全跳过 signature 字段校验——而该字段只由 packagist.org 在 HTTPS 响应中提供。国内镜像（包括阿里云、腾讯云）不生成也不透传 signature，一旦镜像缓存被污染或同步延迟，composer install 就会静默拉下篡改过的 ZIP 包。
- 现象：CI 构建通过，但线上运行时出现未预期的
post-install-cmd执行、vendor/中文件哈希不匹配 - 本质：镜像只是 HTTP 缓存代理，不是可信签名锚点
- 关键区别：
repos.packagist（元数据代理）≠repo.packagist（源替换）
如何启用真正防劫持的 HTTPS 镜像配置
必须保留 packagist.org 的语义和签名能力，仅将元数据请求（packages.json 等）走镜像，包文件（.zip）仍由官方 CDN 提供并校验。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 关闭旧式源替换：
composer config -g repo.packagist false - 启用元数据镜像：
composer config -g repos.packagist.type composer，再执行composer config -g repos.packagist.url https://mirrors.aliyun.com/composer/ - 强制签名验证：
composer config -g security.signature true - 确保 HTTPS 强制开启：
composer config -g secure-http true（默认已开，禁用即高危） - 验证生效：
composer diagnose输出中必须同时出现secure-http: OK和signature verification: OK
composer.lock 不是摆设，而是离线防劫持的最后一道闸
只要 composer.lock 完整且提交进 Git，composer install 就完全不发网络请求——它只从 ~/.composer/cache/files 读取 ZIP 并比对 dist.shasum。镜像宕机、DNS 劫持、中间人攻击，全被挡在门外。
- 必须把
composer.lock提交进版本库，禁止出现在.gitignore中 - CI 流程中挂载并复用
~/.composer/cache（如 GitHub Actions 使用actions/cache缓存该路径） - 生产部署加
--no-plugins --no-scripts --no-dev，避免任何 hook 执行干扰哈希校验 - 临时极端情况可
composer install --dry-run --verbose检查所有 dist 包是否与 lock 中哈希一致
最容易被忽略的三个协同点
配了阿里云镜像 ≠ 防劫持；开了 secure-http ≠ 防篡改；有 composer.lock ≠ 自动免疫。三者必须同时生效：
-
repos.packagist配置 +security.signature true决定是否校验 signature -
composer.lock是否存在且未被手动修改，决定是否跳过网络请求 - CI 是否复用
~/.composer/cache，决定离线安装能否真正完成
少一个，镜像一延迟、一污染、一超时，构建就失败或带毒上线。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
