适合用Docker部署Laravel的核心标准是存在环境不一致、协作成本高或交付流程不可控三类问题之一；满足任一即应容器化，否则单机无迭代小后台可免。
适合用 Docker 部署 Laravel 的项目，核心判断标准不是“要不要容器化”，而是「是否面临环境不一致、协作成本高、交付流程不可控」这三类问题。满足任一，就值得上 Docker。
团队协作频繁、新人接入慢的项目
当新同事 clone 代码后，花半天配 PHP 版本、扩展、MySQL、Redis、Nginx 转发规则，甚至被 mbstring 缺失或 pdo_mysql 没启用卡住——这类项目立刻适合 Docker。
- 本地
.env只需填DB_HOST=db，不用改127.0.0.1或猜端口 -
docker-compose up -d启动即用，MySQL/Redis/Nginx 全自动连通 - 避免“在我机器上能跑”这种低效沟通，环境差异从源头消失
需要多环境（开发/测试/预发/生产）隔离的项目
如果 APP_ENV=local 和 APP_ENV=production 共用同一套 Nginx 配置、PHP 扩展、OPcache 策略，迟早出问题。Docker 让环境差异显性化、可版本化。
- 开发环境可挂载源码热重载，生产镜像用多阶段构建，
composer install --no-dev --optimize-autoloader固化依赖 -
compose.yaml和compose.prod.yaml分开维护，PHP 内存限制、OPcache 启用、日志路径等配置不混在一起 - 测试环境可快速拉起带固定 seed 数据的 MySQL 容器，每次都是干净状态
有前端构建流程（Vue/React/Nuxt）且需与后端联调的项目
纯 API 项目用 php-fpm + nginx 就够了；但一旦涉及 Vite/HMR、SSR 渲染、静态资源打包，就必须处理跨域、构建产物同步、缓存失效等问题。
- 用
node容器跑vite build，输出到public/，再由 nginx 容器服务，避免本地 Node 版本污染 - 开发时
nginx.conf可 proxy_pass 到 vite dev server，上线时直接 serve 构建产物，配置切换无感 - 前后端容器通过自定义网络互通，
http://app:8000/api这种写法在 SSR 场景下天然支持
部署目标是云原生或 Kubernetes 的项目
如果最终要上 K8s，现在就该用 Docker。硬切会暴露大量隐藏问题：权限（www-data vs root）、健康检查路径、启动探针超时、日志输出格式（必须 stdout/stderr）、/tmp 挂载策略。
- Laravel 的
storage:link在容器里得用 volume 挂载，否则重启丢失 -
artisan schedule:run不能靠宿主机 crontab，得用 supervisor 或 sidecar 容器 - 镜像必须基于非 root 用户（如
USER www-data），否则 K8s PodSecurityPolicy 拒绝调度
真正不适合的，反而是那种单机部署、无协作、无迭代、PHP 版本锁死、连 Composer 都不用的遗留小后台——对它们，scp + systemctl restart php-fpm 更快。但只要项目开始长出队列、缓存、定时任务、前端工程，Docker 就不再是“可选”，而是防止技术债滚雪球的基础设施底线。
