composer.lock 就是最权威的依赖备份，它精确记录所有包版本、哈希值、依赖树和安装路径，确保可完全复现；无需额外导出，应通过 git commit、tag 或分支管理其历史状态。
composer.lock 文件本身就是最权威的依赖备份
不需要额外“导出”或“备份”——composer.lock 就是 Composer 记录当前所有包精确版本、哈希值、依赖树和安装路径的快照。只要它没被删、没被手动改坏，你就拥有了可完全复现的依赖状态。
常见错误现象：git commit 时漏掉 composer.lock，或者把它加进了 .gitignore；CI 构建时用 composer install 却报错“找不到 lock 文件”，本质是丢了唯一可信源。
- 每次运行
composer install都严格按composer.lock安装，不读composer.json的版本约束 -
composer update才会改写composer.lock，并更新实际安装的包 - 多人协作或部署前，务必确认
composer.lock已提交且与本地vendor/一致
想留多个历史 lock 快照？别 rename，用 git tag 或分支
有人习惯把 composer.lock 复制为 composer.lock-202405 或加时间戳，这反而破坏工作流。Git 本身就能完美存档任意时刻的依赖状态。
使用场景：上线前冻结依赖、回滚某次更新、排查某天构建失败原因。
- 打 tag 最轻量：
git tag lock-before-v2.3.0，之后随时git checkout lock-before-v2.3.0 -- composer.lock - 需要长期维护多个环境依赖？开独立分支，比如
deps/stable-2024q2，只合入 lock 变更 - 避免用文件名区分——IDE、CI 脚本、Dockerfile 全默认认
composer.lock，换名等于主动绕过工具链
require-dev 包没进 lock？检查是否用了 --no-dev
composer.lock 默认包含 require 和 require-dev 的全部信息。但如果你在 CI 或生产部署中执行了 composer install --no-dev，lock 文件本身没变，只是安装时跳过了 dev 包——这不是备份问题，是安装策略误用。
错误现象：本地 composer install 能跑测试，线上却提示 Class PHPUnit\Framework\TestCase not found。
- 开发机和 CI 应该用同一份
composer.lock，区别只在安装命令：--no-dev仅用于生产环境，不影响 lock 内容 - 确认 lock 是否含 dev 包：打开它搜
"require-dev"字段，有内容即正常 - 如果真想分离 dev 依赖（极少见），应拆成两个
composer.json，而非靠 lock 文件“假装备份”
lock 文件损坏或被篡改？用 hash 验证 + vendor 重装
Composer 不提供校验命令，但 composer.lock 里每个包都带 dist.shasum，这是它下载包时验证完整性的依据。一旦 lock 被手改或传输出错，composer install 会直接失败，并报类似错误：
Failed to download vendor/package: The zip file could not be extracted (invalid checksum)
这时别急着删 lock 重生成——你可能丢掉的是精确版本控制。
- 先检查
composer.lock是否语法合法：json_decode(file_get_contents('composer.lock'), true)在 PHP 里试一下 - 对比 git 历史，看哪次提交改了 lock，用
git checkout HEAD~1 -- composer.lock恢复上一版 - 最后手段：删掉
composer.lock和vendor/，再composer install——但注意，这会按composer.json重新解析版本，结果可能和原来不同
备份不是另存为，而是让 composer.lock 始终处于受控、可追溯、未被绕过的状态。最容易被忽略的点是：以为自己“备份了”，其实只是复制了一个随时可能失效的文件副本，而真正起作用的版本锚点，永远藏在 Git 提交历史里。
