唯一能彻底清空依赖的方式是删vendor和composer.lock、清空require字段后运行composer install --no-dev；composer remove无法真正清空，因其不处理未安装包、require-dev包、间接依赖，且不物理删除目录。
直接删 vendor 和 composer.lock，再清空 require 字段后运行 composer install --no-dev，是唯一能彻底、干净、可复现地清空所有依赖的方式。
为什么不能用 composer remove 批量删包来清空
即使你用 composer remove 逐个删掉所有 require 中的包，它也不会真正“清空”——因为：
• 它只处理已安装的包，如果某个包没装（比如被 --no-dev 跳过），命令会报 Package "xxx" is not installed 并跳过，但不中断后续；
• 它不检查或清理 require-dev 里的包，除非你显式加 --dev；
• 它不会删掉间接依赖（如 symfony/console 引入的 psr/log），这些包仍会留在 vendor/ 里；
• 更关键的是：Composer 2.5+ 的 remove 默认不物理删除目录，得靠后续 install 或 update 触发同步，而你正想“清空”，根本没东西可同步。
清空依赖的三步实操（安全、无残留）
这是重构项目起点最稳的操作链，适用于 Laravel、Symfony 或纯库项目：
• rm -rf vendor composer.lock —— 必须删锁文件，否则 install 仍按旧图谱还原
• 编辑 composer.json，把 "require": {} 保留为空对象（别删整行，否则 JSON 不合法），同理清空 "require-dev": {}（如需彻底清空）
• 运行 composer install --no-dev —— 此时 vendor/autoload.php 会生成，composer.lock 是空依赖树，vendor/ 下只有 autoload 相关文件，没有一个第三方包
清空后立即要验证的两件事
别以为执行完就结束了，这两个点不确认，后续 require 新包可能失败或行为异常：
• 检查 vendor/composer/autoload_psr4.php 和 autoload_classmap.php 是否真的为空或只含项目自身路径 —— 如果还残留旧包的映射，说明上一步没生效，得手动删或补跑 composer dump-autoload --classmap-authoritative
• 运行 composer show --installed，输出应为空（或仅显示 composer/package-versions-deprecated 这类 Composer 自带工具包），若有其他包名出现，说明 composer.json 没清干净，或 install 命令被意外中断
清空不是目的，而是为了从零构建可信依赖树。最容易被忽略的是：很多人删完 vendor/ 后忘记删 composer.lock，结果 install 看似成功，实际只是重装了旧锁文件里的全部历史包——那根本不是清空，是假装清空。
