composer update 默认按 composer.json 约束升级到最新兼容版本，不尊重 composer.lock；composer install 才按 lock 文件还原环境；只升级指定包用 composer update vendor/package-name，避免误升依赖。
composer update 为什么总把不该动的包升级了？
因为 composer update 默认不看 composer.lock 是否“够用”，而是直接按 composer.json 里的版本约束，找最新兼容版本。哪怕你上周刚跑过 composer install，只要约束写得宽（比如 "monolog/monolog": "^2.0"），它就可能升到 2.10.0 —— 而这个版本可能悄悄改了日志处理器的构造参数。
- 默认行为是「满足约束前提下取最新」，不是「保持 lock 文件现状」
-
composer install才是真正按composer.lock还原环境；update是主动打破它 - CI/CD 流水线里误用
update是线上故障常见源头
怎么只升级指定包，其他全锁死？
用 composer update vendor/package-name，不加任何通配符或 --with-dependencies。这是最安全的增量更新方式，Composer 会严格保持其余所有包版本与 composer.lock 一致。
- 例如：只升 Laravel 的核心框架，不动
guzzlehttp/guzzle和symfony/*：composer update laravel/framework - 如果该包有子依赖被间接影响（比如新版本要求更高 PHP 版本），Composer 会报错中止，而不是强行升级下游
- 别写
composer update "laravel/*"—— 这会连带升级laravel/tinker、laravel/sanctum等，失控风险陡增
composer.json 里哪些版本写法实际等于“不锁”？
看似保守的写法，运行时可能比 * 更危险。关键看是否允许次版本或补丁版本漂移。
-
"^2.0"→ 允许升到2.9.9，但禁止到3.0.0；对语义化版本（SemVer）项目较安全 -
"~2.0"→ 等价于>=2.0.0 ，和 <code>^2.0行为一致 -
"2.*"或"2.x"→ 允许升到2.100.0，且部分旧版 Composer 会错误解析为2.0.0 - 2.999.999，隐患更大 - 真正锁死：直接写死完整版本号，如
"2.8.7"；或使用composer.lock+install组合
lock 文件被删或过期了，怎么最小化风险还原？
别急着 composer update。先确认当前 composer.lock 缺失是否因误操作，还是多人协作中有人提交了未生成 lock 的变更。
- 如果有 Git 历史，优先从最近一次正常 CI 通过的 commit 恢复
composer.lock：git checkout HEAD -- composer.lock - 若完全丢失，用
composer install --no-scripts --no-plugins强制按composer.json重建 lock，再立刻git add composer.lock提交 - 禁用脚本和插件是为了防止在依赖未稳定前触发异常钩子（比如数据库迁移、前端构建）
复杂点在于：有些包不遵守 SemVer，小版本也可能破坏接口；而 composer.lock 是唯一能跨机器复现同一依赖树的凭证——它不是可选附件，是契约本身。
