最可靠方式是将私有仓库声明下沉至Composer全局配置（~/.composer/config.json），通过composer config -g命令添加，所有项目自动继承该元数据发现源；但require仍须在各项目composer.json中单独声明，且版本约束须用语义化版本（如"^2.1"），不可用"*"或"@dev"，否则vcs源将被跳过。
多个项目共用同一套私有仓库配置，别重复写 repositories
直接复用配置的最可靠方式，是把私有仓库声明下沉到 Composer 全局配置里，而不是每个 composer.json 都复制一遍。全局配置生效后，所有项目默认继承，无需额外声明——但要注意它只影响「元数据发现」，不自动注入 require。
- 运行
composer config -g repositories.private-packagist composer https://pkg.example.com，把私有源加进全局~/.composer/config.json - 如果同时要用 Packagist 官方源，必须显式补上：
composer config -g repos.packagist composer https://packagist.org（注意 key 是repos.packagist，不是repositories.packagist） - 全局配置里的
repositories会和项目级composer.json中的repositories合并，项目级优先级更高；想让私有源稳居第一，就在项目级配置中把它放在数组开头 - 验证是否生效：执行
composer config --list | grep repositories，能看到全局和项目级的完整合并结果
require 语句不能“跨项目复用”，必须每个项目单独写
require 是项目行为，不是配置行为。即使私有源已全局可用，每个项目仍需在自己的 composer.json 中明确写出 "your-vendor/private-package": "^2.1"，否则 Composer 根本不会尝试解析这个包名。
- 漏写
require→ 即使源存在，composer install也不会拉取该包 - 版本约束写成
"*"或"@dev"→ Composer 会跳过 path/vcs 源，直连 Packagist，导致静默失败 - 多个项目 require 同一私有包时，建议统一用语义化版本（如
"^2.1"），避免因分支名（"dev-main"）不一致引发环境差异
path 类型本地包无法全局复用，必须逐个项目配
type: "path" 的仓库本质是路径绑定，路径是相对或绝对文件系统地址，不可能被多个项目“共享”——除非它们目录结构完全一致，且都指向同一物理位置。强行复用会导致路径解析失败或符号链接错乱。
- Windows 下
"../my-pkg"在项目 A 能用，在项目 B 可能变成"../../my-pkg"，直接报错 - 不要把
repositories.type: "path"放进全局配置：Composer 会忽略它，因为全局上下文无意义的相对路径 - 开发阶段若真要多项目联调一个本地包，推荐改用
type: "vcs"+ 本地 Git 仓库（比如file:///path/to/my-pkg.git），再配合git commit触发更新，比 path 更可控
CI/CD 环境下，全局配置不可靠，必须项目级硬编码
CI 构建容器通常不带开发者本地的 ~/.composer/config.json，依赖全局配置会导致构建失败或行为不一致。生产部署必须把私有源显式写死在项目 composer.json 的 repositories 里。
- CI 脚本中应禁用全局配置干扰：
composer config --global --unset repositories（可选，防意外） - 项目级
composer.json中，私有源务必放repositories数组首位，并显式关闭 Packagist："packagist.org": false，防止漏配导致 fallback 到公网 - 若使用私有 Composer 镜像（如 Satis、Private Packagist），确保其
packages.json已预生成并包含所有需要的包元数据；否则即使源配置正确，也会因元数据缺失而查不到包
真正容易被忽略的是：**repositories 控制的是“在哪找包信息”，而 require 才决定“找哪个包”。两者缺一不可，且作用域完全不同——前者可下沉，后者必须上浮到每个项目。**
