Satis 搭建私有 Composer 仓库可行但仅生成静态文件，需正确配置 type: "composer"、确保 tag/分支存在、URL 指向 packages.json 根目录、验证 name 一致性、处理 Git 认证与证书，并接入 CI 自动构建。
直接用 Satis 搭建私有 Composer 仓库是可行的，但必须明确：它不提供实时服务，只生成静态文件；所有包必须已打 tag 或显式声明分支，否则 composer require 会 fallback 到 packagist.org。
为什么 composer config repositories.xxx 总报 “Invalid repository type”
错误根源是把 Satis 当成 VCS 源来配。Satis 输出的是静态 packages.json，客户端必须用 type: "composer" 去读它，不是 vcs、package 或空类型。
-
composer config repositories.myrepo composer https://packages.internal/—— URL 必须指向packages.json所在根目录，末尾斜杠不能少 - 如果 Satis 的
output-dir是web/，那 URL 就得是https://packages.internal/web/，否则 404 - 检查
composer.json里是否真新增了"type": "composer"字段，不是靠猜测或复制粘贴
为什么 satis build 成功但私有包始终 require 不到
Satis 不扫描未发布的代码 —— 它只处理 Git 仓库中已存在的 tag 和分支，且默认只认 v1.2.0 这类带 v 前缀的 tag。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 确认私有包的
composer.json里name字段（如"company/sdk"）和你在项目中require的完全一致，大小写敏感 - 没打 tag？运行
git tag v1.0.0 && git push --tags，再重新php bin/satis build - 想支持
1.2.0（无v）？在satis.json加"version-regex": "[v]?[0-9]+(?:\.[0-9]+)*" - 要拉
dev-main？需同时设"minimum-stability": "dev"和"prefer-stable": false，且require-all不生效，得用"require": {"company/sdk": "dev-main"}
内网部署时 satis build 报 “Could not clone”
构建过程在服务器上执行，不是你本地终端。Git 认证凭据、网络通路、SSH key 权限都得单独配给 Satis 运行环境。
- HTTPS 私仓？确保
~/.composer/auth.json（或 Satis 进程用户家目录下的该文件）含对应 token：{"github.com": "xxx"}或自建 Git 地址的 token - SSH 私仓？Satis 进程用户（如
www-data）的~/.ssh/下要有可用的id_rsa，且ssh -T git@git.internal能通 - GitLab/Gitea 自签名证书？Nginx/Apache 需配置
ssl_verify=false或将 CA 加入系统信任链，否则 PHP 的 cURL 会拒绝连接
真正容易被忽略的是：satis build 不会自动刷新
所有新 tag 都需重新运行 build 命令——你得把它接入 CI，在 push tag 后触发构建，否则下游永远看不到新版。另外，Web 服务器必须显式支持 application/json MIME 类型，否则即使 packages.json 存在，Composer 也会因响应头错误而静默跳过。
