ThinkPHP版本与Docker容器化部署_不同版本环境一致性方案-ThinkPHP-PHP中文网

thinkphp 5.1 与 6.x 的 composer 创建命令、php 版本要求、docker 构建策略、.env 安全挂载及队列进程部署存在显著差异：tp5.1 用 topthink/think=5.1.*，tp6.x 必须用 topthink/think 并指定版本如 6.3.*；tp6 要求 php ≥7.2，推荐显式声明 platform 版本；docker 应分阶段构建，生产镜像禁用 dev 依赖；.env 需只读挂载或通过环境变量注入；队列应独立 cli 容器运行，避免与 fpm 混用；opcache.revalidate_freq 需设为 0 以支持注解路由热更新。

thinkphp版本与docker容器化部署_不同版本环境一致性方案

ThinkPHP 5.1 和 6.x 的 `composer create-project` 命令差异

TP5.1 默认基于 PHP 7.1+，用 composer create-project topthink/think=5.1.* 可直接拉取稳定分支；而 TP6.x 强制要求 PHP >= 7.2，且必须指定 thinkphp/framework 作为根包，命令得写成 composer create-project "topthink/think" ./myapp "6.3.*"。漏掉版本约束或写错包名，composer 会默认装最新版（可能是 8.x alpha），导致容器启动时报 Class 'think\App' not found。

实操建议：

TP5.1 项目统一锁定 "topthink/think": "5.1.41"（最后一个安全维护版），避免自动升级到非 LTS 分支
TP6.x 项目在 composer.json 中显式声明 "platform": {"php": "8.0.28"}，和 Dockerfile 中的 PHP 版本对齐
不要依赖 latest 镜像标签——php:8.0-apache 和 php:8.0-cli 行为不一致，TP6 的 think 命令需 CLI 环境

Docker 构建时 `vendor` 目录该不该 COPY 进镜像？

直接 COPY . /var/www/html 会把本地 vendor 一起带进去，看似省事，但破坏了容器可复现性：你本地装了 xdebug 或 phpunit，这些开发依赖进了生产镜像，既增大体积又引入安全隐患。

正确做法是分阶段构建：

第一阶段用 php:8.0-cli 镜像，RUN composer install --no-dev --optimize-autoloader
第二阶段用轻量 php:8.0-apache，只 COPY --from=builder /app/vendor /var/www/html/vendor
务必加 --no-dev，否则 symfony/var-dumper 这类包会在生产环境激活，引发 headers already sent 错误

`.env` 文件在容器里怎么安全挂载？

TP 默认从 APP_PATH . '../.env' 加载配置，但把 .env 写进镜像等于硬编码敏感信息。Docker run 时用 -v /host/.env:/var/www/html/.env:ro 最直接，但要注意权限：Apache 用户（www-data）必须有读权限，否则 Dotenv\IOException 报错。

Docker Image Puller

使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。

下载

更稳妥的方式是用 Docker Compose 的 env_file + environment 覆盖：

在 docker-compose.yml 里写 env_file: .env.docker，把数据库密码等映射为环境变量
修改 TP 的 bootstrap/app.php，在 new App() 前加 putenv("DB_PASSWORD={$env['DB_PASSWORD'] ?? ''}");
TP6.3+ 支持 Env::get('DB_PASSWORD') 直接读取，不用再解析 .env 文件

为什么 `php-fpm` 容器里 `think queue:work` 总是退出？

很多人把队列进程塞进 FPM 容器，用 supervisord 拉起，结果发现 queue:work 启动后几秒就死——根本原因是 FPM 容器的主进程是 php-fpm，Docker 一旦检测到主进程退出就杀整个容器。而 queue:work 是长运行命令，不能当子进程活着。

解法只有两个：

单独起一个 php:8.0-cli 容器跑队列，通过 docker-compose.yml 的 depends_on 关联 DB 和 Redis
改用 queue:listen（TP5.1）或 queue:work --daemon（TP6.x），但后者已被官方标记为 deprecated，且内存泄漏风险高
TP6 推荐方案是用 crontab 每分钟拉一次 queue:work --once，配合 restart: on-failure 容器策略兜底