composer remove 不能批量删，得一个个来
composer 没有内置的 composer remove --all 或类似批量卸载命令。所谓“批量删除依赖”，本质是手动或脚本化地调用多次 composer remove，否则会误删 vendor/ 但不更新 composer.json，导致下次 composer install 还拉下来——这根本不算“删依赖”，只是清缓存。
常见错误现象：rm -rf vendor/ && composer install 后发现包还在；或者直接编辑 composer.json 删除几行却忘了运行 composer update，结果 composer.lock 和实际安装状态不一致。
- 必须用
composer remove vendor/package-name才能同步删掉composer.json、composer.lock和vendor/里的文件 - 想删多个？只能连写：
composer remove monolog/monolog guzzlehttp/guzzle symfony/http-Foundation - 如果包被其他依赖间接引用（require-dev 里也有，或作为子依赖存在），
remove会失败并提示冲突，得先确认依赖图：composer depends vendor/package-name
重置项目依赖 = 删锁文件 + 清 vendor + 重装
“一键重置”不是指恢复到初始状态，而是让当前 composer.json 成为唯一权威来源，彻底丢弃所有当前已安装包和锁文件的残留影响。这在 CI 构建、排查依赖污染、或接手别人项目时最常用。
关键点在于顺序和完整性：删错一个文件，composer install 就可能走缓存路径，绕过真实解析。
- 先删
composer.lock：rm composer.lock—— 不删它，install会严格按旧锁安装，哪怕composer.json已改 - 再删
vendor/：rm -rf vendor/—— 只删目录，不碰composer.json - 最后重装：
composer install（不是update）—— 它会根据当前composer.json生成全新composer.lock并安装 - 注意：如果项目含
platform配置（如"php": "8.1"），重装时仍受其约束，不是“无条件重装”
慎用 composer update –lock 和强制重生成锁
composer update --lock 看似是“只更新锁文件”，实际行为很反直觉：它不会重新计算依赖树，只是把现有 vendor/ 结构“快照”进新 composer.lock。这会导致锁文件和 composer.json 不一致，后续 install 可能失败或装错版本。
真正安全的锁文件重生成，只有两种情况：
- 你刚删了
composer.lock和vendor/，然后跑composer install—— 这才是干净重建 - 你明确要升级某些包，用
composer update vendor/package，由 Composer 自动推导并更新锁 - 别信网上抄的
composer update --lock --dry-run，它不解决根本问题，还容易掩盖版本冲突
windows 下 rm -rf vendor/ 容易失败
PowerShell 或 CMD 默认不认 rm -rf，强行执行会报错 The term 'rm' is not recognized，或删不干净（尤其带符号链接或长路径的 vendor/）。这不是 Composer 问题，是 shell 环境差异。
实操建议：
- git bash 用户：直接用
rm -rf vendor/，没问题 - PowerShell 用户：用
Remove-Item -Recurse -Force vendor - CMD 用户：用
rmdir /s /q vendor - 更稳的方式：所有平台都可用
composer dump-autoload && composer clear-cache && rm -rf vendor/ composer.lock（配合 Git Bash 或 WSL）
重置这事，核心就两条：锁文件和 vendor 目录必须一起清，且顺序不能反；删包必须走 remove，手改 JSON 不算数。剩下都是环境适配细节。