CI/CD中执行composer install前必须设COMPOSER_MEMORY_LIMIT
默认情况下，Composer在内存受限的CI环境（如GitHub Actions默认7GB、GitLab Shared Runner常为4GB）容易因OOM被kill，报错类似Killed或PHP Fatal error: Allowed memory size exhausted。这不是PHP配置问题，而是Composer自身加载依赖图时的峰值内存占用高。
实操建议：
- 在CI脚本开头统一设置：
export COMPOSER_MEMORY_LIMIT=-1（禁用限制）或export COMPOSER_MEMORY_LIMIT=2G（显式指定） - 不要依赖
php -d memory_limit=-1 composer install——部分CI镜像中PHP CLI的memory_limit对Composer进程不生效 - 若用Docker，确保基础镜像PHP配置未硬编码限制（检查
php -i | grep memory_limit）
为什么composer install --no-dev不能省略？
CI构建产物（如打包成phar、生成部署包、构建Docker镜像）应只含运行时依赖。--no-dev不只是提速，更是安全边界：dev依赖里的工具（如phpunit、infection）可能引入未审计的远程调用、调试后门或过时漏洞。
常见错误场景：
- 本地
composer.json里require-dev包含symfony/var-dumper，上线后意外暴露dump()调用导致敏感数据泄露 - CI误用
composer update而非install，导致composer.lock被意外修改，破坏可重现性 - 未加
--optimize-autoloader和--classmap-authoritative，导致生产环境autoload慢30%+（尤其Laravel/Symfony项目）
私有包拉取失败？关键在auth.json注入方式
CI环境无法交互输入GitHub/GitLab Token，必须预置凭证。但直接提交auth.json到仓库是严重安全风险。
