本地包根目录必须有合法composer.json且name字段与主项目require键名完全一致（含大小写、斜杠），并已git init且至少一次commit；路径支持相对或绝对，但不能含~、环境变量或未转义冒号。
直接改项目根目录的 composer.json，加 "type": "path" 仓库，本地包目录必须有合法 composer.json 且 name 完全匹配，require 时必须用 "dev-main" 这类分支名——不是版本号，也不是 *。
本地包目录结构和 composer.json 必须满足什么条件
Composer 不会自动校验你的本地包是否“可用”，它只按规则硬匹配。常见失败就卡在这一步：
- 本地包根目录下必须存在
composer.json，且其中name字段（如"myorg/my-package"）要和你在主项目中require的键名**完全一致**（包括大小写、斜杠、vendor 名） -
version字段可写"dev-main"或留空，但没用——path类型源下，Composer 只看 Git 分支名或当前 HEAD 所在分支 - 本地包目录必须已执行过
git init并至少提交一次（哪怕空 commit），否则composer update会静默跳过该包 - 路径支持相对路径（如
"../my-local-package"）或绝对路径（如/home/user/my-pkg），但不能含~、环境变量或 Windows 盘符未转义的冒号
项目 composer.json 怎么写 repositories 和 require
所有配置都必须写在**主项目根目录的 composer.json** 中，不是本地包自己的文件。顺序不重要，但字段不能错：
-
repositories是数组，每个项是对象：{"type": "path", "url": "../my-local-package"} -
require里写"myorg/my-package": "dev-main"—— 注意：不是"^1.0"，不是"*"，也不是"1.0.0"；如果本地包默认分支是develop，就得写"dev-develop" - 不要手动在
vendor/下建软链或复制文件，那会干扰 Composer 的符号链接机制
执行命令后 vendor 里为什么是个软链接而不是文件夹
这是 path 类型仓库的**预期行为**，不是错误：
- 运行
composer update myorg/my-package后，vendor/myorg/my-package实际是一个符号链接（Linux/macOS 下ls -l显示-> ../my-local-package） - 这意味着你改本地包代码，主项目立刻生效，无需重复
update或install—— 这就是“热更新”的底层实现 - 如果你看到的是普通文件夹，说明配置根本没生效（比如
repositories写错了位置、路径拼写错误、或本地包缺composer.json） - 执行
composer install前确保已运行过composer update myorg/my-package，否则install会跳过这个包（因composer.lock里没记录）
为什么 composer install 报 “Could not find package”
这个错误几乎总是源于路径或元数据不匹配，和网络无关：
- 检查主项目
composer.json中repositories的url值是否拼写正确，是否能从项目根目录真实访问到该路径（例如ls ../my-local-package/composer.json是否成功） - 确认本地包
composer.json里的name和主项目require的 key **逐字符一致**，尤其注意 vendor 名有没有多空格、下划线误写成短横等 - 运行
composer validate看是否提示repositories格式错误；运行composer show myorg/my-package看是否识别出包信息 - 别用
composer require myorg/my-package自动添加——它不会识别path源，只会去 Packagist 查，必须手动写repositories+require，再跑update
最易被忽略的一点：本地包目录下的 composer.json 如果没提交过 Git commit，即使有文件、路径对、name 对，Composer 也拒绝加载——它依赖 Git HEAD 解析分支名，不是靠文件系统扫描。
