必须在主项目 composer.json 的 repositories 中添加 path 类型源并启用 symlink，否则本地包无法被识别和实时生效；原因在于 Composer 仅从 repositories 查找包，require 仅声明依赖，且 path 源下必须用 dev-main 等分支名、name 必须严格匹配，更新需执行 composer update vendor/name。
直接结论：不是改 require 字段，而是必须在主项目 composer.json 的 repositories 里加 {"type":"path","url":"../my-package"}，且本地包目录下要有合法 composer.json，name 和 require 中的包名必须完全一致。
为什么 composer require vendor/name:dev-main 报 “Could not find package”
根本原因不是网络或权限，而是 Composer 根本没“看见”你的本地目录。它只从 repositories 数组里找源，require 字段只声明“我要谁”，不负责“去哪找”。常见错误包括：
-
repositories写在了本地包自己的composer.json里，而不是主项目的 -
url写成绝对路径（如C:\packages\my-pkg），Windows 下极易静默失败 - 本地包目录下没有
composer.json，或其中name字段拼写/大小写不匹配（如写成"Vendor/name"而 require 是"vendor/name"） - 版本约束用了
"1.0.0"或"*"—— path 源下必须用dev-main、dev-develop这类分支名，Composer 忽略version字段，只认当前 Git HEAD 所在分支
怎么让改完本地包代码立刻在主项目里生效
默认行为是复制（copy），不是链接（symlink）。你改了 ../my-package/src/Helper.php，vendor/vendor/name/Helper.php 还是旧文件。必须显式启用符号链接：
- 在主项目
composer.json的repositories条目里加"options": {"symlink": true} - 或在本地包自己的
composer.json里加同样字段（效果等价） - 执行
composer update vendor/name（不是dump-autoload，也不是无参数的update）才会重建 symlink - 验证是否成功：
ls -la vendor/vendor/name应显示->指向源目录；Windows 用户用dir vendor\vendor\name看是否为“快捷方式”类型 - Windows 需开启开发者模式或以管理员权限运行命令行，否则 symlink 创建会失败且无提示
composer install 和 composer update vendor/name 的行为差异
composer install 只重建缺失的链接，不会刷新已有 symlink 的目标路径。它依赖 composer.lock 记录的解析结果，而这个结果在首次 require 或 update 时就已固化。也就是说：
- 改完本地包代码后，
composer install什么也不做 - 必须运行
composer update vendor/name才会重新解析 path、重建 symlink -
composer update不带参数会全量重算，慢且易引入意外变更；指定包名更快、更安全 - CI/CD 环境下 symlink 必然失败（路径不存在），上线前必须移除
repositories中的 path 条目
最关键的细节往往藏在路径和权限里：相对路径要从主项目 composer.json 位置算起，Windows 的 symlink 支持不是默认开启的，而 composer.lock 一旦生成，就不会因本地代码改动自动更新链接——这些点不手动触发 update 就永远卡住。
