Composer源合法需同时满足三条件：保留官方源地址、启用签名验证、镜像仅代理HTTPS元数据；composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/危险，因彻底替换源并绕过signature校验，导致供应链完整性丧失。
Composer 安装源不合法，不是“连不上”或“慢”，而是你根本不知道自己正在从哪下载代码——默认的 packagist.org 不强制 HTTPS、无签名、无校验；国内镜像若配置不当，会直接绕过所有安全验证。真正确保源合法，必须同时满足三件事：保留官方源地址、启用签名验证、仅让镜像代理元数据（且走 HTTPS）。
为什么 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 是危险操作
这条命令看似加速，实则彻底替换官方源，导致 Composer 自动跳过 signature 字段校验——因为阿里云、腾讯云等镜像不提供该字段。一旦镜像缓存被污染（如中间人劫持 HTTP 响应），vendor/ 里拉下来的包就是篡改过的。更隐蔽的是：它不会报错，composer install 照常成功，但你已失去供应链完整性底线。
正确做法是保留官方源语义，只代理元数据请求：
- 执行
composer config -g repos.packagist.type composer（声明 packagist 是 composer 类型源） - 再执行
composer config -g repos.packagist.url https://mirrors.aliyun.com/composer/（仅让 packages.json 等元数据走镜像） - 包文件（.zip/.tar）仍从官方或带校验的 CDN 下载，签名验证链不中断
如何确认签名验证已真正生效
composer config -g security.signature true 只是开关，不等于验证在跑。必须用 composer diagnose 实际检测输出：
- 看到
secure-http: OK表示 HTTPS 强制启用（禁用http://源） - 看到
signature verification: OK才代表 Packagist 官方签名字段被读取并校验 - 如果只有前者没有后者，说明镜像配置仍绕过了签名——检查是否误用了
repo.packagist而非repos.packagist
注意：security.signature-verification 是无效配置项，Composer 官方无此参数；混淆它会导致你以为开了验证，其实什么都没做。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer install 时哪些行为会悄悄关闭校验
很多 CI 脚本为了“快”或“稳”，无意中关闭了关键校验：
-
--prefer-source：走git clone，完全跳过dist.sha256校验和签名验证 -
--no-scripts --no-plugins：虽不影响哈希比对，但若插件参与了 post-install-cmd 中的完整性检查（如自定义钩子），就漏掉了最后一道人工兜底 - 手动删
vendor/后运行composer install --no-interaction：没问题；但若加了--ignore-platform-reqs，可能跳过 PHP 版本约束校验，间接允许不兼容（甚至被投毒）的旧版包混入
生产环境 CI 应固定使用：composer install --no-interaction --no-scripts --no-plugins，再紧接 composer audit --severity=high --severity=critical --no-dev。前者保安装一致性，后者补漏洞卡点。
为什么不能依赖 composer.lock 的 sha256 就认为安全
composer.lock 里的 dist.sha256 确实能防传输篡改，但它有硬伤：
- 只校验 dist 包（ZIP/TAR），对
--prefer-source或 path/vcs 仓库完全失效 - 哈希值本身可被恶意修改——只要攻击者能提交 PR 修改 lock 文件，后续 install 就照着假哈希去比对
- 它不验证发布者身份，无法区分“作者发的 v2.1.0”和“攻击者冒充作者发的同名 v2.1.0”
所以 lock 文件必须进 Git，且每次 composer update 后需人工确认变更是否合理；高敏感项目应在 CI 中加一步：用 composer show --locked --format=json 提取所有 dist.sha256，再调外部工具（如 shasum -a 256）比对 vendor/ 下对应路径的实际哈希——别省这一步，尤其当 lock 文件来自不可信分支时。
