composer.lock被误删后应优先用composer update --lock重建，前提是vendor完整且composer.json未修改；否则需先用--dry-run预检再决定是否执行update。
composer.lock 被误删后，composer install 会失败
因为 composer install 严格依赖 composer.lock 来还原确切的包版本。没有它，命令直接报错：Command "install" is not defined. 或更常见的提示：No composer.lock file present. Use "composer install" to generate a lock file. —— 这句话本身就有误导性，别信。
- 执行
composer install前必须有composer.lock，否则它不会自动生成（这是设计行为，不是 bug） -
composer update才会生成/重写composer.lock，但它会升级所有可更新的依赖，可能引入不兼容变更 - 如果你刚删了
composer.lock，但vendor/还在，那当前运行环境其实是“锁定”状态的——只是没文件记录而已
想最小化影响？用 composer update --lock
这个命令是 Composer 2.2+ 引入的“锁文件重建专用模式”，它不升级任何包，只根据 composer.json 重新生成一份语义等价的 composer.lock。前提是：你没改过 composer.json，且 vendor/ 目录完整。
- 运行前确认：
vendor/存在且内容与原composer.lock一致（比如刚删锁文件，但没动 vendor） - 执行：
composer update --lock，输出里应看到类似Lock file operations: 0 installs, 0 updates, 0 removals - 如果提示冲突或报错，说明
vendor/和composer.json已不一致，这时不能强行用--lock，得走下一步
不确定 vendor 是否干净？老老实实用 composer update --dry-run 预检
直接跑 composer update 风险太高，尤其在线上或协作分支中。先用干运行看它打算动什么：
-
composer update --dry-run会模拟整个更新流程，输出将要安装/升级/卸载的包及其版本 - 重点关注输出里有没有
downgrading、upgrading或大量版本号变动——这说明依赖树已漂移 - 如果干运行结果干净（只有
Writing lock file），那可以放心执行composer update - 注意：
--dry-run不写入composer.lock，也不会改vendor/
CI/CD 或部署脚本里别硬编码 composer install
很多构建脚本假设 composer.lock 一定存在，但 Git 忽略规则、分支合并冲突或人工误操作都可能导致它缺失。这时候脚本直接卡死。
- 稳妥做法是在 CI 中加一层检查：
test -f composer.lock || { echo "composer.lock missing"; exit 1; } - 更灵活的方案是：允许 CI 在缺失时自动重建，但必须显式控制策略，例如：
composer update --lock || composer update --no-interaction（后者带降级兜底） - 永远不要在生产部署流程中依赖
composer update—— 它不可重现；composer install才是部署唯一合法入口
vendor/ 没动就等于安全——其实只要 composer.json 变过、或本地有未提交的 require 更改，--lock 就可能产出和原来不一致的哈希，连带影响可重现性。 
