Composer如何避免意外升级破坏项目？（版本锁定技巧）

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 是唯一能跨机器复现同一依赖树的凭证——它不是可选附件，是契约本身。