composer remove --no-update 仅删除 composer.json 中的依赖项，不更新 vendor/ 和 composer.lock；需后续执行 composer update --lock 或 composer install（确保锁文件已更新）才能彻底移除包。
直接执行 composer remove --no-update 不会真正移除包，它只是从 composer.json 中删掉依赖项，但不会同步更新 vendor/ 和 composer.lock —— 这正是它的设计目的，不是 bug。
为什么 composer remove --no-update 看起来“没生效”
常见误解是以为运行后包就立刻从项目里消失了。实际上：
-
composer remove --no-update只修改composer.json，删掉对应require或require-dev条目 -
vendor/目录里的文件完全不动，该包的类仍可被加载（只要没手动删） -
composer.lock也保持原样，里面依然记录着已删包的版本和哈希 - 后续运行
composer install或composer update时，Composer 会按锁文件还原，导致“删了又回来”
什么场景下该用 --no-update
适合需要批量调整依赖声明、但暂不触发安装逻辑的协作或自动化流程：
- CI 流水线中先清理
composer.json，再统一做一次composer update --lock避免多次写锁 - 多人共用一份
composer.json，你只负责删配置，由其他人统一执行更新 - 想保留当前
vendor/状态做兼容性测试，比如确认删包后旧代码是否还能跑通 - 配合
composer update --lock实现“声明即配置”，只改锁不重装
remove --no-update 后必须补哪一步？
若目标是彻底移除包并反映到运行环境，不能只靠 --no-update：
- 手动删除
vendor/vendor-name/package-name目录（可选，但最干净） - 运行
composer update --lock：仅更新锁文件，不重装包（比composer update快，且不碰vendor/） - 或者运行
composer install：按新composer.json+ 当前composer.lock还原 —— 但前提是锁文件已不含该包（否则得先update --lock） - 注意：如果删的是
require-dev包，而当前环境是dev模式，composer install默认仍会装它们；加--no-dev才跳过
真正容易被忽略的是锁文件的滞后性——composer.json 改了，composer.lock 不同步，等于没改。别依赖 IDE 或 git status 判断包是否“已移除”，最终以 vendor/ 和 composer.lock 为准。
