必须先克隆开源包到本地并配置path仓库指向该目录，否则composer require始终走packagist；repositories须置于主项目composer.json根级，url指向含合法composer.json的目录（不以/结尾），name与require逐字一致，本地包需git初始化且自身composer.json声明"options":{"symlink":true}。
不能直接用 path 仓库“导入开源依赖”——它只认你本地磁盘上已存在的、带 composer.json 的目录，不是下载器，也不是代理。 想调试某个开源包（比如 monolog/monolog），必须先把它克隆到本地，再让主项目通过 path 类型仓库指向那个克隆目录。否则 composer require monolog/monolog:dev-main 永远走 Packagist，和你的本地代码无关。
为什么 composer require vendor/name:dev-main 总报 “Could not find package”
根本不是网络或版本问题，是 Composer 根本没“看见”你的本地目录。
-
repositories必须写在主项目根目录composer.json的最外层，不能塞进require、config或其他字段里 -
url必须指向一个含composer.json的目录，不是文件本身，也不能以/结尾（"../my-pkg/"会静默失效） - 本地包目录下的
composer.json必须有合法name字段，且与require中写的逐字一致："acme/utils"≠"Acme/utils"，也 ≠"acme_utils" - 版本必须用
dev-main这类分支名，不能写1.0.0或*；本地包目录下还得有 Git 仓库（至少git init && git add . && git commit -m "init"）
改了本地源码，vendor/ 里还是旧代码？
大概率 symlink 没真正建起来，Composer 静默 fallback 到了 copy 模式。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 关键不在主项目的
repositories配置里加"symlink": true，而是在本地包自己的composer.json里声明"options": {"symlink": true} - Windows 用户必须以管理员身份运行终端，否则 symlink 创建失败且无提示
-
composer install不刷新已有链接，改完本地代码后必须运行composer update vendor/name - 验证是否真链接成功：
ls -la vendor/vendor/name（Linux/macOS）或dir vendor\vendor\name（Windows），看到->或JUNCTION才算对
path 仓库在 CI/Docker 里为什么总失败
因为 path 仓库本质是“开发期快捷方式”，上线环境根本不该存在。
- CI 构建机没有你的
../my-pkg路径，composer install会直接报错或跳过 - Docker 容器内挂载宿主机目录时，常因权限丢失 symlink 能力，需加
--cap-add=SYS_ADMIN并确认挂载方式支持符号链接 - 团队协作时，
repositories中的url建议用相对路径（如"./packages/my-utils"），避免硬编码绝对路径导致换机器失效 - 生产部署前务必删掉或注释掉
repositories中的path条目，否则上线时会崩
最容易被忽略的一点：autoload 映射不会自动更新。即使 symlink 成功，如果本地包的 composer.json 里 autoload 段没配对（比如 PSR-4 映射路径写错了），new MyClass() 依然会报 class not found——这和 path 无关，是自动加载配置没生效。
