私有Composer镜像库必须区分公开包加速与内部代码托管：Satis需正确配置type为composer、URL以/结尾、Web服务器设application/json MIME类型、auth.json放对路径且权限600，禁用require-all，否则会导致包找不到、认证失败或静默丢包。
私有 Composer 镜像库不是“配个 URL 就能用”的功能，它必须明确区分两种用途：一种是加速公开包下载（如镜像 packagist.org），另一种是托管内部代码（如 acme/auth-sdk）。二者技术路径、配置方式和运维重点完全不同，混用会导致 Could not find package、Authentication required 或构建静默丢包。
为什么 satis build 后 composer install 还是找不到包
根本原因在于 Composer 客户端压根没连上你生成的静态仓库——不是包没发布，而是路径、类型或认证断在了第一步。
-
url必须以/结尾，否则 Composer 会拼出https://pkgs.example.com/packages.json（404），实际需要的是https://pkgs.example.com//packages.json -
repositories类型必须是"type": "composer"，不是vcs或package；Satis 生成的是标准 Composer 元数据服务，不是 Git 仓库直连 - Web 服务器（Nginx/Apache）必须正确设置
packages.json的 MIME 类型为application/json，否则返回 200 但内容被当文本解析，Composer 报Unable to load package list - 检查
web/packages.json文件是否真实存在且非空——satis build静默跳过 clone 失败的仓库，不会报错，只会漏包
auth.json 放错位置导致反复提示 Authentication required
Composer 只从三个固定路径读取凭据，且顺序严格：当前目录 auth.json → $COMPOSER_HOME/auth.json → $HOME/.composer/auth.json（旧版）。放错就等于没配。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- CI 环境中禁用
composer config --global写凭据，不同项目可能需不同 token，应挂载文件或注入环境变量 -
auth.json文件权限必须是600（Linux/macOS），否则 Composer 直接忽略并报错 - HTTP Basic 认证填在
"http-basic": { "pkgs.example.com": { "username": "...", "password": "..." } }；GitHub/GitLab OAuth 填在"github-oauth"或"gitlab-token"下，不能混 - SSH 方式（
git@gitlab.internal:...）不走auth.json，依赖系统ssh-agent和密钥，CI 中需提前ssh-add
satis.json 中 require-all 是最大隐患
"require-all": true 表面省事，实则埋雷：它强制索引所有分支和 tag，导致 packages.json 文件爆炸（百包 × 数十版本 → 数十 MB），composer update 内存溢出或超时，且无法控制哪些包真正对外可见。
- 改用显式
require字段，例如："require": { "acme/logging-bundle": "^2.1", "acme/payment-client": "dev-main" } - 私有包名必须与 Git 仓库中
composer.json的"name"完全一致，大小写敏感，不能带通配符（"acme/*"不支持） - 需要 ZIP 包支持离线部署？必须加
archive配置块，并确保 Web 服务器可访问dist/目录下的 ZIP 文件 - Git 仓库 URL 若含用户名密码（如
https://user:pass@git.internal/repo），会被 Satis 记录进packages.json暴露，务必改用 SSH 或 HTTPS + token
别把 Satis 当 Packagist 替代品来用
Satis 是静态生成器，不是运行时服务。它不处理实时请求、不支持包上传、无权限粒度控制、无审计日志。高频迭代的私有开发流（比如 daily dev-tag 发布）会卡在手动 satis build 和 CI 同步延迟上。
- 真要支持团队协作+权限+审计，直接上 Private Packagist 私有部署版（On-Premise），它兼容 Composer 协议，提供 SSO、角色权限、下载统计、包扫描
- 若已有 GitLab，优先启用其
Package Registry（类型composer），无需额外服务，权限复用 GitLab Group，CI 中composer auth即可推送 - GitHub Packages 同理，但注意它对
composer.json的name字段要求更严：必须匹配owner/name格式，否则注册失败 - Artifactory/Nexus 是通用方案，适合已有多语言生态的企业，但配置复杂，PHP 包元数据支持不如专用工具稳定
最常被忽略的一点：Satis 构建后，Web 服务器必须禁止执行 PHP（尤其 web/ 目录下），否则攻击者可能上传恶意 PHP 文件绕过认证。这不是功能问题，是上线前必须卡死的安全红线。
