必须用composer validate确认：报“the lock file is not up to date”为过期，执行composer update --lock；报“./composer.lock is invalid”带json行号为真损坏，需备份后重建；不报错但install提示corrupted多因dist.sha256校验失败。
真损坏必须靠 composer validate 确认，不是“看着像乱码就删了重来”——90% 的情况只是过期，误操作反而引入版本漂移。
怎么用 composer validate 区分“过期”和“真损坏”
断电后 composer.lock 文件可能残留半截 JSON、换行错乱或 Git 冲突标记，但这些不等于不可用。关键看 composer validate 输出：
- 报
The lock file is not up to date→ 过期，composer.json被改过但没同步 lock，执行composer update --lock即可 - 报
./composer.lock is invalid并带具体行号（如Parse error on line 42）→ 真损坏，常见于文件被截断、含或空字节 - 不报错但
composer install提示Invalid lock file. Corrupted.→ 多半是dist.sha256校验失败，说明 lock 记录的哈希和实际包不匹配
磁盘断电后 vendor 和 lock 都不完整，该删哪些、留哪些
断电中断 composer install 或 update 后，vendor/ 目录状态决定恢复路径：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 如果
vendor/存在且没手动删过（比如断电时解压已完成），先备份cp composer.lock composer.lock.bak，再运行composer update --lock—— 它只重写 lock，不动 vendor，输出应为Lock file operations: 0 installs, 0 updates, 0 removals - 如果
vendor/已被删、或目录里有空文件夹、或vendor/composer/installed.json是空文件 → 必须清掉全部：rm -rf vendor composer.lock，再跑composer install --no-cache - 千万别用
composer update替代 —— 它会查远程最新版，可能升级一堆包，彻底偏离原依赖状态
为什么加 --no-cache 是关键一步
断电后本地缓存（~/.composer/cache）里可能存着损坏的 zip 包或截断的元数据，composer install 默认会复用它们，导致反复失败。
-
--no-cache强制跳过本地缓存，从镜像源重新拉取原始包，避免“用坏数据装坏包”的死循环 - 国内用户务必提前配好镜像源（如
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/），否则--no-cache仍可能卡在下载环节 - 如果已配镜像但还卡住，先
composer clear-cache再加--no-cache执行，双保险
真损坏后重建 lock，如何避免二次踩坑
重建 composer.lock 不是终点，而是新风险起点：
- 执行
composer install前，确认 PHP CLI 版本与 lock 文件里"platform": {"php": "..."}一致，否则会静默跳过校验或报错 - 别忽略
vendor/composer/installed.json—— 断电可能导致它被截断，即使composer install成功，后续composer show --installed也会崩，建议重装后手动检查该文件是否完整 - Git 提交前，用
git diff composer.lock看新增内容是否合理：字段顺序变化正常，但突然多出几百行或缺失packages段就是异常
锁文件损坏本身不致命，致命的是凭感觉删、凭经验跳过校验、凭运气重试。真正的恢复节奏是：验证 → 判定 → 清理边界 → 强制刷新 → 交叉核对。
