composer remove 无法自动识别 thinkphp 冗余扩展，因其仅依据 composer.json 删除声明包，不扫描代码、配置或服务注册；需人工验证是否启用（查 config/、grep 代码、检查 provider/middleware、运行 php think service:discover），再结合 composer remove 安全卸载，并清理 runtime/ 缓存与 composer 全局缓存。
Composer 本身没有“移除 ThinkPHP 冗余扩展包”的内置能力——composer remove 只能删 composer.json 里声明的包，不会识别“TP 项目中实际没用到的扩展”。所谓“冗余”，得靠你人工判断，不是 Composer 自动发现的。
为什么 composer remove 不能自动清 TP 扩展
ThinkPHP 的扩展（比如 topthink/think-queue、topthink/think-captcha）一旦被 require 进项目，就和其他 PHP 包一样，只受 composer.json 约束。Composer 不扫描你的控制器、中间件或配置文件，根本不知道某个扩展是否真被调用过。
-
composer remove topthink/think-queue会删包 + 更新composer.lock+ 卸载自动加载规则，但前提是它在composer.json里 —— 如果是手动拷进vendor/或通过其他方式引入，Composer 完全无感 - 很多 TP 项目用
composer create-project topthink/think初始化，自带一堆可选扩展，但后续没启用，它们就静静躺在vendor/里，composer remove不会主动找出来 - 执行
composer outdated只能看出哪些包有新版，看不出哪个包“压根没用”
真正该清理的不是扩展包，而是缓存和临时文件
TP 项目体积膨胀的主因往往不是扩展包本身，而是 Composer 缓存（~/.composer/cache/files/）里积压的旧版 .zip，以及 runtime/ 目录下的日志、模板缓存、路由缓存等。这些才是“垃圾缓存”的主力。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先确认缓存大小：
composer config --global cache-dir查路径，再du -sh $(composer config --global cache-dir)（Linux/macOS）或打开%APPDATA%\Composer\Cache（Windows）看属性 - 超过 1GB？直接运行
composer clear-cache—— 它会清掉files/（所有 ZIP）、repo/（元数据）、vcs/（Git 克隆），但不碰vendor/和composer.lock - 别忘了 TP 自己的缓存：
runtime/log/、runtime/cache/、runtime/template/可以安全清空，TP 启动时会重建 - 如果用了
think-swoole或think-worker，检查runtime/swoole/或runtime/worker/下的 PID 文件和日志，这些也容易堆积
怎么识别哪些 TP 扩展其实没被使用
没有全自动方案，但可以快速筛一遍：进项目根目录，用命令定位疑似“未启用”的扩展。
- 查
config/下有没有对应配置文件（比如queue.php、captcha.php），没有 → 很可能没启用 - 搜代码：
grep -r "think-queue" app/ --include="*.php" 2>/dev/null | head -3，如果完全没结果，基本可判定未调用 - 检查
app/middleware.php和app/provider.php，看是否注册了对应服务提供者（如think\queue\QueueServiceProvider） - 运行
php think service:discover（TP6.1+），看输出里有没有那个扩展的服务名；没有，说明框架没加载它
删之前务必确认 vendor/ 是否干净
很多人以为清了缓存就等于“项目变轻”，其实 vendor/ 才是占空间大头。但 composer clear-cache 从不碰它 —— 所以如果你真想瘦身，得手动处理：
- 先备份：
cp -r vendor/ vendor.bak（Linux/macOS）或复制粘贴（Windows） - 删扩展前，确保它没被任何
use或class_alias引用：grep -r "Queue" app/ --include="*.php" 2>/dev/null - 删包后跑一次
composer dump-autoload -o，避免自动加载失效 - 最保险的做法：删完跑
php think optimize:schema（TP6）或php think optimize:route，验证核心功能是否正常
真正容易被忽略的是：TP 项目里混用的私有扩展、手动 require 的类库、甚至 extend/ 目录下的自定义模块，Composer 根本不管理它们。这些“非标准引入”的东西，得你自己翻代码、看文档、问同事 —— 缓存命令再快，也清不掉认知盲区。
