Composer.lock是实际执行依据：有则install严格按其精确版本安装，无则退化为update解析新版本；失效场景包括--no-lock、手动编辑、.gitignore忽略或platform不匹配。
composer.lock 不是“用来锁定版本”的配置项，而是 Composer 安装行为的实际执行依据——有它，composer install 就只装它写的版本；没它，composer install 就会报错或退化成 composer update。
composer install 为什么有时装旧包、有时装新包？
行为完全由 composer.lock 是否存在及其内容决定，和 composer.json 里的版本范围无关：
- 项目目录下有有效的
composer.lock→composer install直接按里面记录的精确版本（如"monolog/monolog": "2.9.1"）、dist URL、shasum 安装，不查 Packagist，不解析语义版本 - 没有
composer.lock→composer install会静默按composer.json解析最新兼容版（比如"^2.0"可能装上2.10.2），并生成新 lock 文件（这个行为容易被误认为“自动修复”，实则是失控起点） - 删了 lock 后只跑
composer install→ 等价于一次不受控的composer update，团队成员的vendor/从此可能不一致
哪些操作会让 composer.lock 失效或被绕过？
看似安全的操作，实际可能跳过锁文件校验或导致内容漂移：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer install --no-lock：明确跳过 lock 文件，强制退化为依赖解析模式，CI 中误用等于放弃可重现性 - 手动编辑
composer.lock：Composer 不校验手工修改，下次composer update或composer install会被覆盖，且易因 JSON 格式错误导致解析失败 - 把
composer.lock加进.gitignore：协作环境彻底不可控，不同人composer install出来的vendor/可能完全不同 - PHP 平台配置变更后仍用原 lock 文件：比如
composer.json写了"platform": {"php": "8.0"}，但部署机是 PHP 8.2，composer install可能直接失败（尤其启用了platform-check）
怎么确认当前 lock 文件是否真实生效？
不能只看文件是否存在，得验证它是否被读取、内容是否可信：
- 运行
composer show -s，输出顶部显示Lock file is up to date才说明composer.json和 lock 已同步；若显示not up to date，代表你改了 json 却没更新 lock - 检查
composer.lock末尾的content-hash字段，它由composer.json的require、require-dev、repositories和minimum-stability等内容生成；hash 不匹配 = lock 已过期 - 对比
vendor/autoload.php实际加载路径与 lock 中对应包的dist/shasum，可用composer dump-autoload -o后检查vendor/composer/autoload_classmap.php是否与 lock 记录一致
真正关键的点在于：composer.lock 的可靠性不来自它的存在，而来自你是否严格区分 install（还原）和 update（决策）的使用场景，并确保它始终随 composer.json 一起纳入 Git 版本控制——漏掉任一环节，锁定就只是幻觉。
