1. 先说点实在的Java项目部署卡在哪了先问个问题你写好的Spring Boot项目是不是经常遇到这种场景本地跑得好好的一换机器就起不来测试环境说连不上数据库你反复确认配置没问题领导催着上线你手动在服务器上敲了十分钟命令最后发现少装了一个依赖。这些事干过Java的人多多少少都经历过。Docker解决的就是这一整类问题。它把Java应用连同运行环境一起打包让“能跑”变成一件确定的事情。这也是为什么现在聊Java面试题问完JVM、Spring、MySQL乐观锁基本都会顺带问一句容器化部署。你去看招聘JD中级以上的Java岗位十个里有八个写着“熟悉Docker优先”这不是门槛是默认要求。这篇东西适合什么人看三类人。一类是零基础刚接触部署、被各种环境问题折磨的新人能从第一行命令看懂全流程一类是会用java -jar跑项目、但没正经用过Docker的开发者这里面的坑和思路能帮你少走很多弯路还有一类是想把项目交付得干净利落的人比如做外包、做毕业设计、做开源项目学会用Docker交付对方拿过去一键跑起来体验完全不一样。我尽量按实际操练的顺序来讲从装环境、写Dockerfile到构建镜像、跑容器再到用Docker Compose把MySQL、Redis一起编排起来。每讲一步都会解释清楚为什么这么做而不是只给一串能跑的命令。文章最后会有问题排查实录那些都是我在真实环境里踩过的坑你大概率也会遇到。如果你抱着一次性想把Docker学到“能干活”的程度这篇值得静下心看完。2. 为什么Java项目需要Docker先解决“为什么”再解决“怎么做”2.1 环境不一致是Java部署的第一大痛点Java一直标榜“一次编写到处运行”但真正部署过的人都懂实际跑起来到处运行往往会变成到处踩坑。JDK版本不一样Linux和Windows的差异系统缺了某个底层库数据库连接串写死导致环境不同步……这些问题在开发机上一个样测试环境一个样生产环境又是另外一副面孔。Docker的思路刚好相反我不保证你的环境“兼容”我直接连环境一起打包。你把JDK 17 你的应用 配置文件全部打进一个镜像用户拉到这个镜像不管底层是Ubuntu、CentOS还是Alpine跑起来的结果都是一样的。相当于把“部署”这个动作从“搭建环境 装应用”两件事压缩成了“运行容器”一件事。这个思维转变很重要。很多人学Docker时总在记命令却忽略了它的核心价值是解决环境一致性。理解了这一点你就能明白为什么我们在Dockerfile里要写FROM openjdk:17而不是默认服务器上有Java环境。2.2 轻量化与隔离性一台机器跑多个Java应用不再互相干扰再说一个很现实的场景。一台服务器你需要跑三个Java服务分别是Spring Cloud里的不同模块。传统做法要么装三个JDK然后靠端口区分进程要么搞虚拟机隔离。装JDK的话依赖冲突、端口占用、一个服务挂了把系统资源吃满都是麻烦事。上虚拟机的话每个虚拟机都有一套操作系统启动慢、资源占用高光内存就够喝一壶。Docker容器是进程级隔离共享宿主机内核。每个容器有自己独立的文件系统、网络端口和进程空间但底层不重复装操作系统。启动一个Java容器通常就是秒级内存控制在几百MB级别多个服务可以在一台机器上和谐共存。你可以指定每个容器占用的CPU和内存上限避免一个应用把整台机器资源吃完这在实际运维中非常关键。说白了Docker是在“省事”和“隔离”之间找到了一个很实用的平衡点。这也是为什么即便在Kubernetes普及的今天Docker依然是Java应用部署的主流选择之一。部署Zabbix、GitLab这类基础设施时官方推荐的也是Docker方式因为它把一个复杂的安装过程封装成了几条命令。2.3 面试和日常开发都在用不学真的会吃亏有关注过Java面试题目的话你会发现容器化内容的出现频率越来越高。面试官不一定指望你精通K8s但Docker的基本原理和常用命令已经是默认“你应该掌握”的范畴。日常开发中很多开源项目比如各类脚手架、低代码平台、向量数据库提供的部署方式第一条就是docker run。不会Docker连本地跑别人的项目都能卡住。从学习的性价比来看Docker也是值得每个人投入时间的基础设施技能。它不难核心就是镜像、容器、仓库三个概念加上几个常用命令就能应付绝大多数场景。难的是后面的网络、存储和编排但那些可以等用到的时候再深入。3. 环境准备先把Docker跑起来3.1 Windows装Docker Desktop新手最容易卡住的一步如果在Windows上工作建议安装Docker Desktop。这个工具自带图形界面支持在Windows上直接管理容器、镜像和数据卷对新手友好很多。但安装过程有几步很关键漏了就容易出现网上被问爆的那个错Docker Desktop failed to start because a Virtualization support tool isnt installed or not enabled。具体操作步骤打开Windows功能设置勾选“Hyper-V”和“适用于Linux的Windows子系统”然后重启电脑。在BIOS里确认虚拟化技术处于开启状态。重启时进BIOS找Intel VT-x或AMD-V相关的选项设为Enabled。这一步做不到后面Docker Desktop基本必挂。安装WSL2。进入PowerShell以管理员身份运行wsl --install装完按提示重启。去Docker官网下载Docker Desktop for Windows安装包约500MB安装过程保持默认设置即可。启动Docker Desktop等右下角图标变成鲸鱼样子且不闪红就说明引擎已经启动了。特别注意Windows家庭版没有Hyper-V选项的话用WSL2就够用了。Docker Desktop现在默认后端就是WSL2不需要额外调整。安装完成后可以在命令行里输入docker version验证能看到Client和Server两段信息就是成功。3.2 Linux服务器装Docker Engine一条命令的事也有坑实际部署Java项目最终基本要落到Linux服务器上。这里以主流的Ubuntu和CentOS为例。Ubuntu 22.04/20.04sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release echo $VERSION_CODENAME) stable | \ sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.ioCentOS 7/8sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo sudo yum install -y docker-ce docker-ce-cli containerd.io装完之后记得启动服务并设置开机自启sudo systemctl enable docker sudo systemctl start docker这块有两个坑要提前说。第一CentOS 7的内核版本比较老如果docker run之后遇到一些奇奇怪怪的网络或者文件系统问题大概率是内核太旧建议换CentOS 8及以上或者直接用Ubuntu 22.04。第二很多云服务器默认的源里没有Docker使用官网源如果拉取超时可以把上面命令中的download.docker.com替换为国内可访问的Docker源地址不同云厂商都有自己的镜像源阿里云的镜像源是一个常见选择替换成对应内网地址即可。3.3 设置镜像加速这一步能救你的命这一步毫不夸张。Docker默认从Docker Hub拉镜像在国内直连经常几十KB每秒拉一个几百MB的JDK镜像等半小时都是常事。所以装完Docker之后的第一件事不是急着去拉镜像而是先把加速器配好。以阿里云为例登录阿里云容器镜像服务控制台会给你一个专属加速地址形如https://xxx.mirror.aliyuncs.com。然后执行sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [https://你的专属地址.mirror.aliyuncs.com] } EOF sudo systemctl daemon-reload sudo systemctl restart dockerWindows的Docker Desktop配置更简单在Settings - Docker Engine里把上述JSON内容填进去右下角会提示重启点一下就好。配置完之后再拉镜像速度就有质的提升。这个加速配置是你一切后续操作的基础别跳过。4. 用Dockerfile打包Java应用核心中的核心4.1 从基础镜像开始选合适的是门学问写Dockerfile的第一步是选基础镜像也就是FROM那一行。这里的水很深用错了不会报错但会让你的镜像又大又慢。很多初学者习惯直接写FROM openjdk:17这么写本身没错但要注意openjdk这个镜像基于Debian包含了大量Java编译调试工具实际跑jar包根本用不上镜像体积能到400MB以上。如果你只追求“能跑”那没问题如果考虑镜像体积、启动速度和攻击面选精瘦一点的镜像更合理。我常用的选择是Eclipse Temurin的JRE版本比如FROM eclipse-temurin:17-jre-alpine这个镜像基于Alpine Linux体积只有几十MB对JDK做了精简专门为了运行Java应用设计。Spring Boot项目直接用JRE就够不需要完整JDK因为你的代码已经编译成class了。如果你走的是Spring Boot 3.x JDK 17这条路eclipse-temurin:17-jre-alpine是很好的选择。JDK 21也已经很成熟选eclipse-temurin:21-jre-alpine也没问题。Java 8项目至今还有很多存量那就选eclipse-temurin:8-jre-alpine。总之根据自己项目的编译版本选而不是凭感觉选。4.2 一个可以直接拿来用的Dockerfile示例假设你有一个Spring Boot项目用Maven构建产物是一个demo-0.0.1-SNAPSHOT.jar。我的做法是# 第一段用Maven镜像做构建 FROM maven:3.9-eclipse-temurin-17 AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn clean package -DskipTests # 第二段运行阶段只取构建产物 FROM eclipse-temurin:17-jre-alpine WORKDIR /app COPY --frombuilder /app/target/*.jar app.jar EXPOSE 8080 ENV TZAsia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime echo $TZ /etc/timezone ENTRYPOINT [java, -jar, app.jar, --spring.profiles.active${SPRING_PROFILE}]这里用的多阶段构建编译和运行分开。好处很明显第一个阶段负责打包第二个阶段只保留运行所需的JRE和jar包最终的镜像不包含Maven、编译器、源码体积小好几个量级。几个细节说明一下RUN mvn dependency:go-offline -B先把依赖下载到镜像层里缓存起来后面每次改代码重新构建时只要pom.xml没变这层就用缓存构建速度会快很多。--spring.profiles.active${SPRING_PROFILE}这一行是运行时通过环境变量指定profile比在镜像里写死环境要灵活得多。启动容器时给-e SPRING_PROFILEprod就能切到生产配置。时区设置要放在Dockerfile里否则容器默认UTC时间日志时间会和本地差8个小时排查线上问题很痛苦。4.3 构建镜像的正确姿势和容易忽略的.dockerignore写好Dockerfile之后在项目根目录执行docker build -t demo:v1 .-t给镜像起名字demo是仓库名v1是标签。最后的.是构建上下文路径注意不是让你指定Dockerfile在哪而是把当前目录所有文件发送给Docker守护进程作为构建上下文。这一行有个大坑。如果你项目里有target目录、.git目录或者大文件它们会被完整打包发给Docker引擎。项目一大构建上下文动辄几百MB构建被拖得非常慢。解决办法是加一个.dockerignore文件作用和.gitignore类似target/ .git/ .idea/ *.iml *.log .dockerignore Dockerfile把这些排除掉构建上下文就干净了。很多人第一次用DockerJava部署镜像能构建出来但每次都慢得离谱八成就是没加这个文件。构建完成后用docker images看一下镜像列表注意看SIZE这一列。如果你的镜像有500MB说明基础镜像或者上下文有问题回去检查。4.4 镜像安全性和可维护性的个人建议镜像不是越大越好能跑也不是终点。基础镜像里的漏洞往往会被连带扫描出来生产环境的安全扫描工具会报警。我习惯定期更新基础镜像的版本比如从17-jre-alpine换到补丁更新的版本。还有一个容易被忽略的不要用latest标签。latest指向的镜像随时可能变同一份Dockerfile在不同时间构建出的镜像可能不一样这会让“可复现”变成一句空话。给每个构建打上明确的版本号比如demo:v1.0.0至少你的交付物是可追溯的。5. 运行容器docker run只是开始5.1 关键参数逐一拆解别只复制粘贴镜像构建好了接着就是启动容器。最朴素的命令是docker run -d --name demo-app -p 8080:8080 -e SPRING_PROFILEprod demo:v1.0.0乍一看就是一串参数但每个都直接影响你之后的运维体验我拆开讲。-d表示后台运行。不加这个容器会挂在前台一旦你关掉终端服务可能跟着停对于部署场景基本必加。--name demo-app给容器起名字。名字既是标识也是以后操作的关键比如docker logs demo-app、docker restart demo-app都比用一串随机ID方便。-p 8080:8080是端口映射。冒号左边是宿主机端口右边是容器内端口。你的Java服务在容器内部监听8080宿主机暴露8080外部通过服务器IP:8080访问。这里容易搞错的是映射方向我第一次用的时候写反了导致外面怎么都访问不到。-e SPRING_PROFILEprod是传入环境变量对应Dockerfile里的${SPRING_PROFILE}。这是配置外部化的标准手段数据库地址、密码之类的敏感信息不该写死在镜像里运行时通过环境变量注入才是正路。还有一个参数容易被忽略但实际生产环境非常关键--restartalways。加上它之后机器重启时容器会自动拉起。不加的话服务器一重启你的Java服务就悄悄下线了等用户反馈了才反应过来。对于“希望服务一直在线”的场景这行很重要docker run -d --name demo-app -p 8080:8080 --restartalways demo:v1.0.05.2 日志、进入容器、查看状态日常操作三板斧Java项目跑起来之后我们最常用的就是看日志。容器日志不是文件Docker把容器内程序的stdout/stderr都收集起来了# 查看容器日志 docker logs demo-app # 持续跟踪日志输出相当于tail -f docker logs -f demo-app # 只看最近100行 docker logs --tail 100 demo-appJava应用的日志如果用的是默认配置输出到控制台那么docker logs能看到如果你配了logback写文件到/app/logs下那docker logs是空的需要进容器看文件docker exec -it demo-app sh这里注意Alpine基础镜像的交互式shell是sh不是bash很多人习惯性敲bash发现没有这个命令其实不是出问题了是镜像根本没装。查看容器的运行状态和资源占用用docker ps docker statsdocker ps能看到所有运行中的容器docker stats能看到每个容器的CPU、内存占用对于排查内存溢出一类的问题非常有用。5.3 数据放哪里Java日志和MySQL数据的持久化容器是免维护的宿主机重启后如果用了--rm容器直接没了容器内的文件跟着一起消失。如果你的Java应用把日志写在容器内、或者你在容器里放了上传的图片容器一删数据全没了。所以生产环境的部署一定要明确数据不能放容器内部。用数据卷volume解决docker run -d \ --name demo-app \ -p 8080:8080 \ -v /opt/demo/logs:/app/logs \ demo:v1.0.0-v /opt/demo/logs:/app/logs的意思是把宿主机的/opt/demo/logs目录挂载到容器内的/app/logs目录。应用写进/app/logs的文件实际落在宿主机上。容器删了重建“ /opt/demo/logs”里的日志还在不丢数据。这块务必要想清楚你的应用有哪类数据需要保留日志、上传文件、数据库文件。Java应用本身是无状态的但它的产物可能有状态。MySQL容器也一样官方镜像默认把数据写在/var/lib/mysql你不挂载数据卷容器一删整个库就没了——这是很多人第一次用Docker跑MySQL时踩过的最大的坑。6. 进阶Java项目配套MySQL、Redis用Docker Compose编排6.1 为什么单条docker run不够用真实项目里Java应用基本都要依赖MySQL、Redis、消息中间件这些基础设施。之前的做法是一个服务一个docker runMySQL一条命令、Redis一条命令、你的Java应用一条命令。但这几条命令之间有依赖关系Java应用启动时如果MySQL还没就绪应用会报错、无限重试。而且这些命令记在文档里换一台机器逐个执行顺序稍错就出问题。Docker Compose就是来解决这个问题的。它通过一个docker-compose.yml文件把一组服务定义在一起一条命令全部启动和停止服务间还能通过内部网络直接互相访问。根本上它是把“部署方案”文本化了好处是团队协作时不用口口相传命令拿到文件跑一下就完事。6.2 一份可直接修改的docker-compose.yml实例下面是我常用的一版Java MySQL 8 Redis你基本可以直接拿过去改改就用services: mysql: image: mysql:8.0 container_name: demo-mysql environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: demo_db TZ: Asia/Shanghai ports: - 3306:3306 volumes: - mysql-data:/var/lib/mysql restart: always redis: image: redis:7-alpine container_name: demo-redis command: redis-server --requirepass redis123 ports: - 6379:6379 volumes: - redis-data:/data restart: always app: build: . container_name: demo-app environment: SPRING_PROFILE: prod SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/demo_db?useSSLfalseserverTimezoneAsia/Shanghai SPRING_DATASOURCE_USERNAME: root SPRING_DATASOURCE_PASSWORD: root123 SPRING_DATA_REDIS_HOST: redis SPRING_DATA_REDIS_PASSWORD: redis123 ports: - 8080:8080 depends_on: - mysql - redis restart: always volumes: mysql-data: redis-data:启动命令很简单docker compose up -d想看日志docker compose logs -f app全部关停docker compose down注意down不会删除数据卷数据还在。如果连数据卷一起清理用docker compose down -v。6.3 容器间通信服务名就是IP地址这段对新手来说最容易迷茫。你的Java应用要连MySQL数据库地址填什么IP地址吗容器的IP是动态分配的重启一次就变了你总不能每次重启都改配置。Compose网络的答案很优雅在同一个Compose项目里服务名可以作为主机名互相访问。比如上面配置中Java应用里配置的MySQL地址是mysqlRedis地址是redis。这是Docker内置DNS把服务名解析成对应容器的IP你不必关心具体IP是多少。这句配置是很多人的顿悟点容器里不能用localhost连数据库因为每个容器有自己的网络栈localhost指向的是容器自己不是宿主机。要从容器访问宿主机上的服务得用host.docker.internalDocker Desktop支持或者配置网络为host模式。但从容器访问另一容器里的服务用服务名是最直接的方式。如果你不用Compose而用单独的docker run那么需要先建一个自定义网络再把容器都加入这个网络才能实现同样的效果。Compose自动帮你做了这件事这也是我推荐项目配套基础设施优先用Compose的原因。6.4 配置和密码不该写进yml的替代方案上面的例子为了演示直观把密码写进去了现实项目中不建议这样做。尤其当你把docker-compose.yml提交到Git仓库等于把数据库密码暴露给所有人。更好的做法是用环境变量文件env_fileCompose支持从某个文件读取环境变量该文件不入Git。mysql: image: mysql:8.0 env_file: - ./mysql.env此外还可以结合宿主机系统环境变量来赋值将敏感信息从版本库里剥离出来。这个习惯养成之后生产换密码时就不用改代码重新构建了改环境变量重启容器即可。7. 常见问题与踩坑实录新手到老手都躲不开的坎7.1 Docker Desktop启动失败虚拟化问题这是Windows用户提问最多的问题报错一句话概括就是Docker Desktop failed to start。原理是Docker Desktop需要依赖虚拟化技术系统没开或者没装对应组件就直接反馈启动失败。排查顺序我总结为四步打开任务管理器 - 性能 - CPU看右下角是否显示“虚拟化已启用”。如果是“已禁用”进BIOS开启Intel VT-x或AMD-V。在Windows功能里确认“适用于Linux的Windows子系统”已经勾选。在PowerShell里执行wsl --status确认WSL版本如果不是WSL2执行wsl --set-default-version 2。如果以上都正常卸载Docker Desktop重新安装Docker目录下有残留文件也可能导致启动失败。需要注意的是如果使用的是笔记本且BIOS里虚拟化被隐藏了可能需要关闭Hyper-V然后再开或者重置TPM相关选项各家主板不同但大方向一致。7.2 容器启动了但访问不到应用端口与网络排查容器日志看了没先执行docker logs demo-app看Java应用是不是真的起来了。如果日志显示Tomcat started on port 8080说明应用正常问题在网络层。排查顺序确认端口映射对不对。docker port demo-app会打印实际映射关系对比是否还是8080。在宿主机上执行curl http://localhost:8080如果用这个命令通了说明容器和映射没问题问题在外网防火墙或安全组。云服务器的安全组规则里必须放行8080端口这是新手最容易忽略的一步。如果用localhost都不通检查容器里的应用是否监听在所有网卡上。Spring Boot默认监听0.0.0.0但如果是自定义配置绑定了127.0.0.1那容器外访问必然失败。查看配置里的server.address。Docker网络模式是不是host模式。如果用了--network host-p端口映射会失效访问方式就是localhost:8080因为此时容器直接共享宿主机网络栈。另外如果容器到容器之间网络不通确认它们是否在同一个自定义网络上docker network ls和docker network inspect bridge能看出端倪。7.3 镜像太大、内存占用太高基础镜像和JVM参数的问题镜像体积大90%的原因是基础镜像选了完整版JDK或者构建阶段残留了多余文件。换成jre-alpine或jre-slim能把体积砍到三分之一。再用多阶段构建把编译工具全部排除在最终镜像外体积还能再小一个量级。内存占用高的原因一是JVM默认使用宿主机内存的25%在容器里可能不够用或过高二是容器没有设置内存上限。我通常的做法是启动命令里显式指定JVM参数ENTRYPOINT [java, -Xms256m, -Xmx512m, -jar, app.jar]再配合docker run的内存限制docker run -d --name demo-app -m 1g demo:v1.0.0这样容器最多1GB内存JVM最多512MB两者留出余量给非堆和线程栈整个进程的行为就可预期了。不用再担心某个服务把服务器的内存耗尽导致其他服务被系统杀掉。注意事项Java 8及之前版本在容器里识别内存有坑需要额外加-XX:UseContainerSupport和-XX:MaxRAMPercentage75.0这类参数。但JDK 8u191之后已经默认开启容器支持如果你用的版本恰好是8u181之类记得查一下这个点。JDK 17和21没有这个问题可以省心很多。7.4 快速问题排查参考表症状可能原因快速解决方案镜像拉取超慢没配置镜像加速按第2.3节配置registry-mirrors容器启动后马上退出应用启动失败看docker logs确认数据库连接等依赖是否正确宿主机外无法访问云安全组/防火墙没放行检查安全组入方向规则容器间数据库连不上用了localhost而不是服务名改成服务名确认在同一Compose网络服务器重启后服务丢了没加--restartalways加--restartalways或Compose写restart日志时间差8小时时区未设置Dockerfile里设置TZAsia/Shanghai容器内文件重启丢失未挂载数据卷用-v或Compose volumes持久化JVM内存异常没限制堆内存显式设置-Xmx配合容器-m参数Windows Docker启动报虚拟化错误未启用WSL2/虚拟化按7.1步骤排查容器里没有bash基于Alpine的镜像只有sh用docker exec -it 容器名 sh7.5 实际排查案例一次典型的Compose启动失败有次我在一台新的Ubuntu服务器上部署一个项目执行docker compose up -d之后Java应用一直在重启。看docker psSTATUS显示Restarting。第一反应是看日志docker logs demo-app发现报错内容是Connection refused连接MySQL失败。按常理想MySQL容器也在同一Compose网络里为什么连不上我检查了MySQL容器的状态发现它正常Running了。后来发现问题是Java应用启动太快MySQL还在初始化阶段端口虽然映射出来了但内部还没有准备好接受连接。depends_on只是控制启动顺序不会等待MySQL“可用”。当时的解决方式是给Java应用加上简单的健康检查或者重试逻辑。但我不太想改代码后来直接在Compose里加了MySQL的healthcheck然后让Java应用wait等健康检查通过再启动。也可以在Spring Boot配置里加上spring.datasource.hikari.initialization-fail-timeout把初始化失败超时拉长一点让它多等一段时间。具体配置还需要结合项目实际来定但思路是容器启动顺序不代表服务就绪顺序。这类问题很典型遇到容器反复重启不要第一时间认为是Docker坏了先看日志再用docker stats看资源占用一步步排查。8. 写在实验之后的话大概是四五年前我第一次把Java项目部署到Docker上。当时什么都不懂Dockerfile写了将近一百行绕弯路的配置基础镜像选的是openjdk:latest镜像体积接近600MB。后来一步步踩坑、看日志、优化才逐渐摸清楚哪些选择是必要的哪些是在给自己挖坑。这篇的框架基本就是我后来常用的部署套路选好基础镜像多阶段构建运行时环境变量注入配置数据卷持久化综合编排MySQL和Redis。这套流程用在大大小小的项目上稳定性一直不错。也正因为每次交接时给对方一个docker-compose.yml换来一句“起来了没问题”我才更确定当初花时间学Docker是值得的。如果你是刚接触Docker建议不要把命令背下来就完事找一个自己的项目试一遍写Dockerfile、构建镜像、跑容器、再看看docker logs里发生了什么。踩过两个坑之后你会发现这些内容远远比面试题要简单实用得多。最后再分享一个小技巧所有运维操作尽量用docker compose而不是单独执行docker run。把部署方案固化成文件比依赖记忆要可靠得多。等哪一天你需要在三台机器上部署服务再回来读这篇或者看看Compose的进阶文档会顺很多。