composer install是唯一能保证生产环境和团队协作不翻车的安装方式；它严格按composer.lock中记录的精确版本、哈希值和dist url安装，缺失lock则退化为不可控解析，必须在ci/cd和上线时强制使用。

直接说结论：composer install 不是“装依赖的通用命令”，它是**唯一能保证生产环境和团队协作不翻车的安装方式**。只要没走这一步，就等于没部署。

为什么 composer install 必须基于 composer.lock

它不是“看 composer.json 装最新兼容版”，而是严格按 composer.lock 里记录的完整版本号、哈希值、dist URL 安装。哪怕某包昨天刚发 v2.1.5，只要 lock 里写的是 v2.1.4，它就绝不会升。

• 没 composer.lock？它会临时解析 composer.json 生成一份——但这不是稳定行为，不同机器、不同 Composer 版本可能算出不同结果
• composer.lock 缺了某个包？Composer 2.5+ 直接报错退出，不给你蒙混过关的机会
• CI 流水线里漏掉 ls -la composer.lock 检查，或缓存了旧 lock，装出来的依赖就和本地对不上

composer install 在 CI/CD 和上线时的硬性操作顺序

别信“先 composer update 再 commit lock”这种本地流程，上线必须干净利落：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 拉代码后第一件事：确认 composer.lock 存在且已 git checkout 干净（git status 无修改）
• 执行 composer install --no-dev --prefer-dist：跳过 dev 包、强制用压缩包而非 Git 克隆
• 加 -vvv 参数跑一次，检查日志里是否出现 mirrors.aliyun.com —— 如果还看到 packagist.org，说明镜像没生效或缓存没清

常见卡住场景和对应解法

卡在 Loading composer repositories？这不是网速慢，是元数据拉取失败：

• 先 composer clear-cache，再删掉项目下的 vendor/ 和 composer.lock
• 确认镜像配置正确：composer config -g repo.packagist 输出必须是完整 JSON，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
• 项目级配置优先级高于全局，检查 composer.json 的 repositories 字段是否误写了旧源或 "packagist.org": false

为什么不能用 composer update 替代 composer install

composer update 会主动忽略 composer.lock，重新解析 composer.json 约束，哪怕只是 ^3.2.0 这种写法，也可能装上 v3.2.7 —— 而这个版本可能删了你正在调用的私有方法，或改了配置格式。

• 线上部署、新服务器初始化、Docker 构建镜像，只允许用 composer install
• composer update 只该出现在本地开发机，且每次执行后必须人工 review composer.lock diff，再跑全量测试
• 想试某个包的新版？用 composer update vendor/package-name 精确更新，避免连带升级

最易被忽略的一点：.gitignore 里如果写了 composer.lock，或者有人 git add 时漏掉了它，那所有后续 composer install 都是在裸跑，根本谈不上“稳定”。