本地path仓库优先级高于Packagist，但须显式配置为type: "path"并置于repositories数组首位，且包名、版本、路径必须严格匹配；否则Composer将跳过本地仓库转而查询Packagist。
composer install 时本地 path 仓库和 Packagist 谁先被选中？
本地 path 仓库优先级高于 Packagist，但前提是它被正确声明且匹配版本约束。Composer 不会“自动发现”你机器上任意路径的包，必须显式配置为 repository 类型为 path，并且该路径下存在合法的 composer.json。
常见错误现象：明明在项目根目录旁放了 my-package/，composer require my-vendor/my-package 却还是从 Packagist 下载——因为没配 repositories，或者路径写错（如漏掉 ../my-package 中的 ..）。
实操建议：
- 在
composer.json的repositories数组里，把path类型仓库放在最前面（顺序影响解析优先级） - 路径必须是相对或绝对真实路径，支持通配符（如
"../packages/*"），但需确保目标目录含有效composer.json - 版本号必须严格匹配：若本地包
composer.json中"version": "dev-main"，则 require 时得写"my-vendor/my-package": "dev-main"；写"^1.0"会跳过 path，转而查 Packagist -
composer show my-vendor/my-package可确认当前安装源——输出含path字样即命中本地，含packagist.org则走了远程
为什么加了 path 仓库，composer update 还是去 Packagist 拉包？
根本原因不是优先级失效，而是版本约束不满足或包名未注册。Composer 查找流程是：解析 require → 匹配所有已知仓库 → 找到第一个能提供该版本的仓库 → 停止搜索。如果本地 path 仓库里的包没有声明匹配的 version，或 name 字段与 require 的不一致，就会跳过它。
典型陷阱：
-
name字段大小写不一致（如本地写"MyVendor/my-package"，require 写"myvendor/my-package"）→ 不匹配 - 本地包
composer.json缺version字段，只靠分支名推断（如dev-main），但 require 写的是"^2.0"→ 无交集 - 用了
"type": "path"但没设"options": {"symlink": true}，导致后续composer update时因权限或缓存误判路径不可用 - 运行了
composer update --with-dependencies，但依赖链上游某个包在 Packagist 有更高版本，触发了跨仓库回退
如何强制让某个包始终走 path，绕过 Packagist？
不能“强制屏蔽 Packagist”，但可以切断它对特定包的响应能力——通过在 repositories 中将 Packagist 声明为 packagist 类型并设 "packagist.org": false，再单独加 path 仓库。这是最干净的隔离方式。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
示例 composer.json 片段：
{
"repositories": [
{
"packagist.org": false
},
{
"type": "path",
"url": "../my-internal-package"
}
],
"require": {
"my-internal/package": "dev-main"
}
}
注意点：
- 一旦禁用
packagist.org，所有其他包（如monolog/monolog）也必须显式提供来源（比如加另一个path或私有仓库），否则composer install直接失败 - 更务实的做法是保留 Packagist，仅对目标包用
path，靠精准版本约束（如"dev-main as 1.0.0"）锁定解析路径 - CI 环境中要确保
../my-internal-package路径真实存在且有读取权限，否则composer install报Could not find a matching version
path 仓库在生产环境部署时要注意什么？
path 仓库本质是开发期便利机制，**默认不适用于生产部署**。Docker 构建、CI 流水线或线上服务器通常没有对应路径，composer install 会直接失败。
关键判断点：
- 是否把本地路径当成了“私有包托管方案”？——这不是它的设计用途。应改用私有 Packagist（如 Satis、Private Packagist）或 Git 仓库（
"type": "vcs"） - 若真需上线，必须确保构建上下文包含该路径（如 Dockerfile 中
COPY ../my-internal-package /app/packages/my-internal-package），且composer.json中url改为容器内路径 -
composer install --no-dev不影响path仓库行为，但它会影响require-dev中是否包含该包——别把本该在require的内部 SDK 错放到require-dev，否则生产环境直接缺失 - 路径仓库不参与
composer.lock的哈希计算（不像 Git 仓库有 commit hash），换机器后若内容变更，lock 文件无法感知，容易引发不一致
最容易被忽略的是：path 仓库的稳定性完全依赖开发者手动维护路径和版本字段，没有服务端校验。一个拼写错误、一次忘记更新 version、或 CI 节点路径映射偏差，都会导致依赖解析静默失败或错装版本。
