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

适合需要批量调整依赖声明、但暂不触发安装逻辑的协作或自动化流程：

chartjs-reporter

此技能用于在用户需要将结构化数据（查询结果、CSV 摘要、JSON 记录或 Python 字典/列表）转换为独立的 HTML 页面时使用。

下载

• CI 流水线中先清理 composer.json，再统一做一次 composer update --lock 避免多次写锁
• 多人共用一份 composer.json，你只负责删配置，由其他人统一执行更新
• 想保留当前 vendor/ 状态做兼容性测试，比如确认删包后旧代码是否还能跑通
• 配合 composer update --lock 实现“声明即配置”，只改锁不重装

remove --no-update 后必须补哪一步？

若目标是彻底移除包并反映到运行环境，不能只靠 --no-update：

• 手动删除 vendor/<em>vendor-name</em>/<em>package-name</em> 目录（可选，但最干净）
• 运行 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 为准。