根本原因是Composer只在主项目composer.json的repositories中查找本地包路径，且要求路径为相对路径、name严格匹配、版本用dev分支名，并需配置"symlink":true才能实时同步修改。

为什么加了 path 仓库后 composer install 还报 “Could not find package”

根本原因不是网络不通，而是 Composer 根本没“看到”你的本地目录——它只在主项目 composer.json 的 repositories 数组里找源，require 字段只声明“要什么”，不负责“去哪拿”。

• repositories 必须写在主项目（你当前 cd 进入的那个项目）的 composer.json 里，不能写在本地包自己的 composer.json 中
• url 必须是相对路径（如 "../my-utils"），Windows 上用绝对路径（C:\dev\my-utils）会静默失败
• 本地包目录下必须有合法 composer.json，且其中 name（如 "acme/utils"）要和 require 里写的完全一致（大小写敏感）
• 版本约束必须用 dev-main、dev-develop 这类分支名，不能写 1.0.0 —— path 源下 version 字段被忽略，只认 Git HEAD 所在分支

composer install 后 vendor/ 里没变？改本地代码不生效

默认行为是复制（copy），不是符号链接（symlink）。你改了 ../my-utils/src/Helper.php，vendor/acme/utils/Helper.php 仍是旧文件。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 必须在 repositories 条目里显式加 "options": {"symlink": true}
• 执行 composer update acme/utils（不是 dump-autoload，也不是无参数的 update）才会重建链接
• 验证是否成功：ls -la vendor/acme/utils 应显示 -> ../my-utils；Windows 用户用 dir vendor\acme\utils 看是否为“快捷方式”类型
• Windows 需开启“开发者模式”或以管理员权限运行命令行，否则 symlink 创建失败且无提示

生产部署时 path 仓库导致失败怎么办

Composer 在解析阶段就校验 path 目录是否存在，不存在直接报错，不会自动 fallback 到 Packagist。这不是 bug，是设计使然：明确优于隐式。

• CI/CD 流程中必须移除 repositories 里的 path 条目，不能靠“关镜像”或“换源”绕过
• 推荐用环境变量或构建脚本动态生成 composer.json，开发环境保留 path，生产环境输出干净版本
• 更稳妥的做法是用 Studio 工具管理本地包，它通过临时修改配置工作，不把 path 提交进 Git
• 所有本地包必须有对应远程源（GitHub + Packagist），确保 composer install 在无 path 时仍能完整还原依赖

composer install 和 composer update 对 path 仓库的行为差异

install 只按 composer.lock 还原，不重新解析路径；update 才真正触达本地目录并重建链接——这点容易被忽略。

• composer install 不会刷新已有 symlink，即使你改了本地包的 Git 分支或内容
• composer install --prefer-source 仅在首次安装且 vendor/ 为空时尝试创建 symlink，但前提是已配置 "options": {"symlink": true}
• composer update acme/utils 是唯一可靠方式：它强制重新读取本地 composer.json、校验 name、检查路径存在性，并重建 symlink
• 如果 vendor/acme/utils 已存在，install 会跳过 symlink 步骤；update 则会先删再建

注意：path 仓库跳过所有元数据请求，因此它快得离谱，但也最脆弱——路径错一位、name 拼错、少个 options，就卡在“找不到包”。别指望 Composer 帮你猜意图，它只按字面执行。