composer install 严格按 composer.lock 复现已验证依赖，update 则忽略锁文件重算依赖；前者用于稳定交付，后者用于主动升级，二者分工明确不可混用。

composer install 是“照单抓药”，update 是“重新开方”

根本区别就一条：install 读 composer.lock，update 忽略它、重算依赖。前者复现已验证过的状态，后者探索新组合——不是快慢问题，是“稳态交付”和“动态升级”的分工。

• install 在有 composer.lock 时完全不联网查版本、不跑求解器，只按锁文件里写死的哈希、URL、版本号下载解压，本地缓存命中时几乎秒装
• update 会重新请求 Packagist API、递归校验 PHP 版本/扩展/子依赖约束，本质是 NP-hard 计算，10 个包可能耗时数秒，50 个包可能卡住两分钟
• 首次运行 install 若无 composer.lock，它会退化成一次 update 并生成锁文件——但这不是推荐做法，容易绕过团队对初始依赖的共识

什么时候必须用 install，什么时候只能用 update

不是“选哪个更顺手”，而是环境职责决定的刚性规则。

Discussion Composer

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

下载

• CI/CD 流水线、Docker 构建、线上部署脚本里出现 composer update，等于把版本控制权交给网络延迟和 Packagist 镜像同步状态，凌晨告警大概率由此而起
• 新成员克隆项目后第一件事必须是 composer install，不是 update——否则他装的 monolog 可能比你本地高一个小版本，而那个版本悄悄改了日志上下文的序列化方式
• 想升级某个包（比如修 CVE-2025-1234），应该用 composer update vendor/package-name，而不是全量 update；全量更新哪怕加了 --with-dependencies，也可能把一个没动过的 symfony/console 升到带 BC break 的 v7

lock 文件不是“缓存”，是契约

composer.lock 提交进 Git 不是为了省事，是把“这个 commit 能跑通”这个事实固化下来。

• 删掉 composer.lock 再 install？等同于放弃所有环境一致性保障，和直接 update 没区别
• 有人为“减小 lock 文件体积”手动删掉 dev 依赖块，结果 composer install --no-dev 失败——因为 lock 文件里 dev 块虽不装，但它的存在影响主依赖的解析路径，删了就可能让 solver 找不到合法解
• composer install --no-dev 安全；composer update --no-dev 不安全——它仍会重算全部依赖（包括 require-dev 中被其他包间接依赖的部分），只是最后不装 dev 包而已

require 命令才是日常加包的正确姿势

别为了加一个包就跑 update，那相当于为了换颗螺丝把整辆车送回产线重造。

• 加新包用 composer require vendor/package：它自动写入 composer.json、执行最小范围依赖求解、更新 composer.lock，一步到位
• 如果怕影响现有包，加 --no-update：先写进 composer.json，再单独 composer update vendor/package，其他包纹丝不动
• 误用了 update 导致锁文件变大、依赖混乱？别硬扛，用 git checkout composer.lock 回退，再走 require 路线

锁文件一旦提交，它的每一行都是你对“这个版本组合已验证可用”的签字。install 和 update 的分界，本质上就是签过字的处方能不能改——没签字前可以调，签完就得照着抓。