启用 security.signature + 仅代理元数据 + 强制 https 才安全,否则 composer install 静默跳过完整性校验;config -g repo.packagist 易因拼写、格式、结尾/缺失等细节失效且无提示。

直接换镜像源不等于安全,必须启用 security.signature + 仅代理元数据 + 强制 HTTPS,否则 composer install 会静默跳过包完整性校验。
为什么 composer config -g repo.packagist 常被误用
这条命令看似简单,但写错任意一个细节就完全失效,且 Composer 不报错、不提示,只默默 fallback 到 https://packagist.org:
-
repo.packagist不能写成repos.packagist(多一个s就被忽略) - 第二个参数必须是字面量
composer,不是注释,不能省略或替换成vcs/package - URL 必须以
/结尾,否则路径拼接错误(如/composerpackages.json),触发 404 后降级 - 协议必须是
HTTPS;HTTP地址在 Composer 2.x+ 默认被拒绝,除非显式关闭secure-http(不推荐)
企业级安全配置的三步实操
目标:元数据(packages.json 等)走国内 HTTPS 镜像加速,包文件(.zip/.tar)仍由官方签名链验证,不绕过任何校验环节。
工作流任务拆解与模型编排技能。使用场景:(1) 收到复杂工作任务需要拆解为可执行步骤,(2) 需要为不同步骤选择最合适的模型,(3) 需要跟踪工作流进度和模型使用情况,(4) 长时间任务卡住需要问题诊断和解决方案。
- 禁用默认兜底源:
composer config -g repos.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
验证是否生效:composer diagnose 输出中必须同时出现 secure-http: OK 和 signature verification: OK。只看到前者,说明签名没真正启用。
项目级配置比全局更可靠,尤其在 CI/宝塔/Docker 场景
全局配置在多用户环境(如宝塔的 www 用户)下常因权限问题失效。项目级配置写进 composer.json 的 repositories 字段,Git 可追踪、CI 可复现、优先级更高。
- 确保
composer.json中repositories是对象格式:"repositories": {},不是空数组[] - 执行:
composer config repo.packagist composer https://repo.huaweicloud.com/repository/php/(去掉-g) - 它会自动插入类似结构:
{"packagist.org": false}, {"type":"composer", "url":"https://repo.huaweicloud.com/repository/php/"} - 已有私有仓库(如
"type": "vcs")不会被覆盖,但packagist条目必须在数组最前,否则可能被忽略
容易被忽略的硬性前提
安全镜像不是“配完就完”,以下三点不满足,整个链条就断了:
-
composer.lock文件会固化旧的包地址和哈希值;换源后首次install失败或校验不通过,必须删掉vendor/和composer.lock重来 - 华为云、阿里云等镜像地址必须用当前维护的 URL:
https://repo.huaweicloud.com/repository/php/(不是mirrors.huaweicloud.com,后者已 404) - 所有镜像 URL 必须带末尾
/,这是拼接packages.json路径的硬编码规则,漏掉就失效,且无日志提示










