“Package is locked to version”不是错误，而是Composer严格执行一致性契约的表现：lock文件已固化精确版本（如"monolog/monolog": "3.5.0"），需用composer update（而非require）配合明确版本约束或--with-all-dependencies合法更新，而非强行突破。
“Package is locked to version”不是报错，是 Composer 在严格执行版本契约——它没卡住，只是在拒绝破坏一致性。真正要做的不是强行突破，而是看清锁在哪、为什么锁、怎么合法更新。
为什么 composer update 提示 “Package is locked to version”
这个提示本质是告诉你：当前 composer.lock 文件里已固化了该包的精确版本（比如 "monolog/monolog": "3.5.0"），而你执行的命令（如 composer update monolog/monolog）没有提供足够强的版本约束去触发重新解析。
- 常见诱因包括：
composer.json里仍写的是"^3.5"，不是明确版本；或你只运行了composer require monolog/monolog:3.6.0但没加--update-with-dependencies -
composer update默认只更新“有变更需求”的包——如果composer.json没改、lock 里版本又满足当前约束，它就真的一动不动 - 别信“缓存导致”，这不是缓存问题，是依赖解析器按规则判定“无需变更”
解除锁定的正确姿势：用 composer update 而不是 composer require
想升级某个包，优先走 update 流程，它尊重 lock 文件结构，只做最小必要重算；require 容易偷偷加 ^ 或引入新约束，反而引发连锁冲突。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 明确指定包名：
composer update monolog/monolog—— 这会基于当前composer.json的版本范围重新求解，而不是硬塞一个版本 - 带子依赖协同升级：
composer update monolog/monolog --with-all-dependencies—— 避免因子依赖版本卡死（如psr/log被其他包锁在1.0.0，而monolog 3.6.0要求>=2.0） - 验证是否真能升：
composer update monolog/monolog --dry-run先看计划，确认没意外降级或大版本跳变
镜像源元数据延迟导致“明明有新版却说没得更”
现象是 composer update monolog/monolog 输出 Nothing to install or update，但阿里云镜像页面已显示 v3.6.0 —— 根本原因是本地复用了 15 分钟内未过期的 packages.json 缓存，压根不发远程请求。
- 验证是否真延迟：
curl -I https://mirrors.aliyun.com/composer/packages.json，看Last-Modified时间是否比你上次更新还早 - 清缓存无效：
composer clear-cache会重建整个缓存目录，但旧packages.json仍被复用 - 正确刷新元数据：
composer update --refresh（≥2.5）—— 它只丢弃所有缓存的packages.json和provider-*.json，然后从当前配置镜像源重新拉取，不碰 ZIP 包缓存 - 检查是否真用上镜像：
composer config --list | grep repositories.packagist.url，项目级repositories配置会完全屏蔽全局设置，这是最隐蔽的失效原因
锁文件损坏或 Git 合并冲突时千万别手修 composer.lock
composer.lock 不是普通 JSON 文件，字段顺序、空行、缩进、content-hash、platform 字段都参与校验。手动删标记、调顺序、合并数组，99% 会导致 Invalid argument supplied for foreach() 或静默装错子依赖。
- Git 冲突后第一件事：
git checkout --theirs composer.json统一根配置，再rm composer.lock - 然后立刻运行：
composer update --lock—— 它不读旧 lock，只按当前composer.json重算哈希与依赖树，生成全新合法文件 - 如果
vendor/已损坏或不可信，先rm -rf vendor，再composer install（前提是刚生成的 lock 是合法的） - 绝对不要
rm composer.lock && composer install—— Composer 会直接报错退出，CI 构建失败就是这么来的
复杂点在于：锁不是技术问题，是协作契约。哪怕你本地 composer update --lock 成功，如果 composer.json 里写的还是 "^3.5"，下次别人拉代码就可能装出 3.6.0；真正锁死必须三者齐备：composer.json 写三位完整版本号、composer.lock 提交进 Git、部署时只跑 composer install。
