必须使用 path 类型仓库，因其强制启用符号链接或目录映射，跳过版本校验，使 Composer 将本地目录视为已安装包；其他方式均无法实时生效。
必须用 path 类型仓库，其他方式改代码都不生效
直接复制文件到 vendor/、手动 require 或用 vcs 仓库拉本地 Git 分支，都会导致改了代码不生效。只有 path 类型仓库能强制启用符号链接（Linux/macOS）或目录映射（Windows），跳过版本校验，让 Composer 把你的本地目录当“已安装包”对待。
常见错误现象：composer update 成功但类加载失败、new MyPackageThing() 报 Class not found、改了 src/ 里的代码却始终运行旧逻辑——本质都是没走 path 这条链路。
-
repositories必须写在主项目composer.json根级，格式为[{"type": "path", "url": "../my-pkg"}] -
url是相对于主项目composer.json的路径，不能带file://，不能以/或结尾 - 本地包根目录必须有合法
composer.json，且含完整name字段（如"acme/utils"）
name 和路径大小写、分隔符必须逐字一致
Composer 不做模糊匹配。acme/utils ≠ Acme/Utils ≠ acme_utils。90% 的 Could not find package 错误都卡在这一步。
检查三处是否完全对齐：
- 主项目
repositories.url指向的目录里，composer.json的name值 - 主项目
require中写的包名（如"acme/utils": "@dev"） - 执行
composer update acme/utils时输入的字符串
Windows 用户额外注意：路径中避免中文、空格；某些 PHP 版本解析含空格路径会静默失败。
为什么改了代码没反应？大概率 symlink fallback 了
path 仓库默认尝试创建符号链接，但失败时会静默回退到复制（copy），结果你改本地源码，vendor/ 里还是旧副本——这是最隐蔽的调试陷阱。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
关键不在主项目配 "symlink": true，而在于本地包自己的 composer.json 是否声明了 "options": {"symlink": true}。缺这句，Windows 上即使管理员权限运行终端也会 fallback；Docker 容器挂载宿主机目录时也常因权限丢失 symlink 能力。
验证是否真用了 symlink：
- Linux/macOS：
ls -la vendor/acme/utils，看到箭头（→）才是成功 - Windows：
dir vendorcmeutils，看到JUNCTION或SYMLINKD才是成功 - 若显示为普通文件夹，说明 fallback 成 copy，立刻检查本地包
composer.json是否漏了options段
autoload 不更新，类就永远找不到
path 仓库让包“存在”，但能否 new 或 use，取决于 autoload 映射是否包含它的真实路径。即使本地包写了 "psr-4": {"Acme\": "src/"}，主项目也不会自动加载——必须手动触发注册。
改完本地包的 autoload 或 autoload-dev 后，必须运行：
-
composer dump-autoload（开发阶段不用加-o） - 若改的是测试类，还得加
--dev：composer dump-autoload --dev
验证是否生效：php -r "echo class_exists('AcmeCalculator') ? 'ok' : 'fail';" 输出 ok 才算真正通了。别只盯着 vendor/ 目录看。
