CI/CD 中直接运行 composer install 不安全，因其默认执行脚本、等待交互、静默触发不可控 audit；应拆解为 --no-scripts --no-interaction 安装、独立 audit、autoload 验证等可控步骤。
CI/CD 中直接跑 composer install 很容易因脚本、交互或安全检查失控——真正安全的执行必须拆解控制点，而不是依赖“一键命令”。
为什么默认的 composer install 在 CI 里不安全
它默认会做三件你未必想要的事：执行 post-install-cmd 等脚本（可能含任意命令）、等待交互确认（CI 无 TTY 时行为异常）、自动触发 --audit（但不支持参数，退出码不可控）。这些在本地开发中是便利，在流水线里就是风险源。
- 脚本可能调用
php artisan或npm run build，而这些命令依赖未声明的环境变量或二进制，导致静默失败或路径污染 -
--audit在 Composer ≥2.5 且全局启用了experimental.audit时会静默触发，但只输出表格、不支持--severity=critical，一条 low 级 advisory 就让构建失败 - 没加
--no-interaction时，某些插件（如symfony/flex）会卡在“是否启用 recipe”提示上，整个 job 挂起超时
必须显式禁用脚本和交互
用 composer install --no-scripts --no-interaction 是基线操作，不是可选项。
-
--no-scripts跳过所有scripts字段定义的钩子（post-install-cmd、pre-autoload-dump等），但不影响vendor/autoload.php生成 -
--no-interaction（或-n）确保不卡住，同时让 Composer 使用默认策略（比如跳过缓存清理建议、不询问 autoload 优化） - 注意：
--no-scripts不等于--no-autoloader；后者会连autoload.php都不生成，项目直接无法启动 - 别指望
COMPOSER_NO_SCRIPTS=1环境变量生效——Composer 不识别它，必须显式传参
安全卡点要单独、可控地运行 audit
composer install --audit 是个误导性快捷方式，不能当安全门禁用。
- 它不接受任何
composer audit支持的参数，比如--severity=critical,high或--format=json - 退出码逻辑粗暴：只要发现任意 advisory（包括已废弃包提示），就返回非零，CI 直接中断
- 真实做法是分两步：
composer install --no-scripts --no-interaction --no-dev --prefer-dist→composer audit --severity=critical,high --no-dev --with-dependencies --timeout=30 --format=json - 如果用了私有镜像源，得确认它同步了
security-advisories数据，否则Could not fetch advisories会静默失败，audit 变成摆设
生产部署还要砍掉 dev 依赖和优化加载
CI 构建产物若用于生产镜像，漏掉这几个参数等于把测试工具打进线上环境。
-
--no-dev必须加：否则phpunit、phpstan等全进vendor/，增大镜像体积、增加攻击面 -
--optimize-autoloader和--classmap-authoritative一起用：前者生成 classmap 提速，后者禁止 fallback 到文件扫描，杜绝类名拼写错误被“兜底”掩盖 - 缓存策略优先选全局 cache（
~/.composer/cache），比缓存vendor/更稳定——vendor 受composer.json和lock双重影响，微小变更就会失效 - 末尾加一句验证：
php -r "require 'vendor/autoload.php'; echo 'OK';"，能早于应用启动发现 autoload 断链
最常被忽略的一点：安全不是靠某个参数兜底，而是靠拆解——把安装、脚本、审计、验证拆成独立步骤，每步可控、可调试、可单独开关。流水线里多写一行命令，远比事后追查“为什么线上类找不到”省事。
