必须显式声明私有源并禁用packagist.org：在composer.json顶层写"repositories":[{"type":"composer","url":"https://pkg.example.com/"}]且同级设"packagist.org":false，URL须以/结尾。
必须显式声明私有源并禁用 packagist.org，否则 Composer 仍会 fallback 到公网——哪怕 Satis 服务完全正常。
composer.json 里怎么写 repositories 才生效
客户端项目必须在 composer.json 中显式添加私有源，且 "type" 必须是 "composer"，不是 "package" 或 "vcs"：
-
"repositories"是顶层数组，不能嵌套在其他字段下 - URL 必须以
/结尾，例如"https://pkg.example.com/"；写成"https://pkg.example.com/packages.json"会导致 Composer 拼出错误路径 - 必须同时设置
"packagist.org": false，否则 Composer 在找不到包时仍会回退查询官方源 - 示例配置片段：
{ "repositories": [ { "type": "composer", "url": "https://pkg.example.com/" } ], "packagist.org": false }
satis.json 缺哪三项就构建失败
satis.json 不是“能跑就行”，缺以下任意一项都会导致生成的 packages.json 空或不被识别：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
"repositories"：必须是顶层数组，每个元素是完整对象，如{"type": "vcs", "url": "https://git.internal/lib"}；不能只写字符串 URL -
"require-all": true或"require": {"vendor/package": "*"}：二者不可共存，也不能省略 -
"output-dir"：推荐绝对路径（如"/var/www/satis"），相对路径容易因执行目录不同而写错位置
Nginx 配置 packages.json 和 dist ZIP 的关键点
Satis 输出纯静态文件，但 Composer 对 HTTP 响应头和路径匹配很敏感：
-
location /必须含try_files $uri $uri/ =404;，否则访问/packages.json会 404（Nginx 默认不匹配无后缀路径） - 需显式声明 JSON MIME 类型：
types { application/json json; }，否则返回text/plain会被 Composer 拒绝 -
"archive": {"prefix-url": "https://pkg.example.com/dist"}中的 URL 必须与 Nginx 实际可访问的 ZIP 路径一致；若 Nginxroot指向/var/www/satis，则 ZIP 文件必须在/var/www/satis/dist/下，且可通过https://pkg.example.com/dist/vendor-package/1.2.3-hash.zip直接下载
satis 命令找不到？别重装，先查 PATH
全局安装 composer global require composer/satis 后，satis 命令未必可用：
- Linux/macOS：检查
~/.composer/vendor/bin是否在$PATH中，运行echo $PATH确认 - Windows：检查用户环境变量中是否包含该路径（通常为
%USERPROFILE%\AppData\Roaming\Composer\vendor\bin） - 验证方式：直接运行
satis --version；报command not found就说明 PATH 没配对，重装无效
最易被忽略的是 "packagist.org": false 这一行——它不报错，但会让整个私有源形同虚设；另外，output-dir 路径权限不对、Nginx 未启用 try_files、ZIP 的 prefix-url 与实际服务路径不一致，这三处问题占了线上故障的七成以上。
