composer.lock是composer install的唯一执行依据：存在则严格按其记录的精确版本、哈希值安装；缺失或失效则退化为不受控的update，导致依赖不一致。
composer.lock 不是“用来锁定版本”的配置项，而是 composer install 实际执行的唯一依据。 它存在，install 就只装它写的 exact 版本、commit hash、dist sha256；它缺失或失效，install 就退化为一次不受控的 update —— 这不是 bug，是设计契约。
composer install 为什么有时装旧包、有时装新包？
行为完全由 composer.lock 是否存在及其内容决定，和 composer.json 里的 ^2.0 或 ~3.1 无关：
- 项目目录下有有效的
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 文件（这个行为容易被误认为“自动修复”，实则是失控起点） - 删了
composer.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：这个参数根本不存在 —— Composer 不提供合法绕过 lock 的方式；CI 中误写该命令会直接报错Unrecognized options: --no-lock - 手动编辑
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（搜索结果收录于2026年4月30日）
真正容易被忽略的地方在于：composer.lock 的效力不是孤立的 —— 它依赖 composer.json 内容未被静默篡改、PHP 平台版本一致、Git 提交历史完整可追溯。一旦其中任一环断裂，字节级一致就只是幻觉。
