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、源目录结构三处，少动一处，就容易连环错位。