satis不是实时缓存服务器，而是需web托管的静态快照分发工具；它不代理请求、不自动同步，仅支持手动构建与离线分发，本质是“快照分发”而非“动态缓存”。
本地搭建 Composer 镜像 ≠ 用 repositories + path 类型
很多人一看到“本地镜像”，立刻在 composer.json 里加一段：
"repositories": [
{ "type": "path", "url": "./packages/*" }
]
这根本不是镜像，只是让 Composer 从本地目录加载**单个正在开发的包**。它不生成 packages.json，不支持语义化版本（如 ^3.2），不提供 HTTP 接口，也不能被 CI 或其他机器访问。删掉那个目录，整个依赖就断了。
真正自建镜像，必须能：
- 同步 packagist.org 元数据（含所有包、所有版本、依赖关系）
- 提供标准 Composer Repository 协议接口（
/packages.json、/p/xxx/$version.json等） - 支持 HTTPS、缓存、增量更新
- 允许其他机器通过 URL 访问（比如
https://my-mirror.local）
真要搭，得用 Packagist 的官方镜像工具或兼容服务
Packagist 官方不开源其后端，但社区有成熟替代方案。截至 2026 年 7 月，稳定可用的只有两类：
- Private Packagist（商业）：功能最全，支持权限控制、私有包托管、Web UI、自动同步，适合中大型团队；免费版限 5 个私有包
-
Satis（开源，PHP CLI 工具）：轻量，适合只读镜像；它不实时同步，而是按需生成静态 JSON 文件；需定时
php bin/satis build触发抓取
别再试 toran-proxy（已停止维护）、packagist-web（协议不完整）、或自己手写 packages.json —— 这些要么失效，要么无法处理嵌套依赖解析。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
satis 搭建最小可行本地镜像的关键步骤
假设你只要一个可内网访问、只同步 Laravel 生态常用包的轻量镜像，satis 是目前最可控的选择：
- 先装
satis：composer global require composer/satis - 写配置文件
satis.json，重点字段必须包含："name"（任意）、"homepage"（你的镜像地址，如https://mirror.internal）、"repositories"（指定要同步哪些源，例如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}） - 运行构建：
php ~/.composer/vendor/bin/satis build satis.json web/，输出到web/目录 - 用 Nginx 或 PHP 内置服务器暴露该目录，确保能访问
https://mirror.internal/packages.json
注意：satis 不代理请求，它是一次性快照。若想接近实时，得加 cron 定时重建，且每次重建会重拉元数据 —— 所以别把它当“在线镜像”，而应视为“离线缓存快照”。
为什么绝大多数人不该自己搭本地镜像
阿里云、腾讯云、华为云镜像已全量同步、HTTPS 强制、延迟 ≤5 分钟，且免费、免运维。你自己搭，要解决的问题远不止“能不能用”：
- 磁盘空间：完整同步需 ≥120GB（含 ZIP 包缓存）
- 带宽与出口：首次同步可能持续数小时，占满内网带宽
- 证书与 HTTPS：没正确配置 TLS，Composer 2.5+ 会直接拒绝连接
- 权限与安全：暴露
packages.json没问题，但若误配导致私有包路径泄露，风险极高
真正需要本地镜像的场景极少：比如完全断网的生产环境、强审计要求禁止外连、或定制化元数据过滤。其余情况，老老实实用 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就够了——它快、稳、不用管。
