大中型团队不建议用 Satis 做主力私有 Packagist，因其本质是静态快照工具，不支持实时发布、权限分级、审计日志和 Web UI 管理；生产级替代方案应选 GitHub Packages、GitLab Package Registry 或 Nexus/Artifactory。
直接说结论：大中型团队不建议用 Satis 做主力私有 Packagist，它本质是静态快照工具，无法支持实时包发布、权限分级、审计日志、Web UI 管理等刚需；真要私有化，优先选 GitHub Packages（带 Composer registry）、GitLab Package Registry，或自建 Artifactory/Nexus —— 它们才是生产级方案。
为什么 Satis 在大中型团队里容易崩
Satis 生成的是纯静态 packages.json 文件，每次 satis build 都得全量重扫所有仓库、重新解析所有分支/标签、重新生成整个 JSON。这意味着：
- 新增一个
v1.2.0tag，必须手动触发构建，其他开发者要等几分钟甚至十几分钟才能composer require到 - 无法按用户/组织控制谁能 push 包、谁只能 read —— 所有发布逻辑得靠 Git 权限兜底，和 Composer 生态脱节
- 没有 Web 界面查包、看依赖树、看下载统计，运维排查全靠翻日志和文件系统
- 当私有包超 50 个、版本数超 200 时，
packages.json体积轻松破 10MB，Composer 客户端拉取慢、内存爆、解析失败率上升
GitHub Packages + Composer 的真实配置要点
GitHub Packages 是目前对 PHP 团队最友好的开箱即用方案，但配置稍有不慎就会 Could not find package：
- 必须在项目根目录的
composer.json中显式声明仓库类型："type": "composer"，不能只写 URL - URL 必须以
/结尾，例如："https://maven.pkg.github.com/your-org/*/"（注意末尾斜杠） - 认证必须走
auth.json，且 token 需有read:packages和delete:packages（如需 publish）权限 - 包名必须严格匹配 GitHub repo 名：如果 repo 是
your-org/private-utils，则composer.json里"name"字段就得是your-org/private-utils - 发布命令不是
git tag就完事，得配合 GitHub Action 或本地composer publish（需配置github-oauth）
Docker Compose 部署 Nexus Repository 3 的关键避坑点
Nexus 是少数能同时托管 Composer、Maven、Docker 的通用制品库，适合混合技术栈团队，但默认配置不兼容 Composer：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须启用
npm (proxy)和npm (hosted)两种仓库类型 —— Composer 实际走的是 npm 协议兼容层，不是独立的 “composer” 类型 - 在
Repository → Create repository → composer (proxy)里，Remote storage要填https://packagist.org/，但Content type必须选npm - 私有包发布时，
composer.json的repositories指向 Nexus 的 hosted 仓库地址，例如："https://nexus.example.com/repository/composer-private/"（同样要结尾斜杠） - 首次启动后，必须进 Nexus UI 手动创建
composer-privatehosted 仓库，并开启Strict Content Type Validation = false，否则 Composer 上传会因 MIME 类型校验失败而被拒 - 挂载卷路径必须映射到
/nexus-data，否则重启后所有包元数据丢失
别忽略 auth.json 的作用域和生效时机
很多团队把 token 写进项目级 composer.json 的 config → github-oauth，结果发现 CI 流水线里根本读不到 —— 因为 Composer 只在当前项目目录下找 auth.json，而 CI 往往是 clean checkout 后运行，没这个文件。
正确做法是：
- 全局
auth.json放在$COMPOSER_HOME/auth.json（通常为~/.composer/auth.json），CI 脚本开头先mkdir -p $COMPOSER_HOME && echo '{...}' > $COMPOSER_HOME/auth.json - token 权限最小化：私有包只读场景，给
read:packages；需要自动发布，才加write:packages - 不要用个人 access token，应创建专用 machine user 并分配最小权限组 —— 这是审计合规的硬性要求
真正卡住大中型团队的，从来不是“怎么搭”，而是“谁有权发包、谁能看到包、出问题怎么追溯”。静态镜像解决不了权限流，也扛不住高频迭代节奏。选型前先问清楚：你们下一个季度要上线几个新服务？每个服务平均每周发几个包？有没有安全审计要求？答案出来，技术栈就清晰了。
