composer remove 和 composer update --refresh 是 Composer 仅有的两个原子操作命令：前者一次性校验依赖、删文件、改声明、更新 lock 并重建 autoload；后者丢弃所有本地元数据快照，直连镜像拉最新 packages.json 并重做完整依赖求解，失败即回退，不留下半截状态。

Composer 的 remove 和 update --refresh 是目前仅有的两个明确标注为原子操作的命令——它们不是“尽量做全”，而是失败即回退，不留下半截状态。别被“原子”二字吓住，它本质是 Composer 内部把多步动作打包成一个不可中断的事务。

composer remove 是怎么做到原子卸载的

它不是先删 vendor 再改 composer.json，而是一次性校验依赖图、同步删文件、删声明、更新 lock、重建 autoload 映射。任何一步失败，整个操作就中止，不会出现“vendor 没了但 composer.json 还留着”的错乱状态。

• 自动识别包在 require 还是 require-dev 区域，不用加 --dev（除非同名包同时出现在两个区）
• 执行 composer remove monolog/monolog 后，vendor/monolog/monolog 目录、composer.json 里对应行、composer.lock 中的哈希记录，全部同步清理
• 如果该包被其他已安装包硬依赖（比如你删 guzzlehttp/guzzle，但 symfony/http-client 依赖它），命令会直接报错并列出引用链，这是保护机制，不是 bug
• 想跳过实时重装？加 --no-update：只改 composer.json，后续统一跑 composer update，适合 CI 分阶段流程

composer update --refresh 强制刷新元数据的真相

composer update --refresh 不是“清缓存 + update”，而是丢弃所有本地 metadata 快照，直连镜像源拉最新 packages.json，再基于它做完整依赖求解。低于 Composer 2.5 的版本不支持该参数，强行使用会报 Unrecognized option "--refresh"。

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

• 它解决的是“明明镜像源已更新包版本，composer update 却不拉新”的问题——旧 metadata 缓存让你以为没新版本
• 不推荐日常使用，只在确认镜像源已同步新版但本地始终拉不到时触发
• 执行后，vendor/composer/installed.json 和 composer.lock 都会被重写，但不会动你项目代码或配置
• 如果你用的是私有仓库或自建 Packagist，确保其 packages.json 文件确实已更新，否则 --refresh 也拉不到不存在的版本

为什么手动删 vendor 或改 composer.json 很危险

因为 autoload 映射和 lock 文件哈希是强耦合的。你手删 vendor/foo/bar，但 composer.lock 还记着它的 SHA256，下次 composer install 就会校验失败；你手改 composer.json 删掉一行，但没运行 dump-autoload，Class not found 就立刻报给你看。

• composer remove 自动触发 dump-autoload，但如果你用了 --classmap-authoritative（Laravel 9+ 默认开启），删包后必须显式执行 composer dump-autoload --classmap-authoritative
• 某些环境（如 Docker 构建层、CI runner）会缓存 autoloader，此时加 -o 强制优化生成：composer dump-autoload -o
• 检查 composer.json 的 autoload.files 或 autoload.psr-4，是否还残留已删包的路径映射，手动删掉，否则 autoload 仍会尝试加载不存在的文件

原子操作真正难的不是命令怎么敲，而是理解它背后“状态一致性”的约束：Composer 不信任人眼判断，只信任锁文件 + autoload 映射 + vendor 目录三者完全对齐。哪怕你只是多删了一个空格，都可能让后续 install 卡在哈希校验上。