composer install比update快，因直接读取composer.lock执行确定性I/O操作；update需重跑NP-hard级依赖求解器，耗时且结果不可预测。
composer install 为什么总比 update 快？关键在 lock 文件
因为 composer install 完全跳过版本解析，只读 composer.lock 里记录的精确版本和哈希值，直接下载对应 dist 包或 clone 对应 commit。而 composer update 要重新跑依赖图、做版本约束求解、校验兼容性——这一步耗时且结果不确定。
所以：团队协作、CI 构建、线上部署，必须用 composer install；只有你改了 composer.json 或明确要升级某个包时，才用 composer update。
- 没提交新的
composer.lock就让别人运行composer install？他们装出来的 vendor 和你本地不一致，问题很难复现 -
composer install时如果本地没有composer.lock，它会退化成update行为——报错提示 “lock file not found”，别忽略这个警告 - CI 流水线里建议加
--no-interaction，避免因交互式提示卡住
--no-dev 是生产环境的硬性开关，不是可选优化
漏掉 --no-dev 的后果很实在：线上自动加载器多加载几十个类，内存占用涨 10–20MB，phpunit、phpcs 这些开发工具打进生产镜像，还可能意外暴露 /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php 这类危险入口。
Dockerfile 中常见错误写法：RUN composer install —— 缺少 --no-dev，导致基础镜像臃肿且带风险。
- 正确写法：
RUN composer install --no-dev --optimize-autoloader --classmap-authoritative -
--optimize-autoloader把 PSR-4 映射转成 classmap，减少文件 stat 调用 -
--classmap-authoritative告诉 autoloader：“没在 classmap 里的类，就真的不存在”，彻底关掉 fallback 查找，提速明显
遇到平台要求不匹配（比如 PHP 版本）怎么办？--ignore-platform-reqs 不是万能解药
典型报错：Your requirements could not be resolved to an installable set of packages. + 提示 PHP 版本不满足某依赖的 php: ^8.1 约束。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
--ignore-platform-reqs 确实能绕过检查，但它只是“假装满足”，不代表代码真能跑。比如依赖用了 PHP 8.1 的枚举类型，你在 PHP 7.4 上强制装进去，运行时直接 Fatal error。
- 真正安全的做法是：先确认目标环境 PHP 版本，然后在
composer.json的config.platform.php里显式声明，例如："config": {"platform": {"php": "7.4.33"}} - 这样
composer install会按你声明的平台去解析依赖，选兼容的旧版本，而不是硬塞不兼容的包 -
--ignore-platform-reqs只应在调试或临时验证场景下用，绝不能进 CI 或上线流程
vendor 目录权限或磁盘空间不足？用 --prefer-dist 和 --no-scripts 控制行为
默认情况下，Composer 优先从 source（git clone）安装包，尤其当包没发 dist 包或你用了 --prefer-source。这会导致：clone 大量 .git 目录、占更多磁盘、网络慢、权限易出问题（比如容器里非 root 用户无法写 .git）。
--prefer-dist 强制走 zip/tar.gz 包，体积小、解压快、无 git 元数据，适合构建环境。
-
--no-scripts禁用post-install-cmd等脚本，防止某些包的 install 脚本尝试写配置、生成缓存、甚至执行数据库迁移——这些不该在部署阶段发生 - 如果项目用了 Laravel 的
post-install-cmd清理 config cache，那--no-scripts后得手动补：php artisan config:clear - CI 中推荐组合：
composer install --no-dev --prefer-dist --no-scripts --optimize-autoloader
最常被忽略的其实是 composer.lock 的更新节奏和 config.platform 的显式声明——它们不体现在命令行参数里，但决定 install 结果是否可重复、是否真兼容。
