composer update --lock-only是唯一安全的“只更新lock”方式：它仅重算content-hash、字段排序、格式与元数据，不修改vendor、不联网、不升级包，要求composer 2.2+。
composer update --lock-only 是唯一安全的“只更新 lock”方式
你改了 composer.json 里非依赖字段（比如 "description"、"license"、空格、换行），但没动任何 require 或 require-dev，composer install 却报错：Your lock file is out of sync with your composer.json。这不是 bug，是 content-hash 校验失败——你根本不想升级包，只想让 composer.lock 的哈希值和新 JSON 匹配。
✅ 正确做法：composer update --lock-only
❌ 错误做法：composer update（全量重算）、composer install（直接报错）、手动改 composer.lock（破坏一致性）
- 该命令仅重算
composer.lock中的content-hash、字段排序、格式与元数据，不修改vendor/、不触发网络请求、不下载/替换任何文件 - 要求 Composer 2.2+；旧版本必须升级，不能靠 “删 lock + install” 凑合
- 它会重新解析当前
composer.json的全部约束（包括新增/修改的包声明），但按已安装版本重算锁文件
composer update --lock 是“重写 lock”，不是“同步 json”
composer update --lock 和 --lock-only 名字像，作用完全不同：前者完全无视 composer.json 的改动，后者响应它。
composer update --lock 的本质是“快照式重写”：它不读 composer.json 的版本约束，只扫描当前 vendor/ 目录，重新计算每个包的 dist.sha256、源地址、autoload 映射，并标准化写回 composer.lock。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 适用场景：Git 合并后
composer.lock换行符错乱、团队成员用不同 Composer 版本导致字段顺序不一致、迁移到新镜像需刷新 repository URL - 它不校验已安装包是否仍满足
composer.json约束——如果vendor/已被手动改过，这个命令不会报错，但后续install可能失败 - 执行后
git diff一定有变化（时间戳、哈希、URL 全部刷新），但所有"version"字段保持不变
别用 --dry-run 当“同步锁”的替代方案
composer update --dry-run 不会刷新 composer.lock 里的哈希或元数据，它只是模拟完整更新流程：走依赖求解、下载元数据、比对版本，但不写磁盘。输出 Nothing to install, update or remove ≠ lock 文件正确。
- 如果
composer.lock里某个包的dist.shasum已失效，--dry-run可能静默跳过，而真实install时才爆Hash mismatch - 性能开销远高于
--lock-only或--lock，尤其在大型项目中明显卡顿 - 想预览
--lock-only的改动？用composer update --dry-run --lock-only——它会列出哪些包的version、dist.shasum、require字段将被刷新；若看到不该变的包，说明composer.json约束太宽松（如"^2.0"碰巧匹配了新 patch 版）
CI 构建失败时最常踩的坑
CI 报 Lock file is not up to date，99% 是 PR 提交时只改了 composer.json 却漏跑 composer update，或 composer.lock 被 .gitignore 错误忽略了。
- 构建阶段的目标是复现环境，不是探索依赖——永远用
composer install，别手抖加update - CI 脚本里别写死
composer self-update，它可能升到不稳定分支；建议锁定版本，例如composer self-update 2.5.8 - 团队共用
composer.lock时，所有人应尽量使用相同大版本的 Composer（推荐统一用 2.x）；Composer 2.x 生成的 lock 文件含content-hash和细粒度平台信息，1.10 读取时可能直接拒绝加载
真正要“强制更新 lock 文件”，先问自己：是改了非依赖字段？还是 vendor 损坏要重拍快照？或是 CI 格式校验失败？选错命令，轻则引入意外版本漂移，重则线上行为不一致——锁文件的价值不在内容多好看，而在所有环境能复现同一套依赖树。
