必须用composer install而非update：团队协作、ci/cd及上线部署时，只要存在composer.lock就应无条件使用install，严格按lock文件还原依赖；同时必须搭配--no-dev、-o、--classmap-authoritative参数确保生产环境一致性与性能。
什么时候必须用 composer install 而不是 composer update
团队协作中，只要项目存在 composer.lock 文件，就该无条件用 composer install。它不计算版本、不试探兼容性，只按 lock 文件逐字还原依赖树——这是环境一致性的唯一保障。
常见误用场景：
- 新成员克隆项目后直接跑
composer update，结果装了一堆新版包，和 CI 构建失败不一致 - CI 流水线里写
composer update --no-dev，看似省事，实则绕过 lock 文件，部署包可能和本地测试环境不同 - 线上部署脚本漏掉
--no-dev，把phpunit和phpstan打进生产镜像
composer install 必须搭配的参数组合
单独敲 composer install 在团队项目里基本等于裸奔。真实生产/CI 场景下，这几个参数几乎总是成组出现：
-
--no-dev：跳过require-dev下所有包，不是“建议”，是硬性要求 -
--optimize-autoloader（或-o）：生成 classmap，避免运行时遍历文件，autoload 性能提升 3–5 倍 -
--classmap-authoritative：配合-o使用，告诉 autoloader “类只在 classmap 里找”，彻底关闭 PSR-4/PSR-0 的文件扫描 -
--ignore-platform-reqs：仅限调试环境临时绕过 PHP 版本或扩展检查，严禁提交到 CI 或上线脚本
典型 CI 命令：composer install --no-dev -o --classmap-authoritative
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
为什么 composer install 有时卡住或报错
报错不是命令本身有问题，而是 lock 文件和当前环境不匹配。最常遇到的三种情况：
-
Could not find package xxx at version yyy：lock 文件里记录的版本已被作者从 Packagist 下架，或你配置的私有源暂时不可达 - PHP 版本不满足：lock 文件中某依赖声明
"php": "^8.2"，而服务器是 PHP 8.1 —— 此时install直接退出，不会降级适配 - 网络超时或镜像失效：国内访问 Packagist 官方源不稳定，必须提前统一配置镜像源，例如：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
排查时加 -v 参数看详细日志，能快速定位卡在哪一个包的下载或校验环节。
CI/CD 中执行 composer install 的关键细节
CI 环境不是本地开发机，少一个参数就可能让构建成功但运行失败：
- 必须确保
composer.lock已提交且未被 .gitignore 过滤（常见坑：有人把 lock 文件加进 ignore 列表） - 禁止在 CI 中执行
composer update后再install—— 这等于把 lock 文件当摆设 - 如果项目用了私有包，CI 必须显式指定
--repository-url，避免读取开发者本地的repositories配置造成污染 - 构建前清掉缓存目录（
composer clear-cache）或确保cache-dir可写，否则旧缓存可能干扰新包安装
真正容易被忽略的是：CI 中的 composer install 必须和本地开发人员执行的命令完全一致 —— 不是“差不多”，而是参数、顺序、甚至 Composer 版本都要对齐。否则 lock 文件就失去了锁定意义。
