“依赖锁定失效”是Composer拒绝执行的错误，表明composer.lock中某包版本在当前源中不存在，需人工干预；常见原因包括作者删tag、镜像延迟、私有包未发布或源切换未刷新缓存。
“依赖锁定失效”不是警告，是 Composer 明确拒绝继续执行的错误信号——它说明 composer.lock 文件里记录的某个包版本在当前源中根本不存在，必须人工干预，不能靠重试或加参数绕过。
报错信息里带 “has been locked to a version that does not exist” 怎么定位
Composer 会明确告诉你哪个包出问题，例如：
- Package guzzlehttp/guzzle has been locked to version 7.2.0, but this version does not exist
这不是网络超时或权限问题，而是该版本号在你配置的仓库（比如 Packagist 或私有镜像）里查无此物。可能原因包括：作者删了 tag、镜像同步延迟、私有包未发布、或你切换过源但没刷新缓存。
- 先确认这个包是公开还是私有：
guzzlehttp/guzzle是公开包，mycorp/internal-sdk就是私有包 - 用
curl -I https://packagist.org/p/guzzlehttp/guzzle.json直接查官方源是否返回 200；如果是私有源，换用curl -H "Authorization: Bearer xxx" https://your.repo.com/p/mycorp/internal-sdk.json - 检查你是否启用了镜像：
composer config --list | grep repo，确认当前源地址是否有效（阿里云镜像已稳定运行，但旧的 phpcomposer.com 已停用）
删 lock + 删 vendor 是最直接有效的修复方式
当确定版本确实不存在（比如作者撤回了 7.2.0），强行保留 lock 文件只会让每次 composer install 都失败。正确做法是彻底清除陈旧状态：
- 执行
rm -f composer.lock vendor/（Windows 用del /q composer.lock && rmdir /s/q vendor） - 运行
composer install—— 此时因无 lock，它会退化为composer update行为，重新解析composer.json并生成新 lock - 如果项目要求严格锁定（如金融类生产系统），别跳过这步：提交新生成的
composer.lock到 Git，否则 CI 构建会不一致
注意：composer update --lock 在这种场景下无效，它只重写 lock 文件但不校验版本是否存在，仍会卡在同一个错误上。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
想保留 lock 文件？那就改 composer.json 的约束范围
适用于你不能接受全量依赖重算、只想局部修正的场景（比如团队协作中 lock 文件被多人提交过，不能随便删）：
- 打开
composer.json，找到报错包所在的require条目，把死版本号（如"guzzlehttp/guzzle": "7.2.0"）改成兼容范围（如"guzzlehttp/guzzle": "^7.0"） - 运行
composer update guzzlehttp/guzzle --with-dependencies—— 加--with-dependencies是关键，否则它的子依赖（如psr/http-client）可能卡在旧版导致冲突 - 检查输出里是否真升级了该包及其依赖，再确认
composer.lock中对应条目的 version 字段已更新
别用 composer require guzzlehttp/guzzle:7.2.0 --no-update，这只改 json 不动 lock，错误照旧。
私有包或镜像问题容易被当成“锁定失效”
看起来像版本不存在，实际是认证或源不可达。这类问题不会报“does not exist”，但行为高度相似：
- 运行
composer diagnose，重点看 “Checking platform settings” 和 “Checking git settings” 下是否有 warning - 私有包报错常伴随
401 Unauthorized或404 Not Found，但 Composer 默认隐藏详情；加-vvv参数重跑composer install -vvv可看到真实 HTTP 状态码 - 若用的是自建 Satis 或 Private Packagist，确认该包的
distURL 是否可 curl 通，且 JSON 中的version字段与 lock 文件完全一致（注意大小写和分隔符）
真正麻烦的不是版本号写错，而是 lock 文件里存了带 commit hash 的 dev 版本（如 "dev-main#abc123"），而对应分支已被 force push 覆盖——这种失效无法靠改约束修复，只能删 lock 重建。
