根本原因是PHP依赖未复用和vendor目录反复重建：Docker每次构建都从零下载解压安装依赖，且COPY顺序不当导致缓存失效；应采用多阶段构建、分层COPY、启用BuildKit缓存并挂载composer cache目录。
为什么 composer install 在 Docker 中又慢又胖？
根本原因就两个：PHP 依赖没复用、vendor 目录反复重建。Docker 每次构建都从零拉包，composer install 不仅要下载几十 MB 的 ZIP，还要解压、安装、生成 autoloader —— 这些操作在镜像层里全变成不可变的、无法共享的 blob。
更糟的是，很多人把 composer.json 和 composer.lock 放在 COPY . . 之后才执行安装，导致每次改一行代码，前面所有依赖层全失效。
- 别在
FROM php:8.2后直接RUN composer install—— 没 lock 文件或没 vendor 缓存时，它会重装全部包 - 别把
node_modules或vendor一起COPY进镜像 —— 它们不是源码，是构建产物，体积大且易冲突 - 本地
composer install --no-dev生成的vendor，不能直接 COPY 到容器里用 —— 扩展、PHP 版本、OPcache 配置不一致会导致运行时报错
多阶段构建 + 分层 COPY 是唯一靠谱路径
核心思路：把依赖安装和应用打包拆开，只把最终需要的 vendor 和代码 COPY 过去，跳过中间临时文件、缓存、dev 依赖。
第一阶段用带 composer 的基础镜像（比如 composer:2），第二阶段用精简 PHP 运行时（比如 php:8.2-cli-alpine）。关键点在于：先 COPY composer.json 和 composer.lock，再 RUN composer install --no-dev --no-scripts --optimize-autoloader，最后才 COPY 应用代码。
-
--no-dev：去掉phpunit、phpstan等开发依赖，体积直降 30%～60% -
--optimize-autoloader：生成扁平化 classmap，避免 runtime 的文件 stat 开销，对 APCu/OPcache 友好 -
--no-scripts：跳过post-install-cmd等钩子 —— 容器里不该跑前端构建、权限修复这类操作 - 确保
composer.lock提交进 Git —— 没它，多阶段构建的缓存几乎失效
Docker BuildKit 缓存让 composer install 快得像本地
默认的 Docker 构建缓存只认指令顺序和内容哈希，但 composer install 实际依赖的是 composer.lock 内容，而不是某条 RUN 命令本身。BuildKit 的 cache-from 和 cache-to 能真正按文件内容命中缓存。
启用方式很简单：加 # syntax=docker/dockerfile:1 开头，再用 --mount=type=cache,target=/root/.composer/cache 挂载 Composer 缓存目录。这样下次构建时，相同 composer.lock 对应的包不会重复下载。
- 必须显式挂载
/root/.composer/cache—— 否则每次都会重新 fetch ZIP 包，哪怕 lock 没变 - Alpine 镜像里
composer默认用 root 用户，所以 cache 路径是/root/.composer/cache，不是/home/www-data/.composer/cache - CI 环境中记得传
--cache-from type=registry,ref=your-registry/composer-cache，否则本地缓存带不进流水线
vendor 目录进 volume？别这么干
有人想把 vendor 挂成 volume 来“复用”，结果发现容器启动失败、类找不到、甚至 autoload.php 权限报错。因为 vendor 不是状态数据，它是构建确定性产物，和宿主机 PHP 版本、扩展、UID/GID 强耦合。
更隐蔽的问题是：Docker volume 是文件系统级挂载，而 Composer 生成的 autoloader 里写死了绝对路径（比如 /app/vendor/autoload.php），一旦挂载后实际路径变了，就会出 Class not found。
- 永远不要
VOLUME ["/app/vendor"]—— 这等于放弃镜像可移植性 - 开发时用
docker-compose.yml的bind mount挂载源码没问题，但vendor必须由容器内composer install生成 - 如果真要加速本地开发，用
composer install --ignore-platform-reqs+opcache.preload优化，而不是绕过 vendor 构建
最常被忽略的一点：不同 PHP 小版本之间，ext-opcache 的 preload 行为可能变化，所以即使你缓存了 vendor，也得确保构建和运行用的是完全一致的 PHP 镜像 tag（比如固定用 php:8.2.15-cli-alpine，而不是 php:8.2-cli-alpine）。
