答案：根本原因是composer未在主项目composer.json的repositories中配置path源，导致其无法发现本地包；需正确添加type为path、url为相对路径、options含symlink:true的仓库条目，并执行composer update而非install。
为什么composer require vendor/name:dev-main报“Could not find package”
根本不是网络或权限问题，是 Composer 根本没“看见”你的本地目录。它只在主项目 composer.json 的 repositories 数组里找源，require 字段只负责声明“我要哪个包”，不负责“去哪找”。
-
repositories必须写在主项目（即你正在开发的那个项目的）composer.json里，不能写在本地包自己的composer.json中 -
url必须是相对路径（如"../my-package"），绝对路径在 Windows 上极易静默失败（盘符、反斜杠、空格都会中断） - 本地包目录下必须有合法的
composer.json，且其中name字段（如"acme/utils"）要和require里写的完全一致（大小写敏感） - 版本约束必须用
dev-main、dev-develop这类分支名，不能写1.0.0—— path 源下 Composer 忽略version字段，只认当前 Git HEAD 所在分支
如何正确配置repositories实现本地包加载
直接在主项目 composer.json 的 repositories 数组中添加一条 path 类型条目，不是往 require 里塞路径。
- 示例配置：
{ "repositories": [ { "type": "path", "url": "../my-package", "options": { "symlink": true } } ], "require": { "acme/utils": "dev-main" } } -
url是相对于主项目根目录的路径，不是相对于composer.json文件本身 -
"options": {"symlink": true}必须显式声明，否则默认行为是复制（copy），改了本地包代码不会生效 - 执行
composer update acme/utils（不是dump-autoload），才会重建符号链接
本地包改了代码不生效？检查 symlink 是否真生效
默认是复制，不是链接。你改了 ../my-package/src/Helper.php，vendor/acme/utils/Helper.php 还是旧文件。
- 验证是否成功：Linux/macOS 下运行
ls -la vendor/acme/utils，应显示箭头指向源目录；Windows 下用dir vendor\acme\utils看是否为“快捷方式”类型 - Windows 用户需开启“开发者模式”或以管理员权限运行命令行，否则
symlink创建会失败且无提示 - 如果已配
"symlink": true但依然没链接，先删掉vendor/acme/utils目录再跑一次composer update acme/utils - 不要依赖
composer install自动发现 path 包——它不会自动创建 symlink，必须先require，再update
path仓库和 Packagist 远程仓库的关键区别在哪
不是“能不能装上”，而是“怎么装、怎么更新、怎么维护”。path 类型跳过所有元数据请求（不连 Packagist、不查 packages.json），直接读取本地 composer.json 内容，因此它天然离线、极快，但也更脆弱。
- 不支持
composer install自动发现：必须先require，再update，否则vendor里什么都不会有 - 无法自动同步版本号：本地包改了
composer.json里的version，主项目不会感知；它只看 Git 分支名（如dev-main对应main分支 HEAD） - 没有远程校验和缓存机制，出错时 Composer 不会回退或提示元数据缺失，而是直接报错或静默失败
- 调试时别忘了：每次改完本地包，都要确保它所在 Git 分支是干净的，否则
dev-main可能指向一个未提交的修改状态，导致行为不可预期
