本地path仓库必须写在项目根composer.json的根级repositories数组中,如[{"type":"path","url":"./packages/my-utils"}];url须为相对路径、指向含合法composer.json的目录,且其中name与require严格一致。

本地path仓库必须写在项目composer.json根级repositories里
Composer只读取项目根目录composer.json最外层的repositories数组,嵌套在config、require或子对象里完全无效。常见错误是把配置塞进extra或config段,结果composer install照连外网。
正确写法必须是:
{
"repositories": [
{
"type": "path",
"url": "./packages/my-utils"
}
],
"require": {
"my-utils/my-utils": "@dev"
}
}
-
url必须是相对路径,不能带file://前缀,也不能指向composer.json文件本身,只能是含该文件的目录 - Windows下绝对路径(如
C:/dev/my-utils)大概率静默失败,别试 - 哪怕只配一个仓库,也得用数组形式
[{...}],写成对象{...}会被忽略
本地包的composer.json有硬性字段要求
Composer不校验PHP代码,只认composer.json里的元数据。缺任何一项,require就失败,且错误提示模糊(常报Could not find a matching version)。
工作流任务拆解与模型编排技能。使用场景:(1) 收到复杂工作任务需要拆解为可执行步骤,(2) 需要为不同步骤选择最合适的模型,(3) 需要跟踪工作流进度和模型使用情况,(4) 长时间任务卡住需要问题诊断和解决方案。
-
name字段必须存在,且与require中写的完全一致(大小写敏感,vendor/name不能缩写) -
version字段必须存在,可填"dev-main"或"1.0.x-dev",缺失会导致解析中断 -
autoload段若存在,格式必须合法(如{"psr-4": {"My\Utils\": "src/"}}),否则类加载失败不是路径问题,而是自动加载器根本没注册 - 整个JSON语法必须正确,格式错误时Composer会跳过该仓库,不报错也不提示
symlink要手动开启且需环境支持
默认composer install对path类型是复制(copy),不是软链接。改本地代码,vendor/里不会同步——这不是bug,是默认行为。
- 启用符号链接必须显式加
"options": {"symlink": true}到repositories条目里,不是写在config里 - Linux/macOS一般可用;Windows需开启“开发者模式”或以管理员权限运行命令行,否则创建失败且无提示
-
composer install不会刷新已有链接,只补缺失项;改完本地代码后,必须执行composer update my-utils/my-utils重建链接 - 验证是否成功:
ls -la vendor/my-utils/my-utils(Linux/macOS)应显示->箭头;Windows用dir vendormy-utilsmy-utils看是否为“快捷方式”
离线生效前必须彻底禁用packagist.org
即使配了path仓库,composer install仍可能触发DNS查询或连接拒绝,根本原因是未切断默认源的fallback机制。
- 全局关掉:
composer config --global repo.packagist false - 检查项目级配置:
composer config repo.packagist输出必须为空,不能是composer https://packagist.org - 删掉项目
composer.json中repositories里任何指向https://packagist.org的条目 - 用
composer install -v观察真实请求,如果仍有Downloading https://repo.packagist.org/packages.json,说明某处配置没生效
最关键的细节:所有操作都依赖composer.json和composer.lock的一致性。一旦lock里记录的是远程包地址,再怎么配本地仓库也白搭——离线前必须在联网机上跑一次composer update --lock,再把更新后的lock文件带入离线环境。










