企业官网建设流程全解析

1. 这不是“又一个CI/CD教程”，而是Java工程师每天都在用的部署流水线

你有没有过这样的经历：改完一行代码，手动打包、上传服务器、重启服务，等了三分钟发现配置文件少了个分号；或者团队里新人配Maven环境配到怀疑人生，IDEA报错“java: you aren't using a compiler supported by lombok”，结果查了一下午才发现JDK版本和Lombok插件不匹配；又或者上线前临时打个tag，却忘了更新pom.xml里的版本号，导致生产环境跑着一个连Git日志都找不到对应commit的jar包。这些不是小问题，是每天在消耗Java工程师真实的时间、注意力和交付信心。

这篇内容讲的，就是怎么用GitHub Actions把这套重复、易错、依赖人肉记忆的操作，变成一次git push就自动完成的确定性流程——它不是概念演示，不是Hello World级别的玩具，而是我过去三年在5个中型Java项目（Spring Boot微服务、Quarkus后台、Gradle多模块工程、遗留Struts2系统容器化迁移、以及一个对接银行核心的批处理调度平台）里反复打磨、踩坑、重构后沉淀下来的可直接抄作业的生产级CI/CD流水线。核心关键词就五个：GitHub Actions、Java、CI/CD、部署、Maven——没有Docker、没有K8s、不碰云厂商控制台，只聚焦在Java项目最原始也最关键的三个动作：编译 → 测试 → 部署。它能跑在任何一台有Java环境的Linux服务器上，甚至你本地Mac或Windows WSL里也能完整验证。如果你正在被mvn clean package之后那一连串手动操作折磨，或者正为新同事入职三天还配不好Maven仓库而头疼，那接下来的内容，就是为你写的。

2. 整体设计思路：为什么是GitHub Actions + Maven原生链路，而不是Docker或云平台？

2.1 拒绝“为自动化而自动化”的陷阱

很多教程一上来就堆砌Dockerfile、Kubernetes YAML、Helm Chart，看起来很酷，但对绝大多数Java项目来说，这是典型的“杀鸡用牛刀”。我见过太多团队，花两周时间写完一套K8s部署脚本，结果发现线上服务器压根没装Docker，运维说“容器化要走年度预算审批流程”，最后还是回到scp + systemctl restart的老路。GitHub Actions的价值，从来不在它多炫技，而在于它天然与代码仓库耦合、零额外基础设施依赖、权限模型清晰、调试路径极短。你改一行workflow YAML，git push后立刻能看到执行日志，失败时点开就能看到哪一行mvn test报了OutOfMemoryError，而不是在K8s Pod日志里翻十分钟找OOMKilled事件。

所以整个方案的设计锚点非常明确：所有构建产物必须是标准Maven输出（jar/war），所有部署动作必须是纯SSH命令或SCP传输，所有环境变量必须通过GitHub Secrets注入，绝不引入任何需要额外维护的中间层。这意味着：

• 构建阶段完全复用本地开发环境：你本地mvn clean compile能过，Actions里就一定能过；
• 部署目标可以是任意Linux服务器：只要能SSH登录、有Java运行时、有足够磁盘空间，无需预装Docker、K3s、Ansible等任何工具；
• 调试成本趋近于零：本地模拟mvn verify，再对比Actions日志，差异点一目了然；

提示：这个设计不是技术保守，而是对Java生态现实的尊重。Maven本身就是Java世界的“操作系统”，它的生命周期管理（依赖解析、插件执行、profile激活）已经足够成熟。强行绕过它去搞容器化，等于在Linux上写个Python脚本再去调用Shell来执行ls——不是不行，但增加了不必要的抽象层和故障点。

2.2 为什么坚持用Maven而非Gradle？以及如何兼容Gradle项目

热搜词里反复出现maven安装与配置、maven配置阿里云仓库、idea配置maven，这说明什么？说明Maven仍是Java企业级项目的事实标准。不是Gradle不好，而是Maven的XML声明式配置、稳定的插件生态、以及与IDEA/IntelliJ的深度集成，在大型团队协作中容错率更高。比如<dependencyManagement>统一版本、<pluginManagement>锁定插件版本、<profiles>按环境切换配置，这些能力在Gradle里需要写Groovy或Kotlin DSL，对新手更不友好。

但现实是，你手头可能真有个Gradle项目。别担心，方案完全兼容——只需要两处微调：

1. Workflow文件里替换Maven命令：把mvn clean verify换成./gradlew clean build --no-daemon（加--no-daemon避免Gradle守护进程在CI环境中残留）；
2. 部署阶段定位构建产物：Maven默认是target/*.jar，Gradle是build/libs/*.jar，改下scp命令的源路径即可；

注意：Gradle项目务必在根目录提交gradlew和gradlew.bat，并确保gradle/wrapper/gradle-wrapper.jar已提交到仓库。我见过太多团队因为.gitignore误删wrapper导致CI直接失败，这种低级错误比任何技术难题都更消耗团队士气。

2.3 “部署”到底指什么？我们定义清楚边界

热搜词里“部署”和“CI/CD”高频共现，但很多人混淆了概念。CI（持续集成）解决的是“代码合并是否安全”，CD（持续部署）解决的是“代码能否自动到达生产环境”。而本方案聚焦的“部署”，特指将经过测试验证的可执行jar包，安全、可追溯、可回滚地发布到目标服务器，并完成服务启停。它不包含：

• 不包含数据库迁移（Flyway/Liquibase应作为应用启动时的内建逻辑，而非CI步骤）；
• 不包含Nginx反向代理配置更新（那是基础设施即代码IaC的范畴，应独立于应用CI）；
• 不包含蓝绿发布/金丝雀发布（中小项目用简单滚动重启+健康检查已足够）；

真正的部署价值，在于原子性和可追溯性。所谓原子性，是指一次部署要么全部成功（jar包上传+旧进程停止+新进程启动+健康检查通过），要么全部失败（保留旧版本继续提供服务）；所谓可追溯性，是指每个生产环境的jar包，都能通过其文件名中的Git commit hash或tag，精准定位到代码仓库的某一行变更。这才是工程师敢半夜接告警电话的底气。

3. 核心细节解析：从workflow.yaml到服务器上的systemd服务

3.1 GitHub Actions工作流文件（.github/workflows/ci-cd.yml）逐行拆解

这是整个方案的“心脏”，必须理解每一行背后的意图。以下是一个精简但生产可用的版本，我将逐段解释：

name: Java CI/CD Pipeline on: push: branches: [main, develop] tags: ['v*.*.*'] pull_request: branches: [main, develop]

• name只是显示名称，不影响执行；
• on.push.branches定义触发分支：main是生产发布分支，develop是预发分支，每次推送到这两个分支就触发构建；
• on.push.tags是关键：v*.*.*匹配语义化版本tag（如v1.2.3），这是发布正式版本的唯一入口。绝不允许直接向main分支push代码后自动上线，必须打tag才触发部署——这是防止误操作的铁律；
• pull_request仅触发CI（编译+测试），不触发部署，避免PR未合并就污染生产环境；

env: JAVA_VERSION: '17' MAVEN_VERSION: '3.9.6' MAVEN_OPTS: '-Xmx2g -XX:MaxMetaspaceSize=512m'

• JAVA_VERSION指定Actions运行器使用的JDK版本。必须与项目pom.xml中<java.version>一致，否则maven-compiler-plugin会报错；
• MAVEN_VERSION指定Maven版本。建议固定版本（如3.9.6），避免因Actions默认Maven升级导致插件兼容性问题；
• MAVEN_OPTS是重点：-Xmx2g防止mvn clean package时OOM（尤其多模块项目），-XX:MaxMetaspaceSize=512m限制元空间，避免类加载过多导致GC风暴。这个参数是我在线上项目实测调整出来的，比盲目设-Xmx4g更稳妥；

jobs: build-and-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0

• runs-on: ubuntu-latest选择Ubuntu运行器，稳定且社区支持好；
• actions/checkout@v4拉取代码，fetch-depth: 0是关键！默认只拉最新一次commit，但我们需要获取Git tag和历史commit信息（用于生成版本号、计算diff），必须全量拉取；

- name: Set up JDK ${{ env.JAVA_VERSION }} uses: actions/setup-java@v4 with: java-version: ${{ env.JAVA_VERSION }} distribution: 'temurin'

• setup-java@v4安装Temurin JDK（OpenJDK官方构建版），比Adoptium更可靠。distribution: 'temurin'明确指定，避免某些地区镜像源返回非标准JDK；

- name: Cache Maven dependencies uses: actions/cache@v4 with: path: ~/.m2/repository key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }} restore-keys: | ${{ runner.os }}-maven-

• 缓存Maven本地仓库（~/.m2/repository），key基于pom.xml内容哈希，只要依赖没变，下次构建直接复用缓存，节省3-5分钟。restore-keys提供模糊匹配，当pom.xml变更时能降级恢复最近一次缓存；

- name: Build with Maven run: mvn -B clean verify -DskipTests=false -Pprod env: MAVEN_OPTS: ${{ env.MAVEN_OPTS }}

• mvn -B启用批处理模式，禁用交互提示；
• clean verify是黄金组合：clean清除旧产物，verify执行所有验证阶段（包括test、integration-test、verify），比单纯package更严格；
• -DskipTests=false显式关闭跳过测试（有些项目pom.xml里默认设了skipTests=true，必须覆盖）；
• -Pprod激活prodprofile，用于加载生产环境配置（如数据库连接池大小、Redis密码等）；

- name: Upload artifact uses: actions/upload-artifact@v4 with: name: java-app-jar path: target/*.jar

• 将构建产物（target/*.jar）上传为Artifact，供后续部署Job下载。注意：Artifact有效期默认90天，足够应对绝大多数回滚场景；

deploy-to-prod: needs: build-and-test if: startsWith(github.event.ref, 'refs/tags/v') runs-on: ubuntu-latest steps: - name: Download artifact uses: actions/download-artifact@v4 with: name: java-app-jar path: ./target

• needs: build-and-test确保部署Job只在构建成功后执行；
• if: startsWith(github.event.ref, 'refs/tags/v')是安全阀：只有打tag（如git tag v1.2.3 && git push origin v1.2.3）才触发部署，push到main分支不会部署；
• download-artifact从上一个Job下载jar包到本地./target目录；

- name: Deploy to Production Server uses: appleboy/scp-action@master with: host: ${{ secrets.HOST_PROD }} username: ${{ secrets.USERNAME_PROD }} key: ${{ secrets.PRIVATE_KEY_PROD }} source: "target/*.jar" target: "/opt/myapp/releases/"

• 使用scp-action通过SSH密钥上传jar包。这里secrets.*是GitHub仓库Settings → Secrets and variables → Actions里预设的密钥；
• source和target路径需严格匹配：/opt/myapp/releases/是约定的发布目录，所有jar包都放这里，不覆盖旧版本；

- name: Remote deploy script uses: appleboy/ssh-action@master with: host: ${{ secrets.HOST_PROD }} username: ${{ secrets.USERNAME_PROD }} key: ${{ secrets.PRIVATE_KEY_PROD }} script: | cd /opt/myapp # 1. 停止当前服务 sudo systemctl stop myapp || true # 2. 创建软链接指向新jar包 JAR_NAME=$(ls -t releases/*.jar | head -n1) ln -sf "$JAR_NAME" current.jar # 3. 启动服务 sudo systemctl start myapp # 4. 等待健康检查 timeout 60 bash -c 'while [[ "$(curl -s -o /dev/null -w ''%{http_code}'' http://localhost:8080/actuator/health)" != "200" ]]; do sleep 5; done'

• ssh-action执行远程服务器上的部署脚本；
• 关键技巧：用软链接current.jar解耦部署路径与服务路径。systemd服务文件里ExecStart指向/opt/myapp/current.jar，每次部署只需更新软链接，无需修改服务配置；
• 健康检查用curl轮询/actuator/health端点，超时60秒。这是Spring Boot Actuator的标准端点，若你的项目没集成Actuator，需替换成自己的健康检查URL（如/healthz）；

3.2 服务器端systemd服务文件（/etc/systemd/system/myapp.service）详解

这是让Java应用真正“服务化”的关键，不是简单nohup java -jar xxx.jar &。以下是生产环境验证过的配置：

[Unit] Description=My Java Application After=network.target [Service] Type=simple User=myapp Group=myapp WorkingDirectory=/opt/myapp ExecStart=/usr/bin/java -Xms512m -Xmx2g -XX:+UseG1GC -Dspring.profiles.active=prod -jar /opt/myapp/current.jar Restart=always RestartSec=10 SuccessExitStatus=143 Environment="JAVA_HOME=/usr/lib/jvm/temurin-17-jdk-amd64" Environment="SPRING_CONFIG_LOCATION=file:/opt/myapp/config/application-prod.yml" [Install] WantedBy=multi-user.target

• Type=simple：适用于前台运行的Java进程（java -jar会阻塞终端）；
• User/Group：必须创建专用用户（sudo useradd -r -s /bin/false myapp），禁止用root运行应用，这是安全基线；
• ExecStart参数详解：
  • -Xms512m -Xmx2g：初始堆512MB，最大堆2GB，根据服务器内存调整（建议设为总内存的50%-75%）；
  • -XX:+UseG1GC：G1垃圾收集器，适合大堆内存和低延迟要求；
  • -Dspring.profiles.active=prod：激活生产Profile；
  • -jar /opt/myapp/current.jar：永远指向软链接，实现无缝切换；
• Restart=always：进程意外退出时自动重启；
• RestartSec=10：重启间隔10秒，避免频繁崩溃打满日志；
• SuccessExitStatus=143：捕获SIGTERM（15信号）的优雅退出码，让Spring Boot能执行@PreDestroy钩子；
• Environment：设置JAVA_HOME和外部配置文件路径，SPRING_CONFIG_LOCATION指向/opt/myapp/config/，与代码内嵌配置分离；

实操心得：第一次部署后，务必执行sudo systemctl daemon-reload && sudo systemctl enable myapp && sudo systemctl start myapp。enable确保开机自启，start立即启动。然后用sudo journalctl -u myapp -f实时查看日志，这是排查启动失败的第一现场。

3.3 GitHub Secrets安全配置与最佳实践

所有敏感信息必须通过Secrets注入，绝不能硬编码在YAML里。以下是必需的Secrets清单：

注意：PRIVATE_KEY_PROD的值是私钥文件的全部内容，包括首尾的-----BEGIN...和-----END...行。复制时务必选中整块文本，漏掉任何一行都会导致SSH认证失败。我曾因编辑器自动删除末尾换行符而调试两小时，教训深刻。

4. 实操过程：从零开始搭建，每一步都有截图级指引

4.1 准备工作：服务器环境初始化（5分钟）

在目标服务器（假设Ubuntu 22.04）上执行以下命令，这是所有Java部署的前提：

# 1. 创建专用用户和组 sudo useradd -r -s /bin/false myapp sudo mkdir -p /opt/myapp/{releases,config,logs} sudo chown -R myapp:myapp /opt/myapp sudo chmod 755 /opt/myapp # 2. 安装Temurin JDK 17（官方推荐，无License风险） wget https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.1%2B12/OpenJDK17U-jdk_x64_linux_hotspot_17.0.1_12.tar.gz sudo tar -zxf OpenJDK17U-jdk_x64_linux_hotspot_17.0.1_12.tar.gz -C /usr/lib/jvm/ sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk-17.0.1+12/bin/java 1 sudo update-alternatives --config java # 选择JDK 17 # 3. 验证Java安装 java -version # 应输出 openjdk version "17.0.1" 2021-10-19 # 4. 创建systemd服务文件（粘贴上面的myapp.service内容） sudo tee /etc/systemd/system/myapp.service << 'EOF' [Unit] Description=My Java Application After=network.target [Service] Type=simple User=myapp Group=myapp WorkingDirectory=/opt/myapp ExecStart=/usr/bin/java -Xms512m -Xmx2g -XX:+UseG1GC -Dspring.profiles.active=prod -jar /opt/myapp/current.jar Restart=always RestartSec=10 SuccessExitStatus=143 Environment="JAVA_HOME=/usr/lib/jvm/jdk-17.0.1+12" Environment="SPRING_CONFIG_LOCATION=file:/opt/myapp/config/application-prod.yml" [Install] WantedBy=multi-user.target EOF # 5. 重载systemd配置并启动 sudo systemctl daemon-reload sudo systemctl enable myapp sudo systemctl start myapp sudo systemctl status myapp # 检查是否active (running)

提示：如果systemctl status myapp显示failed，第一件事是sudo journalctl -u myapp -n 50 --no-pager看最后50行日志。90%的问题是JAVA_HOME路径错误、current.jar不存在、或application-prod.yml里数据库密码为空。

4.2 本地项目改造：让Maven产出符合部署要求的jar包

很多Java项目默认打包的jar无法直接运行，需检查pom.xml：

<build> <plugins> <!-- 1. 必须使用spring-boot-maven-plugin（Spring Boot项目） --> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <image> <builder>paketobuildpacks/builder-jammy-base:latest</builder> </image> </configuration> </plugin> <!-- 2. 或使用maven-shade-plugin（传统Java项目） --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <version>3.4.1</version> <executions> <execution> <phase>package</phase> <goals> <goal>shade</goal> </goals> <configuration> <transformers> <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> <mainClass>com.example.MyApplication</mainClass> </transformer> </transformers> </configuration> </execution> </executions> </plugin> </plugins> </build>

• Spring Boot项目：spring-boot-maven-plugin是标配，它会把所有依赖打包进fat jar，并生成可执行的MANIFEST.MF；
• 传统Java项目：用maven-shade-plugin，关键是<mainClass>必须指定你的启动类全限定名；
• 验证：本地执行mvn clean package后，target/目录下应有且仅有一个jar包（如myapp-1.0.0.jar），且能直接运行：java -jar target/myapp-1.0.0.jar；

常见问题：java -jar xxx.jar报错no main manifest attribute。这是因为MANIFEST.MF里没写Main-Class。解决方案：检查pom.xml中maven-shade-plugin的<mainClass>是否正确，或确认Spring Boot项目是否误用了maven-jar-plugin。

4.3 GitHub Actions工作流实战：从编写到首次成功部署

现在进入核心环节。在你的Java项目根目录创建.github/workflows/ci-cd.yml，内容如下（已整合前述所有要点）：

name: Java CI/CD Pipeline on: push: branches: [main, develop] tags: ['v*.*.*'] pull_request: branches: [main, develop] env: JAVA_VERSION: '17' MAVEN_VERSION: '3.9.6' MAVEN_OPTS: '-Xmx2g -XX:MaxMetaspaceSize=512m' jobs: build-and-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Set up JDK ${{ env.JAVA_VERSION }} uses: actions/setup-java@v4 with: java-version: ${{ env.JAVA_VERSION }} distribution: 'temurin' - name: Cache Maven dependencies uses: actions/cache@v4 with: path: ~/.m2/repository key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }} restore-keys: | ${{ runner.os }}-maven- - name: Build with Maven run: mvn -B clean verify -DskipTests=false -Pprod env: MAVEN_OPTS: ${{ env.MAVEN_OPTS }} - name: Upload artifact uses: actions/upload-artifact@v4 with: name: java-app-jar path: target/*.jar deploy-to-prod: needs: build-and-test if: startsWith(github.event.ref, 'refs/tags/v') runs-on: ubuntu-latest steps: - name: Download artifact uses: actions/download-artifact@v4 with: name: java-app-jar path: ./target - name: Deploy to Production Server uses: appleboy/scp-action@master with: host: ${{ secrets.HOST_PROD }} username: ${{ secrets.USERNAME_PROD }} key: ${{ secrets.PRIVATE_KEY_PROD }} source: "target/*.jar" target: "/opt/myapp/releases/" - name: Remote deploy script uses: appleboy/ssh-action@master with: host: ${{ secrets.HOST_PROD }} username: ${{ secrets.USERNAME_PROD }} key: ${{ secrets.PRIVATE_KEY_PROD }} script: | cd /opt/myapp sudo systemctl stop myapp || true JAR_NAME=$(ls -t releases/*.jar | head -n1) ln -sf "$JAR_NAME" current.jar sudo systemctl start myapp timeout 60 bash -c 'while [[ "$(curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/actuator/health)" != "200" ]]; do sleep 5; done'

然后按顺序执行：

1. 在GitHub仓库Settings → Secrets and variables → Actions里，添加四个Secrets（HOST_PROD,USERNAME_PROD,PRIVATE_KEY_PROD,APP_DB_PASSWORD）；
2. 本地提交并推送：

   git add .github/workflows/ci-cd.yml git commit -m "chore: add GitHub Actions CI/CD workflow" git push origin main

   此时build-and-testJob会触发，等待约3分钟，看到绿色勾✅表示构建成功；
3. 打tag触发部署：

   git tag v1.0.0 git push origin v1.0.0

   切换到GitHub Actions页面，你会看到deploy-to-prodJob自动启动，几秒后完成。此时登录服务器，执行：

   ls -l /opt/myapp/releases/ # 应看到类似 v1.0.0-abc123.jar 的文件 ls -l /opt/myapp/current.jar # 应指向刚上传的jar包 sudo systemctl status myapp # 应显示 active (running) curl http://localhost:8080/actuator/health # 应返回 {"status":"UP"}

实操心得：首次部署失败，90%概率在SSH密钥或路径权限。检查点：①PRIVATE_KEY_PROD是否包含完整PEM头尾；② 服务器上/opt/myapp/releases/目录是否属于myapp用户；③ssh-action的username是否与服务器上创建的用户一致（不是root）。

4.4 多环境支持：如何扩展出develop预发环境

生产环境有了，预发环境（develop）同样重要。只需在workflow中增加一个Job：

deploy-to-develop: needs: build-and-test if: github.event_name == 'push' && contains(github.event.head_commit.message, '[deploy-dev]') runs-on: ubuntu-latest steps: - name: Download artifact uses: actions/download-artifact@v4 with: name: java-app-jar path: ./target - name: Deploy to Develop Server uses: appleboy/scp-action@master with: host: ${{ secrets.HOST_DEV }} username: ${{ secrets.USERNAME_DEV }} key: ${{ secrets.PRIVATE_KEY_DEV }} source: "target/*.jar" target: "/opt/myapp-dev/releases/" - name: Remote deploy script uses: appleboy/ssh-action@master with: host: ${{ secrets.HOST_DEV }} username: ${{ secrets.USERNAME_DEV }} key: ${{ secrets.PRIVATE_KEY_DEV }} script: | cd /opt/myapp-dev sudo systemctl stop myapp-dev || true JAR_NAME=$(ls -t releases/*.jar | head -n1) ln -sf "$JAR_NAME" current.jar sudo systemctl start myapp-dev

• 触发条件改为if: github.event_name == 'push' && contains(github.event.head_commit.message, '[deploy-dev]')，即只有commit message包含[deploy-dev]才部署到预发；
• 新增HOST_DEV,USERNAME_DEV,PRIVATE_KEY_DEV三个Secrets；
• 服务器端需创建/opt/myapp-dev/目录和对应的myapp-dev.service；

这样，日常开发时，你想部署到预发，只需：

git commit -m "[deploy-dev] feat: add user login validation" git push origin develop

既避免了预发环境被随意污染，又给了开发快速验证的能力。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 Maven构建失败：java: outofmemoryerror: insufficient memory

这是Java CI中最经典的报错。表面看是内存不足，但根因往往在配置。排查路径如下：

我的实测数据：一个12模块的Spring Boot项目，在-Xmx2g -XX:MaxMetaspaceSize=512m下稳定运行；若开启Jacoco覆盖率报告，需额外增加-XX:MaxMetaspaceSize=1g。

5.2 部署后服务启动失败：Failed to start myapp.service

systemctl status myapp显示failed，但日志里只有Process exited with status 1。这是典型的“启动脚本静默失败”。按此顺序排查：

1. 检查current.jar是否存在且可读：

   ls -l /opt/myapp/current.jar # 应显示 -> releases/myapp-1.0.0.jar file /opt/myapp/current.jar # 应显示 "Java archive data (ZIP)"

2. 手动执行ExecStart命令：

   sudo -u myapp /usr/bin/java -Xms512m -Xmx2g -jar /opt/myapp/current.jar

   此时会直接输出Spring Boot启动日志，错误一目了然（如Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'db.password'，说明application-prod.yml缺失）；

3. 检查SPRING_CONFIG_LOCATION路径：

   sudo -u myapp ls -l /opt/myapp/config/application-prod.yml

   若文件不存在，需提前在服务器上创建，并确保myapp用户有读取权限；

4. 检查端口占用：

   sudo ss -tuln | grep ':8080'

   若被其他进程占用，修改application-prod.yml中的server.port，或杀掉冲突进程；

注意：sudo -u myapp必须加上，因为systemd服务是以myapp用户身份运行的，权限和环境变量与root不同。跳过这步，你看到的日志可能是误导性的。

5.3 GitHub Actions执行超时：The job running on ubuntu-latest has exceeded the maximum time of 3600 seconds

免费版GitHub Actions单个Job最长60分钟。超时通常发生在：

• 测试用例执行过长：在pom.xml中为maven-surefire-plugin添加超时：

  <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <forkCount>1</forkCount> <reuseForks>false</reuseForks> <argLine>-Xmx1g</argLine> <testFailureIgnore>true</testFailureIgnore> <trimStackTrace>false</trimStackTrace> <includes> <include>**/*Test.java</include> </includes> <excludes> <exclude>**/integration/**</exclude> </excludes> <!-- 关键：设置单个测试类超时 --> <parallel>methods</parallel> <threadCount>2</threadCount> <perCoreThreadCount>true</perCoreThreadCount> <forkedProcessTimeoutInSeconds>300</forkedProcessTimeoutInSeconds> </configuration> </plugin>

• 依赖下载慢：配置阿里云Maven镜像。在pom.xml中添加：

  <mirrors> <mirror> <id>aliyunmaven</id> <