Satis私有源配置失败主因是repos类型误设为vcs或未指定，正确应为composer类型且URL指向packages.json根目录；require失败多因tag未扫描、命名不匹配或未重建索引；更新需手动build并清缓存。
composer config 里添加 repos 失败，提示 “Invalid repository type”
这是因为 satis 本身不提供标准 Composer repo 接口，它生成的是静态 JSON 文件，必须用 composer config 手动加一个 packagist.org 类型之外的源——也就是 composer 类型（不是 vcs 或 package）。很多人误填成 vcs 或直接复制 Satis 的 HTTP 地址却不指定类型，结果报错。
- 正确写法：
composer config repositories.my-private-repo composer https://packages.example.com -
https://packages.example.com必须指向 Satis 构建后生成的packages.json所在根目录（比如 Nginx 静态服务根路径） - 如果 Satis 配置了
output-dir为web/，那 URL 就是https://packages.example.com/web/，末尾斜杠不能少，否则packages.json404 - 执行完后检查
composer.json里的repositories是否多出一项，且type是composer，不是artifact或空
require 私有包时始终 fallback 到 packagist.org
这说明 Composer 没真正“看到”你的私有包。Satis 不是实时代理，它只把 Git 仓库中已打 tag 的版本构建成静态索引。如果你 require 的版本号没被 Satis 扫描到（比如没打 tag、tag 格式不合法、Satis 配置里 require-dependencies 关闭导致依赖未展开），Composer 就会跳过该源，继续查官方源。
- Satis 默认只扫描
master和带v前缀的 tag（如v1.2.0），1.2.0这种不带v的需在satis.json中加"version-regex": "[v]?[0-9]+(?:\.[0-9]+)*" - 确保私有包
composer.json里name字段格式为vendor/name，且和你在require时写的完全一致（大小写敏感） - 运行
composer clear-cache后再composer update --verbose，看输出里是否出现Reading composer.json of vendor/name (v1.2.0)—— 如果没有，说明 Satis 根本没收录这个版本 - 别指望
dev-main这类开发分支能被直接 require，Satis 默认不发布dev-分支，除非显式配置"minimum-stability": "dev"并开启"prefer-stable": false
satis build 报错 “Could not clone … Repository not found”
Satis 构建时需要能直连私有 Git 仓库，但它运行在服务器上，不是你本地终端，所以 SSH key、HTTP token、网络策略都得单独配。最常见的是用 HTTPS 方式拉取时没带 token，或用 SSH 时没把 key 加进 ~/.ssh/authorized_keys 对应用户下。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 推荐统一用 HTTPS + Personal Access Token：在
satis.json的repositories里写完整 URL，例如https://token:x-oauth-basic@github.com/vendor/pkg.git - 如果 Git 服务器走公司内网，确认 Satis 服务器能
curl -I https://git.internal/repo.git通，防火墙和 DNS 往往比认证更早卡住 - GitLab 私有实例要注意 API 路径，Satis 依赖 GitLab API 获取 tag 列表，若启用了子组嵌套，
repositoryURL 必须和 API 返回的http_url_to_repo完全一致 - 构建前先手动在 Satis 服务器上
git clone一把目标仓库，排除权限和网络问题
私有包更新后，项目里 composer update 拉不到新版本
Satis 是静态快照，不是实时服务。你改了代码、打了新 tag，Satis 不会自动 rebuild，客户端也不会自动刷新缓存。所有“延迟”都来自这一环断开。
- 每次发版后必须手动跑
php bin/satis build satis.json web/（路径按实际调整），且确保输出里有Writing packages.json成功日志 - 检查生成的
web/packages.json文件里对应包的versions数组是否包含新 tag，文本搜索最直接 - 客户端执行
composer update vendor/name --with-dependencies时，加上--no-cache可绕过本地缓存，但别长期这么用；更稳妥的是composer clear-cache后再 update - 如果用了 CDN 或反向代理（比如 Nginx 缓存了
packages.json），要清掉那层缓存，HTTPCache-Control: public, max-age=3600是 Satis 默认设的，别忽略
最关键的复杂点在于：Satis 本身不解决权限分组、访问审计、Webhook 自动触发这些事。它只是个 JSON 生成器，后面还得靠运维补上 CI 触发、Nginx 权限控制、HTTPS 证书轮换这些环节。漏掉任意一环，私有源就变成“半可用”状态。
