必须验证镜像源是否生效：运行composer config -g repo.packagist，输出须为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null或仍为packagist.org即未生效，后续优化均无效。
导出（composer install 或 composer update）慢，核心瓶颈不在“导出”本身，而在于依赖解析、网络下载、自动加载生成和脚本执行这四个环节。优化不是堆参数，而是按阶段精准干预。
怎么确认当前镜像源是否生效
镜像没切对，后面所有优化都白搭。别只看命令有没有报错，得验证实际请求域名：
- 运行
composer config -g repo.packagist，输出必须是类似{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}—— 如果是空、null或仍是https://packagist.org，说明没生效 - 旧版 Composer（1.x）不认
repo.packagist，得用：composer config -g repos.packagist '{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}' - 项目级
composer.json里写了repositories？它会覆盖全局配置，此时要删或改掉 - 加
-vvv跑一次composer install，日志里出现的下载地址必须含mirrors.aliyun.com或proxy.fly.dev才算真走镜像
为什么换了镜像还卡在 Resolving dependencies
这个阶段完全不走网络，卡住是 PHP 层面的问题：
-
memory_limit太低（比如 128M），依赖图一复杂就反复重试 —— 临时加COMPOSER_MEMORY_LIMIT=-1测试 - 启用了
xdebug（php -v看输出），会让解析慢 5–10 倍 —— 改用php -d xdebug.mode=off $(which composer) install临时禁用 -
platform配置与真实 PHP 版本不匹配（如"php": "7.4"却在 PHP 8.2 上跑），触发降级查找逻辑 -
composer.lock里残留已下线包的引用，导致回退搜索失败 —— 删掉vendor/和composer.lock，再composer install --no-cache
生产环境 install 必须带的四个参数
少一个，线上就可能报错或冷启动变慢：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
--no-dev：跳过require-dev包，避免它们污染 classmap 或意外启用调试逻辑 -
--optimize-autoloader（或-o）：生成vendor/composer/autoload_classmap.php，把 PSR-4 映射转为静态路径条目 -
--classmap-authoritative（或-a）：强制 autoloader 只查 classmap，彻底禁用file_exists()和目录遍历 —— 这是提速核心 -
--no-interaction：避免 CI/CD 或 Docker 构建时因无 TTY 卡在 license 确认等交互提示
注意：dump-autoload -o 在 Composer 2.0+ 中只是轻量刷新，不能替代 install 阶段的完整扫描；漏了 --classmap-authoritative 却又报 Class not found，大概率是类文件命名空间写错、路径末尾缺反斜杠，或误把 tests/ 目录塞进了 autoload 块。
CI/CD 和 Docker 构建中容易被忽略的点
本地快不代表上线快，CI 环境有自己的一套陷阱：
- 缓存
~/.composer/cache比缓存vendor/更重要 —— 后者体积大、易冲突，前者复用率高、校验强 - 务必加
--no-autoloader --no-scripts --no-plugins：跳过生成 autoload 文件、跳过post-install-cmd（比如前端构建）、跳过插件初始化，省掉 35%+ 时间 -
--no-autoloader后需补composer dump-autoload --optimize，否则 PHP 直接报错 - 别再装
hirak/prestissimo—— 它在 Composer 2.x 中已失效，还可能静默降级为单线程 -
parallel-downloads已弃用，正确配置是composer config -g http-max-concurrent-downloads 10
真正卡住的地方，往往不是下载速度，而是 autoload_classmap.php 生成或 post-install-cmd 里的 artisan optimize —— 这些都是单进程、无法并行、且没人监控的黑洞。
