path仓库url必须为相对路径（如"../shared-utils"），name字段须与require完全一致，启用symlink需在本地包composer.json中配置"options":{"symlink":true}，且repositories须置于主项目composer.json顶层。
path仓库的url必须是相对路径，且从主项目composer.json算起
Composer只认以./或../开头的路径，~/pkg、/home/user/pkg、file://全都不行——不是报错，而是静默跳过整个仓库。比如你要引用上一级目录的shared-utils包，就得写"url": "../shared-utils"，不能写"url": "shared-utils"（缺./前缀）或"url": "/full/path/shared-utils"（绝对路径）。Windows下也一样，别加C:/盘符，"../my-lib"就足够。
本地包的name字段必须和require字符串逐字一致
这是跨项目调试失败最常见原因。大小写、vendor名、分隔符一个都不能错：acme/utils ≠ Acme/Utils ≠ acme_utils。主项目require里写的是"acme/utils": "dev-main"，那本地包根目录下的composer.json里"name"就必须是"acme/utils"，不能多空格、不能少斜杠、不能用下划线替代短横线。
- 本地包没
git init也没关系，但必须有"version": "dev-main"，否则Composer无法识别分支别名 - 别把
repositories配置写进本地包自己的composer.json里——它对主项目完全无效 -
repositories必须放在主项目根composer.json最外层，和require、config平级，不是extra的子项
改代码不生效？大概率symlink没真正启用
默认情况下，path仓库走的是复制（copy）模式，你改本地源码，vendor/里还是旧副本。要热更新，必须在**本地包自己的composer.json里**加"options": {"symlink": true}。主项目配了没用，漏掉这句，Windows即使管理员权限也会fallback，Docker容器里更常见。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 验证是否成功：
ls -la vendor/acme/utils（Linux/macOS）应看到->指向源目录；Windows用dir vendor\acme\utils看是否为“快捷方式”类型 - 首次引入必须用
composer update acme/utils，install只读composer.lock，不重新解析仓库类型 - 改了本地包的
autoload映射（比如新增PSR-4命名空间），必须手动执行composer dump-autoload -o刷新自动加载器
生产部署时路径仓库会直接报错，不能靠“自动回退”
Composer设计上不支持路径不存在时自动切到Packagist，它会直接中断并报错。这意味着你绝不能把repositories.path配置提交到主干分支。推荐做法是：
- 开发环境用
composer config repositories.local path ../shared-utils临时添加（不写入composer.json） - CI/CD流程中用脚本在构建前移除
repositories块，或用环境变量动态生成配置 - 团队协作时，把本地路径配置放在
.gitignore的composer.json副本里，避免误提交
跨项目调试的核心不在“怎么连”，而在“怎么断得干净”——路径仓库是开发期的临时通道，不是长期依赖方案。
