直接删掉 vendor 文件夹再执行 composer install 是最可靠、最符合 Composer 设计意图的方式；它严格按 composer.lock 精准重建依赖，确保环境一致性，避免 update 导致的版本漂移或 autoload 错误。
直接删掉 vendor 文件夹再 composer install 就行
这不是“绕路”，而是最可靠、最符合 Composer 设计意图的方式。Composer 本身没有 reset 或 clean-vendor 这类命令，强行用 composer update 或反复 dump-autoload 反而容易残留旧包、autoload 错误或版本不一致。
常见错误现象包括：Class not found 即使文件存在、require 某个包却提示未安装、composer show 列出的包和 vendor/ 实际内容对不上——这些基本都是 vendor 状态混乱导致的。
- 确保当前目录是项目根目录（有
composer.json） - 运行
rm -rf vendor（Linux/macOS）或rmdir /s vendor（Windows CMD），别漏掉隐藏文件（如.git子目录） - 执行
composer install，不是update：它会严格按composer.lock安装，保证环境一致性 - 如果没
composer.lock，先composer install生成它；后续才可稳定复现依赖
什么时候不该删 vendor？
仅当你要保留本地修改（比如调试时 patch 了某个包）或正在开发私有包并用 path 类型 repo 引入时，才需谨慎。否则，删 vendor 是安全的——Composer 不存状态在 vendor 里，所有元数据都在 composer.json 和 composer.lock 中。
注意点：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer dump-autoload -o不重建 vendor，只刷新自动加载映射，不能解决包缺失或版本错乱 -
composer clear-cache清的是全局下载缓存（~/.composer/cache），不影响当前项目的vendor - CI/CD 流程中应始终用
composer install，而非update，避免意外升级
想跳过某些步骤？加参数控制行为
重装 vendor 时，常需要适配不同场景，靠参数比写脚本更轻量：
- 跳过脚本执行：
composer install --no-scripts（防止 post-install-cmd 报错中断） - 忽略平台配置（如本地 PHP 版本低但 lock 文件要求高）：
composer install --ignore-platform-reqs（慎用，仅临时调试） - 只装 require，不装 require-dev：
composer install --no-dev（上线部署常用） - 强制重装（即使 lock 未变）：
composer install --force-reinstall（解决 symlink 或权限残留问题）
删完 vendor 后 composer install 报错怎么办？
绝大多数情况是 lock 文件和当前环境不兼容，不是操作错了。先看错误关键词：
-
Your lock file does not contain a compatible set of packages→ 运行composer update --lock同步 lock（仅当确认要更新依赖） -
Could not find package xxx→ 检查composer.json的repositories是否配置正确，或是否用了已下线的私有源 -
Failed to download xxx: Could not authenticate→ 需配置 token：composer config -g github-oauth.github.com <your-token> - PHP 版本报错 → 对照
composer.json的config.platform.php或项目实际要求，别硬加--ignore-platform-reqs
真正麻烦的不是删 vendor，而是 lock 文件长期没更新、多人协作时随意 update 导致分支间依赖漂移——vendor 只是表象，根源在依赖管理习惯。
