Composer镜像同步不能只靠composer install，因其仅安装lock文件依赖而不更新元数据；需通过脚本拉取包列表、校验sha256与lastModified、处理重定向和分页、下载dist并校验shasum，确保packages.json与单包JSON时间戳和哈希严格一致。
Composer镜像源同步为什么不能只靠 composer install
因为 composer install 只读取本地 composer.lock 安装依赖，不触发元数据更新；镜像源（如 packagist.org 的镜像）需要定期拉取远程包列表、版本信息、dist/source 下载链接等元数据，这些由 Composer 自身的 composer self-update 或镜像服务端（如 packagist-mirror）维护，Python 脚本只能辅助完成其中可脚本化的环节：下载索引、校验哈希、增量同步、触发 Webhook 通知等。
用 requests 抓取 Packagist 元数据时要注意重定向和分页
Packagist 官方 API（https://packagist.org/packages/list.json）返回所有包名列表，但实际镜像需获取每个包的完整 JSON（https://packagist.org/p/{vendor}/{package}.json），而这类 URL 会 302 重定向到 S3 或 CDN 地址。直接用 requests.get() 不带 allow_redirects=False 会丢失原始 Location 头，导致无法提取真实资源路径。
- 必须设置
allow_redirects=False，再手动读取response.headers.get("Location") - 包列表接口支持
page参数，但无总页数字段，需循环请求直到返回空数组 - 高频请求会被限流（429），建议加
time.sleep(0.1)，并用session.headers.update({"User-Agent": "mirror-sync-bot/1.0"}) - 不要硬编码
https://packagist.org，应从配置文件读取源地址，便于切换为腾讯云、阿里云等国内镜像源做反向同步
同步前必须校验 packages.json 的 sha256 和 lastModified
镜像一致性依赖两个关键字段：根索引文件 packages.json 中每个包条目的 sha256 值（用于验证包元数据完整性），以及 lastModified 时间戳（避免全量拉取）。Python 脚本不应每次覆盖整个目录，而应：
- 先 GET
https://mirrors.example.com/packages.json，解析出已同步的包名 + 对应sha256 - 对每个待同步包，GET 官方
/p/{vendor}/{package}.json，计算响应体的hashlib.sha256().hexdigest() - 仅当
sha256不一致或本地缺失时，才下载并写入新文件 - 写入前确保目标路径存在：
os.makedirs(os.path.dirname(filepath), exist_ok=True)
用 subprocess.run() 调用 composer archive 生成 dist 包容易失败
很多镜像方案要求提供 zip/tar.gz 格式的 dist 包（即 "dist": {"type":"zip","url":"..."}），但 Composer 官方不提供现成打包服务。有人尝试用 Python 调 composer archive，结果常因工作目录、composer.json 缺失或 PHP 扩展限制失败。
立即学习“Python免费学习笔记（深入）”；
- 更可靠的做法是：跳过本地打包，直接从官方 dist URL 下载（
dist.url字段值），然后用requests.get(..., stream=True)流式保存 - 注意检查
dist.url是否含占位符（如{version}），需先用包版本号格式化 - 下载后必须校验
dist.shasum字段（不是文件名里的 hash），否则镜像可能被篡改而不自知 - 别用
shutil.copy复制本地 vendor 目录——那只是开发快照，不含 license、autoload 信息，也不符合 Packagist 元数据结构
真正难的不是下载，而是保证 packages.json 的 providers、provider-includes 和单包 JSON 三者时间戳与哈希完全对齐；稍有错位，composer update 就会报 Invalid package information。
