根本原因是composer未在repositories中配置本地path源，require仅声明需求而不指定来源；需在主项目composer.json根级添加type为path的源，路径相对且本地包含匹配name的composer.json，并用dev-main等分支名约束版本。
为什么composer require vendor/name:dev-main总报“Could not find package”
根本原因不是网络或权限，而是 Composer 根本没“看见”你的本地目录。它只在 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 所在分支
怎么让改完本地包代码立刻在主项目里生效
默认行为是复制（copy），不是链接（symlink）。这意味着你改了 ../my-package/src/Helper.php，vendor/acme/utils/Helper.php 还是旧文件。
必须显式启用符号链接：
- 在主项目
composer.json的repositories条目里加"options": {"symlink": true} - 或者，在本地包自己的
composer.json里加同样字段（效果等价） - 执行
composer update acme/utils（不是dump-autoload），才会重建 symlink - 验证是否成功：
ls -la vendor/acme/utils应显示箭头指向源目录；Windows 用户用dir vendorcmeutils看是否为“快捷方式”类型
注意：Windows 需开启开发者模式或以管理员权限运行命令行，否则 symlink 创建会失败且无提示。
path 仓库和普通远程仓库的关键区别在哪
不是“能不能装上”，而是“怎么装、怎么更新、怎么维护”。path 类型跳过所有元数据请求（不连 Packagist、不查 packages.json），直接读取本地 composer.json 内容，因此它天然离线、极快，但也更脆弱。
- 不支持
composer install自动发现：必须先require，再update，否则vendor里什么都不会有 - 无法自动同步版本号：本地包改了
composer.json里的version，主项目不会感知，仍按当前 Git 分支名解析（如dev-main） - 本地包目录必须已运行
git init并至少有一个 commit，否则 Composer 拒绝加载 - 若本地包未打 tag，
version字段建议设为"dev-main"或"1.0.x-dev"，并在主项目中对应使用"dev-main"
本地包 Class not found 怎么办
90% 和 Composer 本身无关，而是自动加载配置或框架注册链路断了。
- 确认本地包的
composer.json里有正确的autoload配置，例如："psr-4": {"Acme\Utils\": "src/"} - 运行
composer dump-autoload（开发阶段不用加-o），否则新命名空间不会注册进自动加载器 - 如果包提供了 Laravel
ServiceProvider或Facade，必须手动在config/app.php的providers或aliases里注册——Composer 不处理这部分 - 别在
require 'vendor/autoload.php'之前就实例化类，也别用相对路径引入 autoload 文件
真正容易被忽略的是：即使 symlink 成功、vendor 目录里能看到链接，只要 autoload 没配对或没重生成，类就一定找不到——这一步和路径配置完全解耦，但常被当成“配置失败”反复折腾。
