install 速度快且安全，因直接读取 composer.lock 执行确定性 I/O 操作；update 则重跑依赖求解器，属 NP-hard 计算，结果不可预测。交付用 install，升级用 update。
因为 install 是照单发货，update 是重新选货+比价+验货。它俩根本不是同一类操作，速度和安全性差异源于底层执行逻辑完全不同。
install 直接读 lock 文件，跳过所有计算
只要项目里有 composer.lock，install 就完全不碰版本解析——它只做三件事：读 lock 里记录的包名和精确版本、从缓存或远程下载对应 zip、解压到 vendor。没有网络探测、没有冲突判断、不跑求解算法。整个过程是线性的、确定的、可预测的。
- 本地已有缓存包时，甚至直接复制，几乎零下载
- 不访问 packagist.org 的 API，省掉数百次 HTTP 请求
- CPU 几乎不参与运算，纯 I/O 操作
update 必须重跑整套依赖求解器
update 会主动忽略 composer.lock，回到 composer.json 的版本约束（比如 ^2.1 或 ~3.0），然后启动 Composer 内置的 Solver 组件，完成一整套“探索式”决策：
- 挨个查每个包在源上的所有可用版本及其元数据
- 递归检查每个子依赖的兼容性（PHP 版本、扩展、其他包的版本范围）
- 尝试不同组合，回溯冲突路径，直到找到一组满足全部条件的版本
- 最后才下载新版本并重写 lock 文件
这个过程是 NP-hard 级别的计算问题，依赖越多、约束越紧，耗时呈指数增长。
install 更安全，是因为它锁定行为
lock 文件本质是一份“已验证通过”的依赖快照。install 强制复现这个快照，等于把开发、测试、预发环境验证过的状态，原封不动搬到生产环境。
- 不会意外引入 breaking change（哪怕某个小版本改了接口）
- 避免因某依赖临时下线或镜像同步延迟导致安装失败
- 团队成员、CI 构建机、Docker 构建结果完全一致
而 update 在每次执行时都可能得到不同结果——今天装的是 v1.2.3，明天可能是 v1.2.4（含未测修复），后天甚至变成 v1.3.0（带新功能但有兼容风险）。
什么时候该用哪个？
一句话原则：交付用 install，升级用 update。
- CI/CD 流水线、Docker 构建、线上部署——只允许用 composer install
- 想升级某个库（比如 laravel/framework）——用 composer update laravel/framework，别全量更新
- 首次克隆项目且无 lock 文件？install 和 update 行为一致，但建议优先 run install，语义更清晰
基本上就这些。理解 lock 文件的“契约”属性，就能自然避开多数依赖陷阱。
