path仓库不破坏原有依赖关系，但要求本地包composer.json与原包完全一致（name、require等逐字相同）；若需复用原版本约束，应使用"dev-main as x.y.z"别名，且ci前必须移除path配置。
path仓库本身不破坏原有依赖关系，但必须让本地包的composer.json和远程包完全一致，否则Composer会当作“另一个包”处理。
本地包的composer.json必须和原包一模一样
Composer 不会自动继承或补全依赖，它只读取你本地目录下composer.json里写的require字段。如果你改了本地包的composer.json，删了某个依赖、升了版本、或者加了新依赖，主项目就会按这个新配置解析——不是“保留”，而是“替换”。
- 检查原包在 Packagist 上的
composer.json（比如访问https://packagist.org/packages/vendor/name→ 点开最新版 → 查看 raw 文件） - 确保本地包根目录下的
composer.json中：name、require、require-dev、autoload字段与原版逐字相同（包括大小写、短横线、空格） - 特别注意：不要因为“只是调试”就删掉
"php": "^8.1"或"ext-curl": "*"—— 这些缺失会导致主项目 install 失败或运行时报错
用 dev-main as X.Y.Z 而不是直接写 dev-main
如果你本地包是 fork 自 guzzlehttp/guzzle v7.5.0，但没发布新版本，直接写 "guzzlehttp/guzzle": "dev-main" 会让 Composer 认为这是个全新分支，可能跳过原本由 v7.5.0 锁定的依赖约束（比如某些插件只兼容 7.5.x）。这时要显式做版本别名：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
"require": {
"guzzlehttp/guzzle": "dev-main as 7.5.0"
}
-
as后面的版本号必须和原包composer.json中的version或 Packagist 上发布的稳定版本号一致 - 这能让
composer install继续沿用composer.lock中已解析的依赖树，避免重算整个图 - 别写
"dev-main as 7.6.0"—— 如果原包没发过 7.6.0，Composer 会报错找不到匹配版本
repositories 配置不能干扰其他源
path 类型仓库优先级高于 packagist.org，但只对 name 完全匹配的包生效。只要配置正确，它不会影响其他包的解析路径。不过容易踩的坑有：
- 别把多个 path 条目写成同名包（例如两个
"type": "path"都指向不同目录，但name都是acme/utils），Composer 只用第一个，后一个静默忽略 - 不要在
repositories里混用"type": "package"和"type": "path"指向同一个name，否则行为不可预测 - CI/CD 构建前务必移除
repositories中的 path 条目，否则 build 会失败（路径不存在），且可能导致依赖被错误地 fallback 到 dist 模式而丢失 autoload 映射
最常被忽略的一点：即使所有配置都对，如果本地包的 autoload 段没声明 PSR-4 或 files，主项目也加载不到类——这不是依赖关系问题，而是自动加载失效。验证方式很简单：composer dump-autoload -o 后，检查 vendor/composer/autoload_psr4.php 里有没有你本地包的命名空间映射。
