删 composer.lock 仅是强制重装第一步，还需同步清理 vendor 目录和本地缓存（composer clear-cache），并终止占用文件的 PHP 进程、IDE 索引及杀毒软件扫描，最后执行 composer install --no-cache 才能确保依赖重建正确。
删 composer.lock 是强制重装的前提，不是“清除锁文件”的终点
很多人以为删掉 composer.lock 就万事大吉，其实这只是第一步。真正阻碍 composer install 的，往往是残留的 vendor 目录、本地缓存、甚至被占用的文件句柄。删 lock 文件本身不报错，但后续 install 失败，大概率是这些“隐性锁”在作祟。
删 lock 后必须连带清理 vendor 和缓存，否则 install 仍会复用旧状态
composer install 在没有 composer.lock 时，行为取决于是否有 vendor 目录和缓存：
- 有
vendor/目录 → Composer 可能跳过下载，只尝试重建 autoload（但路径错乱时直接失败） - 有本地缓存（
~/.composer/cache）→ 即使删了 lock，它仍可能从缓存拉包，绕过镜像源配置或 platform 检查 - 没删干净的
vendor/autoload.php或vendor/composer/下的映射文件 → 导致类加载冲突或 “Class not found”
所以标准动作是三连：rm -rf vendor composer.lock + composer clear-cache。Windows 用户用 rmdir /s vendor && del composer.lock，再加 composer clear-cache。
Windows 上 “Could not delete” 不是权限问题，而是进程占用了文件
报错 Could not delete vendor/some-package 时，sudo 或管理员权限基本无效。真实原因是：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- PHP 进程（如 Laravel Sail、Swoole server、Xdebug）正加载该包里的类
- IDE（PhpStorm/VS Code）后台索引服务锁住了整个
vendor/目录 - 杀毒软件或 Windows Defender 正在扫描刚解压的文件
解决顺序很关键：
- 先停掉所有 PHP 服务：
php artisan serve、php -S、sail stop等 - 关掉 IDE，或在 PhpStorm 中禁用 “Synchronize files on frame activation”
- 用 PowerShell 手动删出问题的子目录：
Remove-Item -Recurse -Force vendor\some-package - 最后再跑
composer install --no-cache，避免缓存干扰
删 lock 后别用 composer update，install 才是重建的正确入口
删了 composer.lock 后误跑 composer update，结果往往更糟：
-
update会复用缓存、忽略"platform"配置，可能装出 PHP 版本不兼容的包 - 如果
composer.json里写了"dev-main"这类分支约束，update可能拉取不同 commit，导致 lock 文件再次混入多个source.reference - 而
install在无 lock 时，会严格按composer.json重新解析依赖树，生成全新且一致的 lock
唯一例外：你明确想升版且接受 lock 变更，才用 composer update --with-all-dependencies；其余场景，删完就跑 composer install --no-dev --optimize-autoloader。
真正麻烦的从来不是删文件，而是删完之后谁还在读它——IDE、调试器、后台服务，它们不会因为你 rm 了 lock 就自动松手。动手前先关服务，比多敲十遍命令管用。
