Composer的path仓库必须在根composer.json的repositories数组中配置"type":"path"，不能写入require；路径须为相对或绝对路径，目标目录需含合法composer.json且name、version、autoload三者齐全，修改代码后需执行composer update vendor/name而非dump-autoload。
直接在 composer.json 的 repositories 里配 "type": "path"，不是往 require 里塞路径字段——后者完全无效。
本地包路径必须写在 repositories 数组里
很多人把 "path": "./my-package" 直接加到 require 块里，结果 composer install 报 Could not find package vendor/name。这是因为 path 是仓库类型，只在 repositories 中生效。
-
repositories必须是根级数组，和require同级 -
url支持相对路径（如"../my-package"）或绝对路径（如/Users/me/my-package），但不能带file://前缀 - Windows 下可用
C:/xxx或/c/xxx，但路径中含空格或中文时容易静默失败 - 如果路径下没有合法的
composer.json（比如语法错误、少逗号、用单引号），Composer 会跳过整个仓库，不报错也不提示
本地包的 composer.json 必须满足三个硬条件
哪怕只有一行，也得有 name、version（或可识别的分支别名）、autoload。缺一不可。
-
name必须和你在require中写的完全一致，包括大小写和 vendor 名，比如"acme/utils"≠"Acme/utils" -
version字段建议显式写成"dev-main"，否则"*"可能因稳定性约束被跳过；若没写version，需配合"minimum-stability": "dev" -
autoload不只是“能加载”，还要和主项目命名空间对得上，比如本地包写"psr-4": {"Acme\Utils\": "src/"}，主项目就得能识别这个前缀
改了本地代码，为什么 vendor 里没更新？
因为 path 类型默认走软链接（Linux/macOS）或复制（Windows），但链接/复制动作只在 composer install 或 composer update vendor/name 时触发，dump-autoload 完全不碰文件结构。
- 首次引入：运行
composer require vendor/name或composer update vendor/name - 后续改了
my-package/src/Helper.php：必须再跑一次composer update vendor/name，不是dump-autoload - 想实时生效：确认本地包
composer.json的repositories配置里有"options": {"symlink": true}（Composer 2.2+ 默认启用，但老版本需显式声明） - 检查是否真链接成功：执行
ls -la vendor/vendor/name，输出应显示指向你本地路径的符号链接
CI/CD 和协作场景下最常忽略的一点
path 仓库在 CI 环境里几乎必然失败——因为路径不存在，而且 Packagist 默认优先级低于本地仓库，一旦误提交到 Git，别人 composer install 就会卡住或报错。
- 上线前必须删掉
repositories里的path条目，或用环境变量动态控制（如通过COMPOSER_REPOSITORIES注入） - 团队协作时，不要把
../my-package这种路径写死在composer.json里，改用统一目录结构（如所有包放在packages/下）并文档说明 - 如果只是临时调试，比
path更轻量的做法是直接在主项目autoload里加一条映射："MyLib\": "../my-lib/src/"，然后跑composer dump-autoload—— 这样不进vendor，也不依赖仓库配置
