alpine 3.16+中无法通过apk安装composer，因其已被官方移除；必须用curl安装并确保git、unzip、curl存在，且需换源、多阶段构建、严格清理缓存与冗余文件。
Alpine里装Composer为什么必然失败
直接RUN apk add composer在Alpine 3.16+上会报ERROR: unable to select packages，这不是网络或权限问题，是官方主动移除了composer包。维护者认为Composer属于PHP应用层工具，不该由系统包管理器分发——它对git、unzip的版本要求和Alpine的musl生态不兼容。
必须改用官方安装方式：curl -sS https://getcomposer.org/installer | php，但这个命令硬性依赖git、unzip、curl三个工具。缺任何一个，就会卡在failed to extract或Cloning into...。
- 所有
apk add命令必须带--no-cache，例如：apk add --no-cache git unzip curl - 装完立刻删掉：加
apk del --purge git unzip curl，否则这些工具连带musl libc、BusyBox二进制全打进镜像 - 别用
php composer.phar install替代全局composer命令——Docker构建中路径易错，且shell找不到composer时不会自动fallback
多阶段构建中怎么安全跑composer install
关键不是“能不能装”，而是“装在哪、装完留不留”。Builder阶段要完整，Runtime阶段要干净，中间不能混用用户、路径或缓存。
- Builder阶段用
php:8.3-cli-alpine（含docker-php-ext-install和apk），不用alpine:latest自建PHP环境 - 执行
composer install --no-dev --optimize-autoloader --no-interaction：不加--no-interaction遇到私有包或prompt会挂起；不加--no-dev会让vendor/体积翻倍 - Builder末尾必须清理：
rm -rf /root/.composer /tmp/* /var/cache/apk/*，前提是前面apk add已带--no-cache - Runtime阶段只
COPY --from=builder /app/vendor ./vendor，不复制composer.json、composer.lock，也不运行任何composer命令
换源不是可选项，是刚性前提
直连packagist.org在国内多数场景下等同于无限等待。不换源，90%的卡顿根本没法靠缓存或并行解决。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
全局配置必须在builder阶段内执行：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意末尾必须有/）
验证是否生效：composer config -g repo.packagist输出应为完整JSON：{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}
- 别写成
repos.packagist（少个s）或漏掉composer协议前缀，会导致配置静默失效 - 如果用了BuildKit，可加
RUN --mount=type=cache,id=composer-cache,dest=/root/.composer/cache复用缓存，但普通场景--no-cache更稳 -
COMPOSER_CACHE_DIR=/tmp/cache设临时目录比默认/root/.composer/cache更利于层清理
最终镜像里藏着Composer就是失败
检查最终容器是否含以下任意一项，说明瘦身没到位：
-
/usr/local/bin/composer或/usr/bin/composer -
/root/.composer目录 -
vendor/bin/下除phpunit外的其他可执行文件（如doctrine、phpcs） -
vendor/*/tests/、vendor/*/docs/、vendor/*/CHANGELOG.md
真正干净的生产镜像，只该有vendor/autoload.php、vendor/composer/(含autoload_*.php)和实际用到的扩展类文件——其余全是干扰项。APK缓存没清干净、composer.json被误复制、或者runtime阶段用了和builder不同minor版本的PHP，都可能让redis.so加载失败或vendor/里悄悄混进几百MB垃圾。
