答案是path仓库未配对或symlink静默fallback为copy：需确保主项目composer.json正确配置path源、本地包composer.json含"options":{"symlink":true}、路径权限正确，且验证ls -la输出是否为符号链接。
本地改了代码，主项目里不生效？不是 autoload 没刷新，而是根本没连上——Path 仓库没配对，或 symlink 被静默 fallback 成 copy。
为什么 composer require vendor/name:dev-main 报 “Could not find package”
Composer 根本没“看见”你的本地目录。它只从主项目 composer.json 的 repositories 数组里找源，require 字段只是声明“我要谁”，不负责“去哪找”。
-
repositories必须写在主项目（你正在运行composer install的那个项目的）composer.json里，不能写在本地包自己的composer.json中 -
url必须是相对路径（如"../my-pkg"），绝对路径在 Windows 上极易静默失败（盘符、反斜杠、空格都会中断） - 本地包目录下必须有合法的
composer.json，且其中name字段（如"acme/utils"）要和require里写的完全一致（大小写敏感） - 版本约束必须用
dev-main、dev-develop这类分支名，不能写1.0.0——path 源下 Composer 忽略version字段，只认当前 Git HEAD 所在分支
怎么让改完本地包代码立刻在主项目里生效
默认行为是复制（copy），不是链接（symlink）。你改了 ../my-pkg/src/Helper.php，vendor/acme/utils/Helper.php 还是旧文件。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须显式启用符号链接：在**本地包自己的**
composer.json里加"options": {"symlink": true}（主项目配了没用，关键在本地包） - 执行
composer update acme/utils（不是dump-autoload），才会重建 symlink - 验证是否成功：
ls -la vendor/acme/utils应显示箭头指向源目录；Windows 用户用dir vendor\acme\utils看是否为“快捷方式”类型 - Windows 需开启开发者模式或以管理员权限运行命令行，否则 symlink 创建会失败且无提示
Path 仓库在 Docker 或 CI 环境下为什么失效
因为 path 类型仓库依赖宿主机上的真实路径，而容器或构建机上根本没有 ../my-pkg 这个目录。
- CI 流水线每次拉取代码都得重新
composer install，而 path 源只存在于你本地磁盘——一旦构建机上缺失对应路径，整个流程就中断 - Docker 场景需在
docker run时加--cap-add=SYS_ADMIN，并确保挂载方式支持 symlink（例如用-v $(pwd)/../my-pkg:/app/packages/my-pkg显式挂载） - 上线前必须删掉
repositories中的 path 条目，换成私有仓库地址（如 Satis / Private Packagist），并提交更新后的composer.lock - 生产环境永远不要保留 path 配置，它仅限本地联调
最隐蔽的问题是 symlink fallback：路径权限不对、Windows 未提权、Docker 未加 cap，都会导致 Composer 静默退回到 copy 模式——你以为改了就生效，其实 vendor 里还是旧副本。验证必须动手看 ls -la 或 dir 输出，不能靠“我配了就应该对”。
