必须用 repositories 的 path 类型声明本地包,require 中不能直接写相对路径;需确保本地包 composer.json 的 name 与 require 一致、启用 "symlink": true 实现热更新,并上线前移除 path 仓库。

用 path 类型仓库,而不是改 require 写本地路径
Composer 不支持在 require 里直接写 "myorg/utils": "../my-local-package" 这种路径——它会报 Could not find package。必须通过 repositories 声明一个本地“源”,让 Composer 把你硬盘上的目录当成一个合法包仓库来用。
- 在项目根目录的
composer.json里加repositories字段,类型设为path,url指向含composer.json的本地目录(相对或绝对路径都行) - 本地包目录下必须有合法的
composer.json,且其中name字段要和你在require里写的完全一致(比如"name": "myorg/utils") - 本地包的
composer.json中建议显式写"minimum-stability": "dev",否则可能因版本约束不匹配而安装失败
symlink: true 是热更新的关键,不是可选项
默认情况下,Composer 对 path 仓库会硬拷贝文件到 vendor/,改了本地包代码不会自动生效。只有启用符号链接,才能实现“改完即用”。
- 在
repositories条目里加上"options": {"symlink": true} - Linux/macOS 下天然支持软链;Windows 默认用复制,但只要 Git Bash 或 WSL 环境可用,也能生效(需确保 Composer 运行在支持 symlink 的 shell 中)
- 如果看到
vendor/myorg/utils是个真实文件夹而非快捷方式/链接,说明没生效——检查是否漏了options,或 Windows 上未启用开发者模式
别把 path 仓库提交到生产环境
path 仓库只对开发有意义。上线前必须删掉或注释掉 repositories 里的 path 条目,否则部署时会因路径不存在而失败(尤其是 CI/CD 环境根本找不到 ../my-local-package)。
- 推荐做法:用
COMPOSER_HOME或不同环境的composer.json变体隔离(例如开发用composer-dev.json),或上线前用脚本自动清理 - 如果误提交了,错误现象通常是
Source directory ../xxx does not exist或Could not scan for classes(autoload 失败) - 注意:
path仓库优先级高于 Packagist,哪怕你写了"prefer-stable": true,它也会先找本地路径——这点容易被忽略,导致你以为拉的是稳定版,其实用的是本地 dev 分支
常见报错和对应检查点
几乎所有失败都卡在这三处:路径不对、名字不一致、没清缓存。
-
Could not find package myorg/utils→ 检查本地包composer.json的name是否拼写一致(包括大小写、斜杠方向),以及主项目require是否用了完全相同的字符串 -
Source directory ../xxx does not exist→url是相对于composer.json的路径,不是相对于命令行当前目录;建议用绝对路径临时验证 - 装上了但类找不到(
Class not found)→ 本地包composer.json里autoload配置是否正确?运行composer dump-autoload强制重生成映射 - 改了代码不生效 → 先确认
symlink: true已配置;再检查vendor/myorg/utils是否是链接(ls -la或dir查看);最后试composer update myorg/utils --no-cache强制刷新
path 就稳了。其他花哨配置都是锦上添花,但这里错一个,就进不了 vendor。










