怎么把外部依赖包缓存到Composer私有源-composer-PHP中文网

satis是composer官方推荐的静态私有仓库工具，通过satis.json配置repositories、require及archive等字段，运行build命令递归抓取包及其全部依赖并生成静态packages.json和dist文件；必须显式声明私有源、禁用packagist.org且url以/结尾才能生效。

怎么把外部依赖包缓存到composer私有源

用 Satis 抓取并缓存外部包到私有源

Satis 是唯一被 Composer 官方推荐、能批量抓取 packagist.org 上任意包及其全部依赖（包括 transitive dependencies）并生成静态文件的工具。它不代理请求，而是“一次性下载+静态托管”，适合离线或强管控内网环境。

关键点在于：satis.json 中的 "repositories" 指向公共源（如阿里云镜像），"require" 明确声明你要缓存的包名和版本约束；运行 bin/satis build 后，Satis 会递归解析依赖树，把每个包的 dist 文件（zip/tar）下载下来，并生成统一的 packages.json。

必须用 "require-dependencies": true，否则只缓存顶层包，下游依赖仍会尝试外连
"archive": {"format": "zip"} 比 tar 更通用，Windows 和 CI 环境兼容性更好
避免写 "*"，比如 "monolog/monolog": "*" 会拉取所有历史版本，极大拖慢构建且浪费磁盘——应限定为 "^2.0" 或具体版本号
若需缓存 dev 分支（如 dev-main），需显式开启 "skip-dev": false，否则默认跳过

为什么不能直接用 Nexus/Artifactory 代替 Satis 做“缓存”

Nexus 或 Artifactory 的 Composer 仓库类型是代理型（proxy repository），它只缓存你实际访问过的包，首次请求仍需联网回源。这意味着：新项目执行 composer install 时，如果某个依赖从未被任何人在该 Nexus 上触发过下载，它就会去 packagist.org 拉取——这在完全断网的离线环境里直接失败。

Satis 则完全不同：它不依赖“有人先访问过”，而是通过配置主动抓全。你控制什么进、什么不进，输出目录就是最终可用的静态资源集合，可直接扔进 Nginx/Apache，甚至用 python3 -m http.server 起个临时服务供内网机器访问。

代理仓库适合“有网但想加速+审计”的场景；Satis 适合“零外网连接”的硬隔离环境
Nexus 的 Composer proxy 不支持 dist 文件重定向到本地路径，而 Satis 生成的 packages.json 中所有 dist.url 都指向你部署的私有域名，彻底切断对外依赖
如果你已在用 Nexus，可把它当 Satis 输出目录的 Web 托管层，但别指望它自动补全未访问过的包

部署后项目怎么正确引用这个私有源

项目中的 composer.json 必须显式声明该私有源，并禁用 packagist.org 默认源，否则 Composer 仍会 fallback 到公网。

Discussion Composer

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

下载

正确写法：

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://your-intranet.example.com/satis/"
    }
  ],
  "packagist.org": false,
  "require": {
    "guzzlehttp/guzzle": "^7.5"
  }
}

"packagist.org": false 是硬开关，缺了它，哪怕你写了私有源，Composer 在找不到包时仍会去 packagist.org 尝试——这是最常被忽略的一步
URL 必须以 / 结尾，否则 packages.json 请求路径会拼错（如变成 https://.../satispackages.json）
如果私有源启用了 HTTPS 自签名证书，需在项目中加 "secure-http": false，或在宿主机信任该证书，否则 composer install 会报 cURL error 60

缓存后的包还能更新吗？怎么维护增量

Satis 本身不提供“自动增量同步”。每次 bin/satis build 都是全量重建：它会重新解析所有 "require" 包的最新满足版本，并重新下载 dist 文件。所以“更新”靠的是重新运行 build 命令，而非后台守护进程。

实际运维中建议：

把 satis.json 和构建脚本纳入 Git 版本控制，每次变更（如新增包、升级版本）都走 PR 流程
在 CI 中定期触发 build（例如每周一次），但仅当 satis.json 有变更时才真正执行，避免无谓重复下载
不要手动删 dist/ 目录里的旧 zip——Satis 不会校验已存在文件，可能跳过重新下载，导致版本错乱；应清空整个 output/ 目录再 build
若要保留历史版本供回滚，得自己备份每次 build 输出的完整目录，Satis 不生成版本快照

真正的难点不在第一次搭建，而在于让团队理解：这个私有源不是“设置一次就永远有效”的黑盒，它的内容完全由 satis.json 定义，且每次 build 都是确定性覆盖。任何绕过配置直接改文件的行为，都会导致下一次 build 失效或冲突。