path仓库必须写在主项目composer.json顶层repositories里,且url须以./或../开头指向含composer.json的目录;本地包需git初始化、name逐字匹配、启用symlink选项,否则静默失效。

path仓库必须写在主项目composer.json顶层repositories里
Composer只认主项目根目录下composer.json最外层的repositories字段,其他位置写的全无效。常见错误是把它塞进config、extra或require下面——那样配置完composer install完全没反应,连警告都没有。
正确结构示例:
{
"repositories": [
{
"type": "path",
"url": "../my-utils"
}
],
"require": {
"acme/utils": "dev-main"
}
}
-
url必须以./或../开头,不支持~、$HOME、绝对路径、file:// -
url指向的是含composer.json的目录,不是文件本身,末尾不能加/("../my-utils/"会静默失效) - 本地包目录必须已执行
git init && git add . && git commit -m "init",否则Composer拒绝识别
本地包的composer.json必须有合法name且启用symlink
名字不匹配是Could not find package报错的最常见原因。主项目require里写"acme/utils",本地包的composer.json里name就必须是"acme/utils"——大小写、短横线-、vendor名全部逐字一致,"Acme/utils"或"acme_utils"都不行。
工作流任务拆解与模型编排技能。使用场景:(1) 收到复杂工作任务需要拆解为可执行步骤,(2) 需要为不同步骤选择最合适的模型,(3) 需要跟踪工作流进度和模型使用情况,(4) 长时间任务卡住需要问题诊断和解决方案。
符号链接不是默认开启的,关键开关在本地包自己的composer.json里:
{
"name": "acme/utils",
"options": {
"symlink": true
}
}
- 这个
"options": {"symlink": true}必须写在本地包的composer.json中,不是主项目的 - Windows用户必须以管理员身份运行终端,否则
symlink创建失败且无提示 - Docker环境需加
--cap-add=SYS_ADMIN,否则挂载目录下无法建链接 - 验证是否生效:
ls -la vendor/acme/utils(Linux/macOS)看到->,或dir vendor\acme\utils(Windows)看到JUNCTION才算成功
改了代码没生效?大概率fallback到了copy模式
Composer在symlink失败时会静默回退到复制(copy)模式,结果你改本地源码,vendor/里还是旧副本——这是最隐蔽的问题。
-
composer install不会刷新已有链接,改完本地代码后必须运行composer update acme/utils - 如果
vendor/acme/utils是普通文件夹而非链接,说明symlink没启用,立刻检查本地包是否漏了options段 - autoload映射不会自动更新:改了本地包的
autoload配置(比如PSR-4路径),需手动运行composer dump-autoload -o - Xdebug断点打不上?确认IDE里打开的路径和磁盘真实路径一致,别用软链路径去开文件
多项目共享本地包时路径管理要小心
多个项目都引用同一个本地包时,url写法必须统一基于各自composer.json的位置。比如主项目A在/app-a,项目B在/app-b,共享包在/shared/lib,那么A里写"url": "../../shared/lib",B里就得写"url": "../shared/lib"——不能硬编码成"url": "/shared/lib",那根本不可移植。
- 团队协作时建议把共享包放在固定相对位置(如所有项目同级目录下的
packages/),降低路径歧义 - CI环境可配合环境变量或脚本动态生成
repositories,但开发机上仍推荐显式相对路径,避免依赖全局状态 - 删掉本地包目录后,
composer install会跳过该包,不报错也不提醒——这种“安静失效”比报错更难排查
ls -la vendor/xxx看是不是链接,再确认本地包composer.json里有没有options,最后看git status是否干净、有没有未提交的修改。










