生产环境必须用composer install --no-dev --optimize-autoloader，否则会引入dev包引发安全风险，且未优化自动加载导致I/O开销高；镜像配置需严格满足repo.packagist键名、composer类型、HTTPS末尾带/三要素，缺一即静默回退至官方源。
生产环境部署慢，八成卡在 composer install，不是网络差，也不是代码问题，而是镜像没配对、参数漏了、缓存没清——三者缺一，提速就成空谈。
为什么默认 composer install 在生产环境一定不能用
不加任何参数的 composer install 会装 require-dev 里的包（比如 phpunit、symfony/debug-bundle），这些在生产环境完全无用，还可能引入安全风险或冲突；更关键的是自动加载器没优化，每次 class_exists() 或 new 一个类都要遍历一堆文件路径，PHP 反复 stat()，I/O 开销明显。
-
--no-dev：跳过require-dev，删掉 dev-only 的 autoload 规则（比如 psr-4 到tests/） -
--optimize-autoloader（简写-o）：把 PSR-4/PSR-0 映射转成静态数组，生成vendor/composer/autoload_classmap.php，跳过文件扫描 - 二者必须同时用；只用
--no-dev不优化，autoload 还是慢；只用--optimize-autoloader不去 dev 包，反而让 classmap 更大
怎么配中文镜像才真正生效
composer config -g repo.packagist 看似简单，但错一个字符就静默回退到 https://packagist.org，且完全不报错：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
repo.packagist不能写成repos.packagist（多一个 s 就彻底失效） - 必须显式带上
composer这个type值：composer config -g repo.packagist composer https://mirrors.cloud.tencent.com/composer/ - URL 必须是 HTTPS 且末尾带
/：https://mirrors.cloud.tencent.com/composer/✅，https://mirrors.cloud.tencent.com/composer❌ - 漏掉
-g就只改当前项目，换目录即失效 - 验证是否成功：运行
composer config -g repo.packagist，输出必须是完整 JSON，形如{"type": "composer", "url": "https://mirrors.cloud.tencent.com/composer/"}。空、null、或仍显示官方地址，说明没写进去
CI/CD 部署脚本里怎么写才可靠
部署脚本里不能依赖本地 composer.lock 是否存在或是否最新——CI/CD 流水线里常出现 lock 文件没提交、或开发机上手动 run 了 composer update 却没 commit 导致线上行为不一致。
- 务必先
git checkout到目标 tag/branch，再执行composer install，确保 lock 文件和代码版本匹配 - 加
--no-interaction（简写-n）避免卡在 prompt（比如问是否启用 plugin） - 加
--prefer-dist：优先下 zip 包而非 git clone，更快更稳定（尤其网络差时） - 完整命令建议：
composer install --no-dev --optimize-autoloader --no-interaction --prefer-dist - 如果部署机没装 Composer，别用
curl -sS https://getcomposer.org/installer | php动态下载——有中间人风险；应提前打包好composer.phar并校验 SHA256
Resolving dependencies 卡住怎么办
镜像只加速下载，不加速依赖解析。这个阶段卡住，和网络无关，典型原因有：
-
composer.json里写了过宽的 PHP 版本约束，比如"php": "^7.4 || ^8.0 || ^8.1"，触发求解器暴力穷举 - 存在
"minimum-stability": "dev"，强制拉取不稳定分支，候选版本爆炸 -
composer.lock被删或未提交，install实际退化为update -
repositories字段指向了已下线的私有源，Composer 逐个超时才 fallback - 快速排查：进项目根目录，执行
composer config --list | grep repositories看实际生效源；再跑composer validate --strict确认 lock 文件合法
最易被忽略的一点：即使镜像、参数、缓存全配对，composer.lock 和代码不同步，或者 minimum-stability 设为 dev，整个优化就前功尽弃——解析阶段卡住，你连下载都等不到。
