必须在构建阶段执行composer install，否则ThinkPHP项目因PHP扩展缺失、版本错配或config.platform.php未锁定，将报Class not found、require()失败或静默跳过autoload生成。
不能在容器启动时执行 composer install，必须在构建阶段完成；否则 ThinkPHP 项目大概率报 Class not found、require(): failed to open stream 或静默跳过 autoload 生成——根本原因是运行时 PHP 环境缺失扩展、版本错配，或 config.platform.php 未锁定。
为什么 tp 项目在 Docker 里一跑就 Class not found
ThinkPHP 的类加载强依赖 vendor/autoload.php 的完整性，而这个文件的生成质量直接受构建环境影响：
- 官方 PHP 镜像（如
php:8.2-fpm）默认不带ext-zip、ext-xml、ext-mbstring，composer install会静默跳过部分包解压或 autoload 生成 - 宿主机用 PHP 8.3 生成的
composer.lock，在容器 PHP 8.2 下执行install，可能装入含readonly属性的包（PHP 8.2 不支持），运行时报ParseError - 没设
"config": {"platform": {"php": "8.2.15"}}，Composer 会按容器当前环境推测能力，结果装了只兼容 8.3 的symfony/console，tp 控制器一调用就崩 -
topthink/think-trace这类包若被误写进require-dev，但app/middleware/TraceMiddleware.php又无条件 new 它，--no-dev会删包但不删代码，上线必报错
Dockerfile 多阶段构建 tp 项目的正确顺序
顺序错了，缓存就废，镜像就不可复现。关键不是“有没有”，而是“先 COPY 什么、再 RUN 什么”：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 第一阶段用
php:8.2-cli（别用 Alpine，ext-zip编译太麻烦），COPY composer.json composer.lock ./必须放在RUN composer install之前 -
RUN apt-get update && apt-get install -y unzip && rm -rf /var/lib/apt/lists/*补系统工具，unzip是硬依赖 -
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer安装最新版，别用apt install composer（版本太老，不支持 lock v2） -
RUN composer install --no-dev --optimize-autoloader --classmap-authoritative：三个参数缺一不可，--no-dev防体积膨胀和 autoload 冲突，后两个提升 tp 自动加载性能 - 第二阶段用
php:8.2-fpm-alpine，COPY --from=builder /app/vendor /var/www/html/vendor，只复制 vendor，不复制composer.phar或源码
tp 项目挂载 vendor 到容器的权限陷阱
开发时图省事挂载整个 vendor/ 进容器？90% 的 Class not found 来自这里：
- macOS/Windows 宿主机 UID/GID 和 Linux 容器不一致，挂进去的文件属主变成
root或1001，PHP 进程（常以www-data身份运行）读不了 - opcache 会拒绝加载跨 UID 缓存，即使文件存在，
opcache_get_status()显示命中但实际不生效 - 解决办法只有两个：
docker run -u $(id -u):$(id -g)强制容器内用户 ID 对齐；或者干脆别挂vendor/，只挂./app和./config，让容器自己composer install（仅限开发） - 若必须挂（比如 CI 场景），进容器后手动跑一次
composer dump-autoload -o，刷新 autoload 映射，否则文件系统缓存可能让旧路径继续生效
tp 项目里 require-dev 包是不是真能“只开发用”
不能看字段名，得看调用链。一个包只要被 app/ 或 src/ 下任意 PHP 文件直接引用，它就是运行时依赖：
- 执行
grep -r "think-trace" app/ src/ --include="*.php"，结果非空，就得从require-dev挪到require -
topthink/think-swoole若线上也跑 Swoole 模式，就不能放require-dev；同理，topthink/think-queue若生产启用队列，就必须进require -
composer dump-autoload默认仍生成autoload-dev映射，哪怕包没装，自动加载器也会尝试找路径——加--no-dev参数才真正隔离 - 验证是否干净：
docker run --rm -v $(pwd):/app php:8.2-cli php -d extension=mbstring.so -d extension=zip.so -d extension=xml.so /app/vendor/autoload.php，能不报错加载，才算过关
最易被忽略的是 config.platform.php 锁定和 require-dev 的真实调用边界——它们不报错，但会让 tp 在某个深夜突然 500，且日志里只有一行 Class 'think\Debug' not found。
