Composer本地镜像站需独立服务实现，直接改repositories仅能切换至阿里云等公开镜像源；全局替换命令为composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。
Composer 本地镜像站不是“配置一下就能用”的功能，它本质是代理或缓存服务，必须通过独立服务（如 packagist-mirror、satis 或 Private Packagist）实现；直接改 composer.json 的 repositories 只能指向已有镜像源（如阿里云、腾讯云），不能“搭建”镜像站。
如何快速切换到国内公开镜像源（最常用场景）
这是绝大多数人真正需要的操作：加速 composer install 和 composer update，无需自建服务。
git-log-tracker
下载
Git post-commit 钩子 + SQLite 提交索引工具。自动将每次提交的元数据（哈希值、作者、分支、仓库、主题）记录到本地 SQLite 数据库中，随后提供一个命令行接口（CLI），支持查询、列表展示、统计、删除和更新记录。 触发场景：管理 Git 钩子、跨仓库查询提交历史、定位某次提交所属的仓库、查看提交统计信息、将提交记录写入本地索引。 当用户提及“提交日志记录”、“提交索引”、“跨仓库查找提交”、“Git 钩子管理”，或希望以结构化方式查询其提交历史时（即使未明确指出该工具），请使
- 全局替换（推荐）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
- 项目级替换（仅当前目录生效）：
composer config repo.packagist composer https://mirrors.cloud.tencent.com/composer/
- 验证是否生效：运行
composer config repo.packagist，输出应为镜像 URL 而非https://packagist.org - 注意：阿里云镜像已支持 HTTPS + 全量同步，但不支持私有包上传；腾讯云镜像延迟略高，适合只读场景
为什么不能用 repositories + path 直接搭本地镜像
很多人尝试在 composer.json 中写：
"repositories": [
{
"type": "path",
"url": "./packages/*"
}
]这只能让 Composer 从本地目录加载开发中的包（比如你正在写的 my-utils），但它不会同步 packagist.org 的包，也不提供元数据索引、版本解析、依赖扁平化等核心能力。
-
path类型仓库只适用于单个包的本地开发联调 - 它不生成
packages.json，不支持require的语义化版本匹配（如^2.0） - 没有 HTTP 接口，无法被其他机器或 CI 使用
- 一旦删掉本地目录，整个依赖就断了——这不是镜像，只是软链接
真要自建私有 Packagist，该选哪个工具
取决于你的团队规模、是否需权限控制、是否要兼容 packagist.org 协议。
- 小团队 / 内部工具库为主 → 用
satis：
– 静态生成 JSON 索引，部署到 Nginx 即可
– 支持 Git 仓库白名单、自定义require过滤
– 缺点：无 Web UI，更新需手动触发php bin/satis build - 中大型团队 / 需权限、审计、Web 管理 → 用
Private Packagist（商业）或packagist-mirror（开源）：
–packagist-mirror基于 Laravel，支持实时同步 + webhook 回调 + 简易管理页
– 它监听 packagist.org 的update事件，只拉取被 require 的包，节省磁盘
– 注意：需 PostgreSQL + Redis，不支持 PHP 8.3+（截至 2024 年中） - 完全隔离环境（如金融内网）→ 自建
satis+ 定时脚本拉取指定 Git 仓库，彻底脱离 packagist.org
真正卡住人的从来不是命令怎么写，而是没分清“换源”和“建源”的区别：前者改一行配置，后者要部署服务、维护同步、处理元数据冲突。如果你的服务器连不上外网，又没人力运维镜像服务，老老实实用 satis 定期导出再离线导入，比硬上实时镜像更稳。
