企业官网建设流程全解析

做后端开发这些年，我最怕的不是写业务代码，而是“部署”这两个字。SpringBoot 项目虽然打出来就是一个 jar，但真正上线的时候，环境不一致、依赖缺失、端口冲突、忘记重启服务，哪一件都能让人当场崩溃。后来我把 SpringBoot + Docker + Jenkins 连成一条流水线，代码 push 到仓库之后，单元测试、打包、镜像构建、服务器部署全部自动跑完，我只需要在 Jenkins 页面上看日志就行。这篇文章打算把这条流水线从设计思路、环境搭建、配置文件、完整实战到避坑经验全部讲清楚，正在折腾 CI/CD 的同学可以直接照着往下走。

1. 这套组合拳到底解决了什么问题

1.1 先回忆一下没有流水线时的发布流程

我最早带一个订单服务项目时，团队就三个人，发布全靠手搓。每次发版的固定动作是：本地跑一遍mvn clean package，然后 scp 把 jar 包传到测试服务器，再用ps -ef | grep java找端口，kill 掉旧进程，最后 nohup 启动新包。听起来简单，实际上一周来几次，问题就全出来了。

最常见的是“我本地是好的”。本地 JDK 8，服务器 JDK 11，本地内存充足，服务器是 2G 小机器，启动参数没调，一压测就 OOM。还有一次同事把配置文件里某个密码改成自己本地的，打包后直接传上去，结果连不上生产数据库，服务起不来。当时排查了半天，最后发现是“本地环境”和“测试环境”的差异在作怪。

这些痛点的本质是：发布流程没有标准化，每一步都依赖人的记忆和操作习惯。哪怕你写一个 deploy.sh，它也只是把一部分操作脚本化，测试、构建、镜像管理这些环节仍然是割裂的。

所以当时我定的目标状态是：开发者把代码推到仓库，后续动作全部自动化。仓库收到新代码 -> 自动拉取 -> 跑单元测试 -> 用 Maven 打包 -> 构建 Docker 镜像 -> 推送到镜像仓库 -> 目标服务器拉取新镜像并启动容器。如果哪一步挂了，能在网页上直接看到日志，不用 SSH 上去翻文件。这其实就是今天要讲的完整流水线。

1.2 为什么偏偏是 SpringBoot + Docker + Jenkins

先说 SpringBoot。它不是流水线的一部分，但它是整个流程的“产物主体”。SpringBoot 应用打包成可执行 jar，内嵌 Tomcat，不需要单独安装 Web 容器，天然适合容器化。如果你换成传统 WAR 包项目，构建和部署方式会复杂一些，但 SpringBoot 这种“拿起来就能跑”的特点，让流水线可以很干净。

再说 Docker。我要解决的核心问题是环境一致性。把 jar 包丢进一个 Docker 镜像里，等于把“应用 + 运行环境 + 启动命令”一起固化下来。本地能跑的镜像，生产上大概率也能跑，因为你交给部署目标的不再是半成品 jar，而是完整的运行时。这一点是手动 scp 永远比不了的。

最后是 Jenkins。你可能想，为什么不直接写个 Shell 脚本加 cron？说实话，小项目确实可以，但我选择 Jenkins 有几个实际理由：第一，有任务历史和构建记录，出问题能对比上一次成功和这次失败的日志；第二，有权限控制和凭证管理，不用把服务器密码写在脚本里；第三，插件生态非常全，Docker、Git、通知、Blue Ocean 这些都能直接接；第四，后续如果接 Kubernetes 或作为分布式构建调度，Jenkins 无缝衔接。

用一张表格来对比手动发布和流水线发布，会更直观。

这套组合选型不算什么黑科技，但它把一个中小团队最缺的“发布确定性”给补上了。

1.3 流水线从头到尾要经过哪些节点

在开始动手之前，我习惯先把整条链路在纸上画一遍。虽然不建议用太复杂的架构图，但每个阶段的输入输出必须清楚。

整个流水线大致分七个节点：

1. 代码提交。开发者把代码推送到 Git 仓库，这一步是触发源头。
2. 拉取代码。Jenkins 从仓库拉取指定分支的最新代码。
3. 单元测试。在构建机上执行mvn test，测试失败直接终止。
4. 打包构建。执行mvn clean package -DskipTests生成可执行 jar。
5. 构建镜像。根据 Dockerfile 将 jar 打成 Docker 镜像。
6. 推送镜像。把镜像推到镜像仓库，并打上版本标签。
7. 部署上线。目标服务器拉取新镜像，停止旧容器，启动新容器。

每个节点的产物分别是什么，也要心里有数：代码提交的产物是 commit；测试的产物是测试报告；打包的产物是 jar；镜像构建的产物是带 tag 的镜像；部署的产物是运行中的容器。

搞清楚这些之后，接下来就是逐个把环境搭起来。

2. 环境准备：把四件套装好

2.1 版本选型要先想清楚，不然坑在后面

很多同学铆足劲安装，结果第一条命令就跑不通，原因多半是版本不匹配。我的建议是先定版本，再动手。

这里要特别提醒一个“springboot 版本太高”的坑。如果你以前写的是 SpringBoot 2.x，升级到 3.x 以后，javax.*相关包会变成jakarta.*，很多老配置和代码要跟着改。比如spring.factories的自动配置方式也被AutoConfiguration.imports替代。这意味着，你不能拿一套旧的 SpringBoot 2.x 项目代码直接放到新流水线里跑，需要先保证项目本身能在 JDK 17 下构建通过。

我自己建项目时统一用 JDK 17，因为它是长期支持版本，Text Blocks、Switch 表达式这些语法能让代码写起来舒服不少，而且 Docker 生态里对应的基础镜像非常成熟。

2.2 Docker 环境安装与初始化

构建机和部署机建议都用标准 Linux 发行版。Windows 或 Mac 上的 Docker Desktop 适合开发时用，但不建议拿来做 Jenkins 构建节点，原因有两个：一是文件路径和权限模型跟 Linux 有差异，二是资源占用太高。

Linux 上安装 Docker 很简单，我以 Debian/Ubuntu 为例，核心步骤如下：

# 安装依赖 sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg # 添加 Docker 官方 GPG 密钥和仓库 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 a+r /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 # 安装 Docker Engine 和 compose 插件 sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

装完以后，记得把当前用户加进 docker 组，否则每一条 docker 命令都要加 sudo。执行之后重新登录一次生效。

sudo usermod -aG docker $USER

开发机上如果用 Windows 的 Docker Desktop，偶尔会遇到启动时提示 “virtualization support not detected”，这个我会在后面的排查章节详细讲，这里先提一句：本质是 BIOS 的虚拟化没开，或者 Windows 的 Hyper-V/WSL2 功能没启用，不是 Docker 本身的问题。

2.3 Jenkins 怎么装：容器方式还是 war 包方式

这是个老问题了。我两种都试过，最终长期用的是“容器方式安装 Jenkins”。因为 Jenkins 本身也是一个 Java 应用，升级、迁移、备份，用容器管理最方便。

但有一个关键细节：我希望 Jenkins 容器内部能直接调用宿主机的 docker 命令。所以启动 Jenkins 容器时，必须把宿主机的 Docker socket 和 docker 客户端二进制挂载进去。

docker run -d \ --name jenkins \ -p 8080:8080 \ -p 50000:50000 \ -v jenkins_home:/var/jenkins_home \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /usr/bin/docker:/usr/bin/docker \ -e TZ=Asia/Shanghai \ jenkins/jenkins:lts

解释一下为什么这样挂载。Jenkins 容器内的 jenkins 用户通过访问宿主机的/var/run/docker.sock，可以和宿主机上的 Docker 守护进程通信，这样我们在流水线里执行docker build、docker push，实际是在调度宿主机的 Docker。这种模式叫 docker-outside-of-docker，和传统的 Docker-in-Docker 相比，不需要启动一个嵌套的 Docker 服务，资源开销小，也更稳定。

第一次启动后，容器日志或宿主机docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword可以拿到管理员密码。初始化时插件不要全装，按需来就好，我装的基础插件是这些：

• Pipeline
• Git
• Docker Pipeline
• Docker plugin
• Credentials Binding
• Timestamper（时间戳，看日志舒服很多）
• Workspace Cleanup（构建前清理工作区）
• Locale（Jenkins 汉化用）

提到汉化，顺便说一句：装 Locale 插件后，还要在系统设置里把语言改成 zh_CN，并勾选强制使用，否则中英文会混杂。

2.4 凭证管理：Git 和镜像仓库的钥匙

自动化流水线里最避讳的一件事，就是把账号密码写在 Jenkinsfile 里。Jenkins 的凭证管理就是干这个的。

进入 系统管理 -> Credentials -> System -> Global credentials -> Add Credentials，我建议至少准备三组：

1. Git 凭证。如果仓库是 GitLab，用用户名密码或 Access Token 都行；如果是 GitHub，用 Personal Access Token。我推荐用 token，因为 token 可以精确控制权限范围和有效期。
2. 镜像仓库凭证。Docker Hub、Harbor 或私有 Registry，都需要一个账号密码，用来执行docker push。
3. 部署服务器 SSH 凭证。如果目标是远程服务器，通过 SSH 执行部署命令，需要上传私钥或密码。

这三组凭证会分别绑定到 Jenkinsfile 中的不同步骤。凭证 ID 自己命名清晰一点，比如gitlab-cred、docker-registry-cred、deploy-server-cred，后续写流水线时不容易记混。

3. 应用容器化：Dockerfile 与镜像构建

3.1 多阶段构建：让最终镜像瘦身

SpringBoot 项目写 Dockerfile，我强烈推荐多阶段构建。简单说，第一阶段用一个带 Maven 和 JDK 的镜像去编译，第二阶段只拷贝编译好的 jar，配上 JRE 运行环境。这样最终镜像里没有 Maven、没有源码、没有临时文件，体积小，安全性也高。

下面是我常用的模板，以 SpringBoot 3.x 为例。

# 第一阶段：构建 FROM maven:3.9.6-eclipse-temurin-17 AS builder WORKDIR /workspace COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn clean package -DskipTests # 第二阶段：运行 FROM eclipse-temurin:17-jre RUN useradd -m appuser WORKDIR /app COPY --from=builder /workspace/target/order-service.jar app.jar EXPOSE 8080 USER appuser ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /app/app.jar"]

这个文件的第一阶段有一行RUN mvn dependency:go-offline，很多人会忽略它的价值。Docker 构建镜像时是有层缓存机制的，只要pom.xml没变，这一层就不会重新执行，依赖会被完整缓存下来。如果把它去掉，直接COPY . .，那你每次改一行代码，Maven 都要重新下载所有依赖，构建时间翻几倍都不止。

第二阶段用eclipse-temurin:17-jre而不是继续用maven镜像，是因为运行阶段根本不需要 Maven。我见过有人偷懒，一个镜像从头跑到尾，最后镜像体积 800M。用多阶段构建之后，SpringBoot 镜像一般能控制在 250M 以内，如果再用jlink裁剪 JRE，能压到 150M 左右。

还有一个细节：ENTRYPOINT我写成了 shell 形式，而不是 exec 形式，原因是为了能接收JAVA_OPTS环境变量。这样部署时如果想调整 JVM 堆大小，直接在容器环境变量里传即可，不用改镜像。

3.2 镜像仓库与版本标签

镜像构建出来之后，不能只留在构建机上，需要推到一个镜像仓库里。常见选择有三个：Docker Hub、简单私有 Registry、Harbor。各有各的适用场景。

我个人的习惯是，团队不大时直接用带 Web UI 的轻量 Registry 或 Harbor，重点是要支持镜像推送时的凭证认证。镜像的 tag 必须包含可追溯的信息，比如构建号或 Git commit 短哈希。

举例来说，order-service:20250112-18或者order-service:1.2.3-a1b2c3d。千万不要所有人都在用同一个latest标签，否则生产上一旦拉错镜像，排查起来很痛苦。给每个构建一个唯一 tag，回滚时直接docker run上一个 tag 就行，这是成本最低的回滚方案。

3.3 构建完先本地验证一把

在接流水线之前，我总会先在构建机上手动把镜像构建一遍，验证能不能启动。

docker build -t order-service:test . docker run --rm -p 8080:8080 -e SPRING_PROFILES_ACTIVE=dev order-service:test curl http://localhost:8080/actuator/health

有的项目一启动就要连 MySQL、Redis，这时候只用docker run拉一个应用容器是不够的。可以把 MySQL 和 Redis 也用 Docker Compose 编排在同一套网络里，本地一把拉起。简单示例：

services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: order_db ports: - "3306:3306" order-service: image: order-service:test environment: SPRING_PROFILES_ACTIVE: dev SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/order_db ports: - "8080:8080"

这里的关键点是 SpringBoot 连接数据库的地址，不要写localhost，要写服务名mysql，因为同一个 Compose 网络里，服务名就是 DNS 名。如果这一步验证通过，说明镜像本身没问题，就可以放心交给 Jenkins。

4. Jenkins 流水线脚本设计与参数化

4.1 声明式流水线的基本骨架

Jenkins 的 Pipeline 有两种写法，声明式和脚本式。我推荐声明式，它把结构固定下来，可读性更强，适合团队里其他人接手维护。管线常见格式是这样。

pipeline { agent any stages { stage('阶段名') { steps { // 具体命令 } } } post { success { /* 成功处理 */ } failure { /* 失败处理 */ } } }

一个容易混淆的细节是steps块里可以直接写sh 'xxx'，也可以写echo、script等步骤。当需要执行 Groovy 逻辑时，就得包一层script { }。比如我要动态决定镜像名，就会在script块里处理变量。

4.2 从拉代码到部署的完整 Jenkinsfile

我把前面提到的七个节点串成 Jenkinsfile，直接贴出来参考：

pipeline { agent any triggers { // 这里放置 webhook 或轮询的触发配置 } parameters { string(name: 'BRANCH', defaultValue: 'main', description: '要构建的分支') string(name: 'APP_NAME', defaultValue: 'order-service', description: '应用名') string(name: 'DEPLOY_PORT', defaultValue: '8081', description: '宿主机映射端口') } environment { REGISTRY = 'registry.example.com' IMAGE = "${REGISTRY}/${params.APP_NAME}" } stages { stage('拉取代码') { steps { cleanWs() git branch: "${params.BRANCH}", credentialsId: 'gitlab-cred', url: 'http://gitlab.example.com/backend/order-service.git' } } stage('单元测试') { steps { sh 'mvn test' } } stage('打包') { steps { sh 'mvn clean package -DskipTests' } } stage('构建镜像') { steps { script { docker.build("${IMAGE}:${BUILD_NUMBER}", ".") } } } stage('推送镜像') { steps { script { docker.withRegistry("https://${REGISTRY}", 'docker-registry-cred') { docker.image("${IMAGE}:${BUILD_NUMBER}").push() docker.image("${IMAGE}:${BUILD_NUMBER}").push('latest') } } } } stage('远程部署') { steps { sshagent(['deploy-server-cred']) { sh """ ssh deploy@prod-server " docker pull ${IMAGE}:${BUILD_NUMBER} && docker stop ${params.APP_NAME} || true && docker rm ${params.APP_NAME} || true && docker run -d --name ${params.APP_NAME} \ -p ${params.DEPLOY_PORT}:8080 \ -e SPRING_PROFILES_ACTIVE=prod \ ${IMAGE}:${BUILD_NUMBER} " """ } } } } post { failure { echo '构建失败，请检查日志' } success { echo "部署完成：${IMAGE}:${BUILD_NUMBER}" } } }

这个文件有几个值得注意的地方。

BUILD_NUMBER是 Jenkins 自带的环境变量，代表当前构建的序号，每次递增。用它做镜像 tag，可以保证每次构建的镜像都是唯一的，不会和旧版本冲突。类似的环境变量还有很多，比如GIT_COMMIT、GIT_BRANCH、WORKSPACE，看时间段可以用 Timestamper 插件在日志上加时间戳。

远程部署这一步，我采用 SSH 直接连目标服务器执行命令。这里建议不要把所有部署逻辑都写成 ssh 后面的一大串，而是先在目标服务器上放一个deploy.sh脚本，Jenkins 只负责调用脚本。这样既能减少 SSH 传输复杂命令的出错概率，也让运维同学能在服务器上看到清晰的部署日志。

另外注意，docker stop后面加了|| true。原因是第一次部署时容器不存在，stop 返回非 0，如果不用|| true，整个部署阶段会被判定为失败。

4.3 参数化构建与触发方式

流程跑通之后，还要让开发者按需选择部署环境。我开启参数化构建后，手动触发 Jenkins 任务时，可以填分支名、应用名、部署端口。比如测试环境填BRANCH=develop，生产环境填BRANCH=release，在同一个 Jenkins job 里切换，非常方便。

自动触发的常见方式有两种。一是 GitLab/GitHub 的 Webhook，仓库收到 push 事件后，请求 Jenkins 的一个远程 URL，让构建自动开始。二是在triggers块配轮询，比如每五分钟检查一次仓库是否有新提交。Webhook 更实时，但需要 Jenkins 对公网或内网网络可达；轮询实现简单，最坏情况延迟几分钟。

我推荐团队里把 Webhook 和分支过滤配合起来：只在 push 到 main 或 develop 分支时触发，其他临时分支不触发，不然每个功能分支都会跑一次构建，浪费资源。

4.4 构建结果通知不能少

日志不是所有人都看得及时，所以通知要主动。最简单的方案是 Jenkins 邮件通知，但我用下来更推荐钉钉或企业微信机器人。机器人本质是往一个 webhook 地址 POST 一段 JSON，在post块里写sh 'curl ...'即可。

post { failure { sh ''' curl -H "Content-Type: application/json" \ -d '{"msgtype":"text","text":{"content":"构建失败：order-service"}}' \ http://your-dingtalk-webhook ''' } }

这样构建一挂，手机立刻收到消息，不用一直盯着 Jenkins 页面。

5. 从代码提交到服务上线：完整跑一遍流水线

5.1 提交代码触发流水线

环境都配好了，我用一次真实的发布过程来演示。假设我在本地修复了一个订单超时问题，提交信息是fix: adjust order timeout logic，然后执行：

git push origin main

GitLab 收到 push 后，Webhook 通知 Jenkins，任务列表里立刻出现一个新的构建记录。状态从排队开始，很快就进入“拉取代码”阶段。这个触发链路一开始配置时最容易出问题，前后端网络不通、token 配错都会导致没反应，这些后面再讲。

5.2 在构建日志里看每一步的产出

点进构建控制台，看到的日志大概是这样的片段：

[Pipeline] stage [Pipeline] { (拉取代码) [Pipeline] git Checking out Revision a1b2c3d4... [Pipeline] { (单元测试) ... Tests run: 42, Failures: 0, Errors: 0, Skipped: 0 [Pipeline] { (打包) ... Building jar: target/order-service.jar [Pipeline] { (构建镜像) Step 1/9 : FROM maven:3.9.6-eclipse-temurin-17 AS builder ---> Using cache ... Successfully tagged registry.example.com/order-service:18 [Pipeline] { (推送镜像) The push refers to repository [registry.example.com/order-service] 18: digest: sha256:... [Pipeline] { (远程部署) ... docker run -d --name order-service -p 8081:8080 registry.example.com/order-service:18

日志其实是很好的“证据链”。哪一步耗时多少、有没有命中缓存、镜像 digest 是什么，全都看得到。比如Using cache出现，说明依赖层没有重新构建，这验证了我前面说的分层缓存策略。

如果看到构建失败，第一时间不要看完整输出，而是顺着阶段名往下找。Jenkins 的 Stage View 插件会把每个阶段用色块显示，红色挂点就是问题点，效率比我以前滚动态日志高得多。

5.3 部署后的检查与回滚

流水线显示成功后，我建议不要直接认为万事大吉，还要验证服务真的可用。目标服务器上执行：

docker ps | grep order-service docker logs --tail 200 order-service curl http://localhost:8081/actuator/health

这三条命令分别确认容器状态、应用启动日志、健康检查结果。如果 health 接口返回UP，才算真正部署完成。

万一新版本有问题，回滚也很简单。假设当前线上是构建号 18，要回退到 17，就执行：

docker stop order-service && docker rm order-service docker run -d --name order-service -p 8081:8080 registry.example.com/order-service:17

之所以能这样流畅，就是因为每个构建号的镜像都是独立存在的。如果一开始偷懒都用 latest，回滚就会变成一场噩梦。

6. 常见问题排查与避坑实录

6.1 高频问题速查表

下面这张表是我在搭建和日常使用过程中踩过的坑，按出现频率排了个序。

6.2 Jenkins 容器内调用 Docker 的权限坑

这个坑我保证你会遇到，所以单独拿出来说。容器方式启动 Jenkins 后，流水线里执行docker build时，最容易报两类错。

一类是docker: command not found。原因是容器里根本没有 docker 客户端二进制，启动时没挂载/usr/bin/docker。解决方法是启动 Jenkins 容器时挂载宿主机 docker 客户端，并确认版本和 socket 匹配。

另一类是Permission denied while trying to connect to the Docker daemon socket。原因是/var/run/docker.sock的属主是宿主机的 root 用户或 docker 组，而 Jenkins 容器内的 jenkins 用户没有权限访问。简单来说，jenkins 用户在宿主机上并不存在，所以 socket 的权限校验会走一遍“other”权限，默认就是拒绝。

我的处理方式是把 Jenkins 容器内的 jenkins 用户，加到宿主机的 docker 组里。但由于容器和宿主机的用户体系并不完全打通，更稳妥的一种做法是修改 socket 的属组，或者把 docker CLI 和 socket 的权限放宽到o=rw。需要说明的是，这种做法的安全边界是：能访问 Docker socket 就等同于能控制宿主机。所以我一般建议只用在内部开发/测试构建节点上，生产环境要谨慎，条件允许的时候应该用 Kubernetes 动态 agent 或特权模式做隔离。

6.3 并发构建冲突与版本回滚策略

流水线跑起来之后，第二次坑大概率出现在“并发”上。场景是：我同时推了两个分支到仓库，GitLab webhook 连续触发 Jenkins，结果两个构建同时在“远程部署”阶段去操作同一台服务器，一个docker stop把另一个刚启动的容器给停了，场面一度很混乱。

解决办法有两个层面。第一，给任务加并发限制，让同一时间只有一个构建在跑。

properties([ disableConcurrentBuilds(abortPrevious: true) ])

这一段要放在 pipeline 块最前面。abortPrevious: true表示新的构建开始后，直接中断正在跑的那个，适合解决连续 push 触发多次的冗余问题。

第二，在部署层面不要让latest成为唯一确定版本。刚才部署阶段一直是按BUILD_NUMBER来部署的，这一点务必保持。如果为了图省事统一用 latest，并发部署时可能两个构建各自拉取，结果最后一个 push 的人赢，但谁是最后，日志上很难快速定位。

我实际用的版本策略是：Docker tag 对应 Git commit 短哈希，同时打上BUILD_NUMBER的标签。回滚时直接切回上一个 commit 的镜像即可，既准确又可审计。

6.4 Windows 环境下 Docker Desktop 的启动问题

虽然不是 Linux 部署机的必备环节，但很多同学开发机是 Windows，会碰到 Docker Desktop 启动时报virtualization support not detected。这个错误字面意思很清楚：宿主机没有开启虚拟化支持，Docker Desktop 无法创建 Linux 虚拟机。

排查步骤就三步：

1. 开机进 BIOS，确认 CPU 虚拟化选项Intel VT-x或AMD-V已开启。
2. 在 Windows 功能里勾选“适用于 Linux 的 Windows 子系统”和“虚拟机平台”，然后重启。
3. 确认 Windows 版 Docker Desktop 的运行模式是 WSL2，而不是旧版 Hyper-V，有时 Hyper-V 和第三方虚拟机软件冲突。

这个坑和流水线本身关系不大，但会影响你在本地的验证环节。如果开发机起不来 Docker，就只能在 Linux 构建机上完成镜像验证，体验会差一些。

最后再分享一个我自己的操作习惯。流水线全部跑通之后，并不是说就一劳永逸了，我仍然会在每次大版本发布前，手动在构建机上用新镜像跑一遍 smoke test，curl 一下核心接口，再让 Jenkins 自动部署到生产。这个动作看着多余，但可以拦截掉那些“镜像构建成功但业务接口 500”的问题。自动化解决的是重复劳动，不等于放弃最终把关。搭建流水线的过程，本质上是一件“花时间省时间”的事情，前期把环境、脚本、权限这些磨顺了，后面的每一次发布都会变得轻松可靠。