--no-cache 仅禁用本地包缓存（~/.composer/cache）和远程 HTTP 缓存，不影响 Git 镜像、插件加载、autoloader 映射及 vendor 复用。
加 --no-cache 能跳过本地包缓存和远程 HTTP 缓存，但不能跳过 Git 克隆缓存、插件加载或 autoloader 缓存——它只作用于元数据获取与 zip 包下载环节。
composer install/update 加 --no-cache 到底禁了什么
这个参数明确跳过两层：一是 ~/.composer/cache 下已下载的 zip/tar 包和 metadata；二是远程请求时的 HTTP 缓存（如 ETag、304 响应）。但它不碰以下内容：
-
vendor/目录里的代码，哪怕你删了再装，只要 lock 文件没变，它仍可能复用旧 vendor 内容 -
~/.composer/cache/vcs/里的 Git 镜像，改了分支 URL 也不触发重新 clone - 插件（如
hirak/prestissimo）是否激活，不受影响 - autoloader 的映射逻辑，
composer dump-autoload仍需手动执行
为什么加了 --no-cache 还是拉旧 commit
因为 Composer 默认复用 ~/.composer/cache/vcs/ 下的 Git 镜像。即使加了 --no-cache，只要 remote URL 和 reference（如 branch 名）没变，它就直接 git checkout 已有镜像里的 commit。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 验证方式：
ls -la ~/.composer/cache/vcs/https---github.com-vendor-package.git/，看最后修改时间 - 强制刷新：删对应镜像目录，或临时设
COMPOSER_CACHE_DIR=/dev/null - 更稳做法：对单个包更新用
composer update vendor/package --with-dependencies，它会比对远程 HEAD
禁用缓存的可靠组合命令
只靠 --no-cache 容易漏掉关键缓存层。真要“从零重建”，得按顺序做三件事：
- 删掉
vendor：rm -rf vendor（Windows 用rmdir /s vendor） - 清空全部缓存：
composer clear-cache（确认输出含Clearing cache (all)） - 无缓存重装：
composer install --no-cache（不是update，除非你要重算依赖）
CI 环境还要额外加一层保险：COMPOSER_CACHE_DIR=$(mktemp -d) composer install --no-cache，彻底隔离 runner 挂载的缓存目录。
容易被忽略的副作用和边界
--no-cache 不影响插件行为，也不阻止 composer-plugin-api 加载；它也不改变 composer.json 中 repositories 的配置逻辑。如果你在调试镜像源同步问题，光加 --no-cache 不够，还得配合 -vvv 看真实请求头，甚至手动在 repositories 里加 "Cache-Control: no-cache" HTTP 头。Git 镜像、VCS 缓存、插件激活、autoloader 映射——这四块各自独立，没有一个开关能一并关掉。
