最轻量可控的本地调试方式是用 path 类型仓库：在 composer.json 中配置 repositories 指向含有效 composer.json 的本地目录，require 时版本需与本地包 version 或分支名严格匹配，注意路径正确性、name 格式规范、symlink 权限及锁文件影响。

本地开发时怎么让 Composer 加载未发布的包

直接用 path 类型仓库，这是最轻量、最可控的本地调试方式。它绕过 Packagist 和网络拉取，把本地文件夹当“包源”用，改完代码立刻生效，不用反复 composer update 或打 tag。

常见错误是写错路径——比如用相对路径但没注意当前工作目录，或者路径里漏了 vendor 外层结构，导致 Composer 找不到 composer.json。另外，path 仓库默认启用 symlink（符号链接），Windows 上若没管理员权限或启用了开发者模式，会静默失败回退到 copy，结果改了源码却没反映到项目里。

• 在项目根目录的 composer.json 中添加：

  "repositories": [
    {
      "type": "path",
      "url": "../my-local-package"
    }
  ]

• url 必须指向含有效 composer.json 的目录，支持绝对路径或相对于该 composer.json 文件的路径
• 执行 composer require vendor/name:dev-main（分支名要和本地包的 composer.json 中 "version" 字段匹配，或设为 "dev-*"）
• 确认是否成功软链：ls -la vendor/vendor/name，看到箭头指向源目录才是 symlink 成功

为什么 require 后包没进 vendor 或报 “could not find package”

根本原因通常是版本约束不匹配。Composer 不会自动把本地 path 包当作“任意版本可用”，它仍严格校验 require 中写的版本号是否与本地包 composer.json 里的 "version" 或 "branch-alias" 对得上。

另一个高频坑：本地包的 composer.json 缺少 "name" 字段，或名字格式不规范（如含大写字母、下划线），导致 Composer 拒绝识别。

• 本地包必须有明确 "name"（格式：小写字母+短横线，如 "acme/utils"）
• 如果本地包没设 "version"，就用 dev-main、dev-develop 这类分支名 require；若写了 "version": "1.0.x-dev"，就得写 composer require acme/utils:1.0.x-dev
• 运行 composer show --all 可列出所有已知包（含 path 仓库），确认名字和版本是否出现在列表中
• 加 -vvv 参数重试：composer require acme/utils:dev-main -vvv，看日志里是否提示 “Skipped branch … no matching version constraint”

path 仓库和 symlink 的兼容性问题（尤其 Windows / Docker）

symlink 在 Windows 默认被禁用，Docker 容器挂载宿主机目录时也常丢失 symlink 权限。一旦失败，Composer 会 fallback 到复制整个目录进 vendor，后续本地修改就完全无效了。

Workflow Decomposer

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

下载

这不是 bug，是设计行为——Composer 把 symlink 当作优化而非保证。所以不能只靠“看起来能用”来判断是否真连上了。

• Windows 用户需以管理员身份运行终端，或启用开发者模式（Settings > Update & Security > For developers > Developer mode）
• Docker 场景下，在 docker run 加 --privileged 或使用 docker-compose.yml 的 sysctls 开启 fs.symlinks（部分系统不支持）
• 更稳妥的做法：显式禁用 symlink，在项目 composer.json 加

  "config": {
    "preferred-install": "source",
    "symlink": false
  }

  然后手动用 rsync 或脚本同步，或干脆接受 copy 行为并配合 IDE 的文件监听刷新
• 验证方式永远是看 vendor/xxx/yyy 是否为链接：Linux/macOS 用 file vendor/xxx/yyy，Windows 用 dir vendor\xxx\yyy 看有没有 <SYMLINKD>

测试完想切回稳定版，但 composer update 不生效

因为 path 仓库是“永久注册”的——只要还在 repositories 数组里，Composer 就一直优先查它。即使你删了 require，之前装过的包仍留在 vendor，且 composer.lock 记录着它的来源是 path，不是 Packagist。

这容易让人误以为“我已经切回线上版了”，实际只是没更新而已。

• 先删掉 repositories 里对应的 path 条目
• 删掉 vendor 和 composer.lock（仅限本地调试环境，CI 或协作时别这么干）
• 再 composer install，此时才会从 Packagist 拉正式版本
• 如果只想临时禁用，可用 composer config --unset repositories.my-path-repo（前提是当初用了命名 key）
• 长期维护多个环境？建议把 repositories 提到 composer.json 外，用 COMPOSER_REPOSITORIES 环境变量注入，避免手误提交调试配置

路径、版本、symlink、锁文件——这四个点串起来就是本地调试的完整闭环。漏掉任何一个，都可能卡在“明明改了却没生效”这种无头问题上。