必须执行composer config -g repo.packagist确认输出为https://mirrors.aliyun.com/composer/等国内镜像url，为空或仍显示packagist.org说明未生效；ci中需用--no-dev --prefer-dist --optimize-autoloader --classmap-authoritative等参数组合，并缓存~/.composer/cache而非vendor。
CI/CD里Composer慢，根本不是网络差，而是镜像没生效、缓存路径错、安装参数漏——三者任缺其一，提速就失效。
怎么确认repo.packagist镜像真写进运行环境了
CI脚本里执行composer config -g repo.packagist，输出必须是类似https://mirrors.aliyun.com/composer/的URL。如果为空、null或仍是https://packagist.org，说明配置没落到实际执行命令的用户家目录下。
- 用
sudo composer config -g很可能写进了root的~/.composer/config.json，但CI runner以普通用户（如runner）身份运行，读不到 - 拼错字段名（比如写成
repos.packagist多一个s）会静默失败，查出来还是空 - 验证是否真走镜像：加
-vvv跑composer install，日志里出现GET https://mirrors.aliyun.com/composer/p2/...才算成功
为什么vendor/不能缓存，而~/.composer/cache必须缓存
缓存vendor/看似快，实则危险：不同PHP版本、扩展开关（如ext-apcu）、甚至OS大小写敏感性，会导致生成的autoload文件不兼容，随机报Cannot declare class或Class not found。
-
~/.composer/cache只存dist包和元数据，与运行环境完全解耦，只绑定composer.lock哈希 - GitHub Actions示例：
path: ~/.composer/cache，key里必须含${{ hashFiles('**/composer.lock') }} - GitLab CI写
cache: paths: [- ~/.composer/cache]，别写vendor/或~/.composer整目录 - 缓存失效最常见原因：本地生成了新
composer.lock但没提交，导致key不匹配，CI每次冷装
composer install在CI中必须带哪些参数
CI部署命令不是“能跑就行”，而是要兼顾速度、一致性与生产可用性。漏掉任意一个，都可能在线上引发autoload性能问题或不可重现构建。
-
--no-dev：排除开发依赖，减小体积，避免测试工具污染生产环境 -
--prefer-dist：强制走zip包而非git clone；但前提是镜像已生效——否则fallback到source会卡死或失败 -
--optimize-autoloader：把PSR-4映射编译为静态数组，跳过运行时解析 -
--classmap-authoritative：告诉autoloader“不在classmap里的类一律不存在”，彻底禁用file_exists()试探 -
--no-interaction：防止因交互提示卡住（尤其在无TTY的容器里）
项目级镜像配置比全局配置更可靠
在项目根目录执行composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/，会安全追加到composer.json的repositories字段，不覆盖已有私有源。
- 适合CI场景：配置随代码提交，所有人行为一致，避免不同镜像混用导致
composer.lock哈希漂移 - 如果
composer.json里已有"repositories": []（数组），命令会报错；得先手动改成"repositories": {}（对象）再执行 - 别手写
"packagist.org": false——这会彻底关掉官方源，镜像临时不可用时，composer install直接失败 - 换源后首次install若报hash校验失败，删掉
vendor/和composer.lock重来即可
真正难的不是配命令，而是让每个环节都对齐：镜像源生效路径、缓存命中条件、参数组合的语义边界——漏掉任意一层，提速就断在半路。
