企业级composer镜像需满足私有包纳管、公共包加速、元数据可控三大硬需求；satis适用于静态私有仓库，composer-proxy才是替代toran proxy的生产级方案。
企业级 Composer 镜像不是“换一个源”就能搞定的事，它必须解决三个硬需求：私有包纳管、公共包加速、元数据可控。Satis 适合静态私有仓库，composer-proxy 才是替代 Toran Proxy 的真实生产级选择。
为什么 satis build 出来的镜像在 composer install 时总 fallback 到 packagist.org
根本原因不是配置漏了 repositories，而是 Composer v2 协议默认强制校验包名合法性——它会先向 https://packagist.org/p2/xxx.json 发请求，失败才考虑你的镜像，但这个 fallback 在 v2 中已大幅削弱。
- 必须显式禁用官方源：
composer config -g repo.packagist false（注意是repo.packagist，不是repos.packagist） - 如果只做项目级配置，
composer.json中的repositories必须包含"packagist": { "type": "composer", "url": "..." }这个 key，否则不生效 - Satis 生成的静态
packages.json若体积超 5MB（常见于 100+ 包 × 多版本），PHP 解析 JSON 会内存溢出或超时，导致整个仓库不可用
composer-proxy 启动后 composer install 报 404 或 “package not found”
这不是代理没跑起来，而是上游响应了 404，常见于缓存未命中且上游本身无该包——比如你配了 -upstream https://packagist.org，但请求的是私有包 acme/internal-utils，packagist.org 当然返回 404。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 正确做法是：用
composer-proxy做双 upstream 代理，例如上游配https://packagist.org+https://satis.internal.example.com（需自行改源码或用 Nginx 反向代理聚合） - 启动时务必加
-insecure参数，否则遇到 Packagist 的 HTTPS 重定向（如 providers-api 签名跳转）会失败 - 首次请求慢是正常的，因为要拉取并缓存
packages.json和 ZIP 包；但后续同包安装快于直连，因 ZIP 已落盘
satis.json 中 require 和 require-all 的实际影响差异
require-all: true 看似省事，实则埋雷：它会把每个 VCS 仓库的所有 tag、branch 全量抓取并写入 packages.json，极易撑爆文件体积和构建时间。
- 生产环境强烈推荐用
require显式声明："acme/utils": "^2.1"，避免拉取 dev 分支或废弃 tag - archive 配置必须显式开启，否则
composer install --prefer-dist会退回到--prefer-source，直接 clone Git 仓库，丧失离线部署能力 - 私有 Git 仓库若用 SSH，satis 构建时依赖系统级 SSH key；若用 HTTPS，URL 中必须带 token（如
https://token:x-oauth-basic@gitlab.internal/acme/utils.git），否则静默跳过
真正卡住企业的从来不是“怎么搭”，而是“怎么稳住”：Satis 的静态特性决定它无法实时同步新包，而 composer-proxy 的代理逻辑又要求你对上游行为有足够掌控——比如是否允许重定向、如何处理签名、缓存失效策略。这些细节不提前对齐，上线后就是半夜告警。
