path仓库无传统缓存，其“状态”分散于vendor目录、composer.lock及源目录结构三处；需手动删除vendor下对应包、更新lock文件，并确保repositories配置与本地包name一致才能生效。
path仓库的缓存到底存在哪
Composer 对 path 类型仓库（比如 "type": "path" 的本地包）不会走 Packagist 缓存，但它会把源目录软链接进 vendor/，同时在 Composer 内部维护一个「路径映射缓存」——关键就在 composer.json 中的 repositories 配置变动后，Composer 仍可能沿用旧的路径解析结果，尤其当你改了 symlink 目标、重命名了本地包目录、或切换了分支但没刷新状态时。
清除缓存要动哪几个地方
单纯跑 composer clear-cache 没用，它只清下载器缓存（~/.composer/cache/），不影响 path 依赖的链接逻辑。真正要处理的是：
-
vendor/下对应包的目录：直接删掉，比如rm -rf vendor/my/local-package -
composer.lock：必须删或手动删掉该包条目，否则composer install会照旧还原旧链接 - 如果用了
composer dump-autoload生成了优化类映射，也建议顺手清掉vendor/autoload_*.php文件（非必需，但可避免 autoload 错误）
重新加载 path 依赖的正确流程
删完之后不能直接 composer install —— 它只会按 lock 文件恢复，而你刚删了 lock 里的记录。必须触发重新解析依赖图：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 确保
repositories配置已更新（比如"url": "../my-new-package"） - 运行
composer update my/local-package --with-dependencies（推荐，精准更新） - 或更彻底：删掉整个
vendor/+composer.lock，再跑composer install（适合多 path 依赖联动变更） - 检查输出是否出现
Writing lock file和新路径的symlink提示，而非Installing...（后者说明还在走 zip 包安装，不是 path 模式）
为什么有时候删了还是不生效
常见卡点就两个：
-
composer.json里包名（"name"）和repositories.path.url目录下的composer.json不一致，Composer 会静默忽略该 path 条目，回退到其他仓库源 - 系统级 symlink 权限问题（尤其 Windows WSL 或 macOS SIP），导致 Composer 创建软链接失败，却假装成功，实际写入的是空目录或拷贝副本 —— 此时
ls -la vendor/my/package能立刻暴露问题
path 依赖本质是开发期便利机制，没有「缓存刷新命令」这种银弹；它的「状态」分散在 vendor、lock、源目录结构三处，少动一处，就容易连环错位。
