Composer install 不识别本地包因默认只拉取远程仓库，需在 composer.json 的 repositories 中配置 type 为 "path" 并指定 url 路径，且 require 的包名须与本地包 composer.json 中 name 一致；执行 composer update 而非 install 才能创建 symlink。
composer install 本地包时为什么报错 “Could not find package xxx”
因为 Composer 默认只从 packagist.org 或你配置的仓库拉取远程包，composer require 不会自动识别你本地文件夹里的包。必须显式告诉 Composer：这个包存在本地，且路径在哪。
在 composer.json 中配置 repositories type path
这是最常用、最稳妥的方式，适合开发中频繁修改的扩展包。关键点是：repositories 必须是数组，type 设为 "path"，url 填相对或绝对路径（推荐相对路径）。
{
"repositories": [
{
"type": "path",
"url": "./packages/my-local-package"
}
],
"require": {
"vendor/my-local-package": "*"
}
}
注意：vendor/my-local-package 必须和该包 composer.json 中定义的 name 字段完全一致；"*" 表示允许任意稳定版本（Composer 会自动匹配最新可用的本地版本）。
- 路径支持通配符，比如
"./packages/*"可一次性注册多个本地包目录 - 如果路径含空格或特殊字符，确保 shell 环境能正常解析（Windows 下建议用正斜杠或双反斜杠）
- 执行
composer update vendor/my-local-package才会触发 symlink，不是install
为什么 require 后没生成 vendor/vendor/my-local-package 的软链接
常见原因有三个：composer.json 中包名不匹配、路径不存在、或未运行 update。Composer 的 path 类型仓库不会在 install 时生效，它只在 update 阶段扫描本地目录并建立符号链接。
- 检查目标包根目录下是否存在有效的
composer.json，且含"name"字段 - 运行
composer update vendor/my-local-package --no-scripts可跳过脚本避免干扰 - Linux/macOS 下确认终端有权限创建 symlink；Windows 需启用开发者模式或以管理员运行终端
- 若已存在同名远程包缓存，先运行
composer clear-cache
用 path 方式引入后，修改本地包代码为何不实时生效
因为 Composer 创建的是符号链接（symlink），不是复制文件。只要链接存在，修改 ./packages/my-local-package 里的代码，项目中 vendor/... 下立刻可见——但 PHP OPcache 会缓存已加载的类文件。
- 开发时务必关闭 OPcache（
opcache.enable=0），或调用opcache_invalidate()清理单个文件 - 某些 IDE（如 PHPStorm）可能缓存类结构，需手动刷新项目索引
- 若用
autoload-dev加载测试类，记得在本地包的composer.json中正确配置
path 方式本质是“本地开发模式”，它绕过了版本约束和网络依赖，但也意味着你失去了 packagist 的版本隔离能力——多个项目共用同一份本地源码时，要格外注意分支与提交状态。
