答案是：第一阶段用php:8.2-cli执行composer install --no-dev --optimize-autoloader，第二阶段用php:8.2-cli-alpine仅COPY /app/vendor，确保composer.lock已提交、不挂载宿主机vendor、并验证镜像中无composer/git/dev扩展。

多阶段构建中如何只保留运行时依赖

生产镜像里塞进 composer 二进制、git、unzip 和全部 dev 包，是常见但危险的做法。它增大攻击面、拖慢拉取速度、还可能因权限或环境差异引发运行时异常。

• 第一阶段用完整构建镜像（如 php:8.2-cli）执行 composer install --no-dev --no-scripts --no-progress --optimize-autoloader
• 第二阶段切换为最小化运行镜像（如 php:8.2-cli-alpine），只 COPY --from=builder /app/vendor /app/vendor
• 确保 composer.lock 已提交到 Git，否则第二阶段无法复现依赖树
• 不要在第二阶段再运行 composer install —— 它会失败，因为没装 Composer，也不该有

--no-dev 和 --optimize-autoloader 的实际影响

这两个参数不是“可选优化”，而是生产部署的硬性要求。漏掉任一个，都可能让镜像变臃肿或运行变慢。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• --no-dev：跳过 require-dev 下的所有包（如 phpunit、phpstan），这些在容器运行时完全不需要
• --optimize-autoloader：生成扁平化的 vendor/autoload_classmap.php，避免运行时遍历目录查类，PHP 启动快 20%–40%
• 如果项目用了 PSR-4 自动加载，还要加 --classmap-authoritative，彻底禁用动态查找，进一步提速

为什么不能在运行镜像里挂载 vendor 或映射宿主机 vendor

本地开发时映射代码很自然，但把 vendor 也卷进去，等于把容器的依赖管理权交给了宿主机 —— 这直接破坏了镜像的可重现性。

• 宿主机 vendor 权限、UID/GID、符号链接结构和容器内不一致，常导致 include(): Failed opening required 错误
• 不同开发者本地 composer install 环境（PHP 版本、扩展、OS）不同，vendor 内容可能实际不兼容容器 PHP
• Docker 构建缓存失效频繁：只要宿主机 vendor 变了，哪怕只是时间戳，整个 layer 就重建
• 正确做法：构建时固化 vendor，运行时只挂载 ./src 或 ./config 等业务代码目录

如何验证最终镜像真的精简了

别只看 Dockerfile 写得漂亮，要进镜像里实测。最容易被忽略的是 Composer 自身残留和未清理的构建缓存。

• 运行 docker run --rm -it your-app-image sh -c "ls -la /usr/bin/composer || echo 'composer not found'"，确认命令不存在
• 检查 vendor/bin/ 是否为空或只剩必要二进制（如 phpunit 必须删掉）
• 执行 docker history your-app-image，观察各 layer 大小 —— 第二阶段基础镜像层应明显小于第一阶段
• 用 docker run --rm -it your-app-image php -m | grep -E 'xdebug|pcov|apcu'，确认没带入 dev-only 扩展

真正精简的镜像，不是靠删文件凑出来的，而是靠构建阶段就切断所有非运行必需路径。一旦在第二阶段还能找到 composer、git 或任何 dev 包，说明多阶段没切干净。