alpine容器配composer镜像源需三步：先装git、unzip及php-zip扩展，再以非root用户全局配置阿里云源，最后清缓存并确保多阶段构建中仅builder阶段配置、final阶段无残留；否则仍卡在解压或解析失败。
Alpine 容器里配 Composer 镜像源，不是加一行 config 就完事——不解决依赖缺失、权限冲突和缓存残留，composer install 会卡在“failed to extract”或“could not resolve packages”，镜像体积反而暴涨 30MB+。
为什么 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 不起作用
这条命令只改全局配置，但 Alpine 容器里常缺三样东西：git、unzip、php-zip 扩展。没 git，私有包拉不下来；没 unzip 或 ext-zip，包解压直接失败，镜像源再快也没用。
- 必须在
RUN阶段先装依赖：apk add --no-cache git unzip，再装 PHP 扩展：docker-php-ext-install zip（或apk add php83-zip，取决于 PHP 版本） - 全局配置命令得在非 root 用户下运行，否则
/root/.composer/config.json写入失败，后续所有composer命令都 fallback 到默认源 - 如果用多阶段构建，这行配置只该出现在 builder 阶段，final 阶段根本不该有
.composer目录
composer install 还是走默认源？检查这三处
即使你跑了 composer config -g，实际请求仍可能绕过镜像源，原因藏在缓存、锁文件和平台配置里。
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
-
composer.lock里记录的是包的原始 dist URL（含 packagist.org），install时不会自动替换——它只影响update时解析新版本 -
/root/.composer/cache/或/home/app/.composer/cache/里可能存着旧的元数据，强制走原站查 hash；清掉：rm -rf /root/.composer/cache - 项目
composer.json若显式写了"repositories": [{"type": "composer", "url": "https://packagist.org"}]，会覆盖全局配置；删掉或改成阿里云地址
多阶段构建中镜像源配置必须分阶段写死
builder 阶段要配源，final 阶段不能留任何配置痕迹——否则别人拿你镜像跑 composer update，会意外触发网络请求甚至覆盖已优化的 autoloader。
- builder 阶段 RUN 命令示例：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ && composer install --no-dev --optimize-autoloader --classmap-authoritative - final 阶段绝对不要 COPY
composer.json或composer.lock，它们对运行零价值，还可能被误读 - final 阶段若需验证源是否生效，进容器后运行：
composer config --global repo.packagist，输出应为空（因为没全局配置）或报错 “No configuration file found”，这才是干净状态
最易被忽略的一点：DNS。Alpine 的 BusyBox nslookup 有时解析 mirrors.aliyun.com 失败，但 ping 得通。真遇到请求超时，别急着换源，先在 Dockerfile 里加 RUN echo "nameserver 223.5.5.5" > /etc/resolv.conf 换 DNS。
