执行composer remove后报Class not found，是因为它只修改composer.json和composer.lock，不自动刷新autoload映射；必须立即运行composer dump-autoload -o，若启用--classmap-authoritative或使用OPcache，还需手动opcache_reset()并检查autoload配置。

composer remove 为什么删完还报 Class not found

因为 composer remove 只改声明和锁文件，不自动刷新 autoload 映射——尤其在 Laravel 9+ 启用 --classmap-authoritative 模式下，旧映射会缓存到 vendor/composer/autoload_classmap.php 里，PHP 仍试图加载已删类。

• 执行 composer remove vendor/package 后，必须立刻补上 composer dump-autoload -o
• 若项目用了 OPcache，还得手动调 opcache_reset()，否则 PHP 从字节码缓存里拉出旧路径
• 检查 composer.json 的 autoload.psr-4 或 autoload.files，删掉已不存在的路径条目（比如还写着 "GuzzleHttp\": "vendor/guzzlehttp/guzzle/src/"）
• Docker 或 CI 环境常缓存 autoloader，加 -o 强制重生成： composer dump-autoload -o

如何判断一个包真能安全删除

不能只看它是否出现在 composer.json 里——间接依赖和运行时反射会让“看似没用”的包实际生效。

• 先查上游依赖：composer depends vendor/package，输出为空才说明没被其他已装包 require
• 再查代码调用：composer-unused --scan-path=app --scan-tests（需先 composer require --dev composer-unused/composer-unused）
• 动态加载漏网：搜索 class_exists(、new $className、配置文件里的字符串类名（如 'monolog/handler/stream'），用 grep -r 'PackageName' . --include="*.php"
• 特别注意 Laravel 的 config/app.php 中的 providers 和 aliases，这些不会被任何扫描工具捕获

批量删除多个包时的坑与对策

composer remove 支持空格分隔多包名，但失败逻辑和依赖保护机制容易被忽略。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 正确写法：composer remove spatie/laravel-permission laravel/sanctum nunomaduro/collision（不加引号、不加逗号）
• 如果其中任一包被其他已装包硬依赖（如 symfony/http-client require guzzlehttp/guzzle），命令会中止并提示谁在引用它——这不是错误，是保护
• 想跳过实时卸载？加 --no-update，只改 composer.json，后续统一 composer update；但记得之后必须补 dump-autoload -o
• Composer 2.5+ 是原子操作：成功则全部生效，失败则全部回退，不会出现 “删了一半、autoload 还指着旧路径” 的半截状态

删完后 vendor 目录还有残留文件正常吗

正常。Composer 2.2+ 默认同步删除对应目录，但若你用了 --no-update、执行中断、或锁文件污染，物理文件就可能滞留。

• 先确认 composer.json 里已无该包条目（注意大小写、vendor 名拼写）
• 最稳妥同步动作是 composer install（不是 update，后者会升级其他包）
• 若怀疑锁文件异常，可删掉 composer.lock 再跑 composer install（仅限开发环境）
• 手动检查 vendor/composer/autoload_*.php，搜索包名，确认相关条目已消失
• 别信 ls vendor/vendor-name 结果——有时目录空了但 autoload 还映射着，或者目录还在但 autoload 已清空，两者必须同时验证

真正危险的不是删不干净，而是删完没动代码里的 use、没清配置注册、没重刷 autoload 映射。这些地方不扫，上线第一秒就报错。