composer install 严格按 composer.lock 安装指定版本，秒级完成；无 lock 则退化为首次解析。update 重解依赖并更新 lock，require/remove 才是增删包的正确方式。
composer install 是照单抓药，不是“安装最新”
它只认 composer.lock 里的版本号，哪怕 composer.json 里写的是 "^2.0"，只要 lock 文件锁死在 "2.12.3"，就一定装这个——不联网、不比版本、不重算依赖。
- 有
composer.lock→ 完全跳过解析，纯下载解压，秒级完成 - 没有
composer.lock→ 退化为首次解析：读composer.json、选最新兼容版、生成新 lock、再装 - CI/CD 部署脚本里必须用
composer install --no-dev，绝不能出现update - 团队协作时，
composer.lock必须提交 Git；漏提 = 别人install出来的 vendor 和你不一样
composer update 是重画处方，不是“更新已装包”
它直接无视 composer.lock，重新跑一遍依赖求解器：查 Packagist、比约束、解冲突、挑最新组合，最后把结果写回 lock 文件。
- 每次运行都可能升级小版本（比如从
2.12.3到2.13.0），甚至引入破坏性变更 -
composer update guzzlehttp/guzzle可局部更新，但依然会重算整个依赖树，只是其他包版本不变 - 执行后必须提交新的
composer.lock，否则别人install不到你实际测试过的版本 - 安全补丁或新 API 需要时才用，且应在测试环境验证后再推上线
加新包别用 install 或 update，用 require
composer install 不改 composer.json，composer update 又太猛——它们都不是为“加一个包”设计的。
- 正确姿势是：
composer require monolog/monolog:^3.0 - 它自动做三件事：写进
composer.json的require、装包、更新composer.lock - 如果误用
update加包，很可能顺手把其他十几个包也升了，引发未知问题 - 想删包？对应用
composer remove monolog/monolog，而不是手动删 json 再 update
为什么 install 总是快，update 经常卡住？
这不是网络慢的问题，是根本逻辑不同：install 是 IO 密集型操作，update 是 CPU + 网络双密集型。
-
install：已知每个包的 URL、SHA256、安装路径，批量下载解压即可 -
update：要发几十个 HTTP 请求查元数据，再跑 SAT 求解器判断兼容性，嵌套深的项目可能卡 2–5 分钟 - 国内用户遇到 update 卡在
loading composer repositories，大概率是没配镜像源，不是命令本身有问题 - 生产服务器上看到
composer update出现在部署脚本里，基本可以判定是配置错误
