Composer在开发团队内部共享基础类库的实现方法（私有化部署）-composer-PHP中文网

不能直接 require sdk 文件，因会绕过 composer 自动加载机制，导致命名空间解析失败、依赖冲突、ide 跳转失效及无法 mock；必须用 path 仓库开发联调，上线前替换为 vcs 仓库，并通过 satis 统一管理私有包。

composer在开发团队内部共享基础类库的实现方法（私有化部署）

团队内部共享基础类库，必须用私有仓库，不能靠软链接或共享 vendor 目录——后者会在 5 分钟内触发 Class not found 或 autoload 错乱。

为什么不能把 SDK 目录直接 require 进主项目

直接 require '../acme-sdk/src/Helper.php' 看似简单，但会绕过 Composer 的自动加载机制，导致：命名空间无法解析、依赖未被安装、测试时无法 mock、IDE 跳转失效。更关键的是，一旦 SDK 自身 require 了 monolog/monolog，而主项目又用了不同版本，就会出现两套 Monolog 同时加载，Class 'Monolog\Logger' not found 只是时间问题。

本地开发阶段用 type: "path" 仓库实时联调

这是唯一能边改 SDK 边测应用的合法方式。操作要点：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

acme/sdk 目录下必须有合法 composer.json，name 字段为 "acme/sdk"，autoload 中 PSR-4 映射与实际目录结构严格一致
主项目 composer.json 的 repositories 段写成：
```
{
  "type": "path",
  "url": "../acme-sdk"
}
```
注意 url 是相对于当前项目根目录的路径，不能跨出项目树（如 ../../shared 会报 Invalid repository url）
Windows 下若符号链接失败，需加 "options": {"symlink": false}，否则改代码不生效且无提示

上线前必须替换成 Git VCS 仓库

type: "path" 是开发专用，生产环境必须删掉它，换成真实 Git 地址：

SDK 推送到内网 GitLab，确保打了语义化 tag（如 v2.1.0）
主项目 composer.json 改为：
```
{
  "type": "vcs",
  "url": "https://git.internal/acme/sdk"
}
```
注意 URL 不带 .git 后缀，且必须提前配置好凭据（PAT 或 git config --global credential.helper store）
运行 composer update acme/sdk，确认 composer.lock 中记录的是 commit hash 而非 dev-main

企业级统一管理用 Satis 搭建静态私有源

当团队有 5+ 个私有包时，手动维护每个项目的 repositories 不可持续。Satis 是最轻量可靠的方案：

用 composer create-project composer/satis 初始化
satis.json 中列出所有 VCS 仓库，"require-all": true 会自动抓取全部 tagged 版本

生成的 packages.json 部署到 Nginx，主项目只需配一条：

"repositories": [
  { "type": "composer", "url": "https://packages.internal" }
]

CI 流程中每次推送 SDK 新 tag，就跑一次 php bin/satis build satis.json web/

真正容易被忽略的是：Satis 生成的包信息不会自动感知分支变化，只认 tag；所以 SDK 的 CI 必须在打 tag 后才触发 Satis 构建，而不是 push 到 main 分支就跑。