启用 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）仍由官方签名链验证，不绕过任何校验环节。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(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路径的硬编码规则，漏掉就失效，且无日志提示
