1. 项目概述为什么“Linux 部署 SpringBoot 项目”是每个后端工程师绕不开的硬技能你手头刚写完一个功能完整的 SpringBoot 项目本地mvn clean package打出一个xxx.jar双击或者java -jar xxx.jar一跑浏览器打开http://localhost:8080页面秒开心里美滋滋。但当你把 jar 包传到公司那台崭新的 CentOS 服务器上敲下java -jar xxx.jar然后满怀期待地在公司电脑上输入服务器 IP 加端口——页面打不开连curl -I http://server-ip:8080都返回Connection refused。这时候你才真正意识到写完代码只是万里长征第一步让代码在生产环境里稳稳当当地跑起来才是检验一个工程师是否成熟的分水岭。这就是“Linux 部署 SpringBoot 项目”的真实意义。它不是教你怎么写 Hello World而是教你如何把一个开发态的、依赖 IDE 和本地环境的 Java 应用变成一个生产态的、能扛住并发、能自动恢复、能被监控、能被运维团队一眼看懂的“服务”。这个标题背后藏着至少三层硬核需求。第一层是环境适配你的开发机可能是 macOS 或 WindowsJDK 版本是 17Maven 是 3.9而生产服务器大概率是 CentOS 7/8、Ubuntu 20.04 或国产麒麟、统信系统JDK 可能是 OpenJDK 11甚至还要考虑 ARM64 架构比如华为鲲鹏、飞腾 CPU。第二层是进程守护java -jar命令在终端里一执行你关掉 SSH 连接进程就跟着挂了。生产环境要求服务 7x24 小时在线这需要systemd或supervisord这类进程管理器来拉起、监控、重启。第三层是网络暴露与安全直接把 SpringBoot 的 8080 端口暴露在公网上这是运维大忌。必须通过 Nginx 做反向代理隐藏真实端口统一处理 HTTPS、静态资源、负载均衡甚至 WAF 防护。所以当你看到“Linux 部署 SpringBoot 项目”这个标题它本质上是在问“我如何把一个开发玩具变成一个能放进生产环境货架里的工业品” 这个问题的答案决定了你写的代码是“能跑”还是“敢上线”。它适合所有刚从校园走向职场的 Java 初级工程师也适合那些常年在 SpringCloud 微服务里摸爬滚打、却对单体应用部署细节已经生疏的中高级开发者。因为无论架构多复杂最底层的那个服务实例终究要落在一台 Linux 机器上靠java命令启动。掌握它你就拿到了进入生产环境的那把钥匙。2. 核心思路拆解从“能跑”到“稳跑”的四条技术路径与选型逻辑面对一个.jar包摆在你面前的不是一条路而是四条截然不同、各有利弊的技术路径。选择哪一条不取决于哪个“听起来更酷”而取决于你当前所处的阶段、团队的技术栈和项目的实际规模。我干了十多年运维和 DevOps见过太多人因为选错路在项目上线前一周疯狂踩坑。2.1 路径一最原始的java -jarnohup新手入门临时验证这是所有人的起点也是最脆弱的一条路。核心命令就一句nohup java -jar myapp.jar app.log 21 。它的逻辑极其简单nohup让进程忽略SIGHUP信号即 SSH 断开信号重定向标准输出到日志文件21把错误输出也合并进去最后的让它在后台运行。优点是零学习成本三秒上手适合你第一次把 jar 包扔到测试服务器上快速验证“它到底能不能跑起来”。但它的致命缺陷在于“无守护”。如果 JVM 因为 OOM 崩溃了或者你的代码里有个未捕获的RuntimeException进程会直接退出而nohup不会管它死活也不会尝试重启。你第二天早上来上班发现服务挂了一夜日志里只有一行java.lang.OutOfMemoryError: Java heap space然后开始漫长的排查。所以这条路径的定位非常清晰仅限于五分钟内的快速验证绝不允许出现在任何预发布或生产环境。我见过最惨的案例是一个创业公司的 MVP 产品就用nohup跑在一台阿里云 ECS 上结果某天凌晨内存泄漏服务挂了老板早上六点打电话过来整个技术团队手忙脚乱花了两小时才恢复。这种“裸奔”式部署代价远高于你花十分钟配置一个systemd服务。2.2 路径二systemd守护服务生产环境事实标准推荐首选systemd是现代 Linux 发行版CentOS 7、Ubuntu 16.04的默认初始化系统它早已不是简单的“开机自启”工具而是一个功能完备的进程生命周期管理器。选择systemd是因为它解决了nohup的所有痛点并且与操作系统深度集成。它的核心优势有三点一是强健的进程守护。你可以配置Restartalways只要进程退出systemd就会立刻拉起一个新的还可以配置RestartSec10每次重启前等待 10 秒避免进程反复崩溃导致的“雪崩”二是精准的依赖管理。你可以声明Afternetwork.target确保网络服务启动完成后再启动你的应用三是标准化的日志与状态查询。所有systemd管理的服务日志都统一由journalctl收集journalctl -u myapp.service -f就能实时查看再也不用满/var/log目录去翻.log文件。更重要的是systemd的配置文件.service文件本身就是一份清晰的“部署说明书”它明明白白地告诉你这个服务用了什么 JDK、什么参数、监听什么端口、以什么用户身份运行。这对于团队协作和后续的审计、交接价值巨大。所以如果你的服务器是较新的发行版systemd是我毫无保留的首选。它不是最炫的但它是“最稳的”是经过千万次生产环境锤炼出来的可靠方案。2.3 路径三Docker 容器化微服务与云原生基石中长期必学Docker 的本质是给你的 SpringBoot 应用套上一个“标准化的集装箱”。它把你的 jar 包、JDK、甚至 Linux 内核的特定版本全部打包进一个镜像里。这样你在开发机上构建的镜像和在生产服务器上运行的镜像保证是 100% 一致的。这彻底消灭了“在我机器上是好的”这类经典甩锅话术。Docker 的部署流程是先写一个Dockerfile里面定义好基础镜像如openjdk:11-jre-slim、复制 jar 包、暴露端口然后docker build -t myapp .构建镜像最后docker run -d --name myapp -p 8080:8080 myapp启动容器。它的优势在于环境一致性和可移植性。一个 Docker 镜像可以无缝地从你的笔记本跑到腾讯云的 CVM再跑到阿里云的 ACK 集群甚至跑到边缘计算设备上完全不需要关心底层 OS 的差异。这也是为什么所有云厂商都在力推容器服务。但它的学习曲线比systemd更陡峭。你需要理解镜像分层、数据卷挂载、网络模式bridge/host、以及如何安全地管理敏感配置如数据库密码。对于一个只有单体应用、且没有专职运维的小团队过早引入 Docker可能会把简单问题复杂化。我的建议是把它当作一项“中长期投资”。当你开始规划微服务拆分或者准备上云Docker 就不再是可选项而是必选项。2.4 路径四宝塔面板等可视化工具小白友好但需警惕“黑盒陷阱”宝塔面板这类工具把systemd、Nginx、MySQL 等所有操作都封装成了图形界面的按钮。你只需要上传 jar 包点几下鼠标填几个表单服务就起来了。这对完全没有 Linux 基础的开发者简直是福音。它极大地降低了入门门槛让你能把精力集中在业务代码上。然而正如此前论坛里大量用户的吐槽所揭示的这种“傻瓜式”操作背后是一个巨大的“黑盒陷阱”。当你点击“一键部署”后宝塔在后台究竟做了什么它创建了哪个systemd服务它生成的 Nginx 配置文件在哪里它用的是哪个 JDK 版本这些关键信息都被隐藏在了图形界面之下。一旦服务出了问题比如端口冲突、配置文件加载失败、或者升级后功能异常你就会陷入一种“看得见、摸不着”的绝望境地。因为你无法像调试代码一样去逐行检查部署脚本。你只能在界面上点来点去或者去翻那些被宝塔自动生成、格式混乱、注释缺失的配置文件。所以我的经验是宝塔可以作为你学习的“脚手架”但绝不能成为你生产的“拐杖”。我建议的正确用法是先用宝塔快速部署一个 demo然后立刻 SSH 登录服务器找到它生成的所有配置文件通常在/www/server/panel/vhost/和/www/wwwroot/下把它们全部拷贝出来一行一行地读搞懂每一行的作用。当你把宝塔背后的“黑盒”全部拆解成白盒之后你就可以自信地抛弃它转而用纯命令行的方式进行部署和维护。这才是技术成长的正道。3. 核心细节解析SpringBoot 部署中那些“不起眼”却致命的细节很多工程师在部署时会把注意力全部放在“怎么启动”这个动作上却忽略了启动之前和启动过程中那些决定成败的“毛细血管”级细节。这些细节往往不会在报错日志里直接体现但会让你在排查问题时耗费数小时甚至数天。3.1 JDK 版本与架构的“隐形杀手”SpringBoot 项目对 JDK 的版本有严格要求。一个用 SpringBoot 2.7.x 开发的项目其pom.xml中spring-boot-starter-parent的版本决定了它编译时使用的 JDK 特性。如果你在开发机上用 JDK 17 编译然后把 jar 包扔到一台只装了 OpenJDK 8 的 CentOS 7 服务器上java -jar命令会直接报错Unsupported major.minor version 61.0。这个错误码61.0就是 JDK 17 的内部版本号。更隐蔽的问题是CPU 架构不匹配。现在越来越多的国产服务器如华为泰山、浪潮 K1 Power使用 ARM64 架构而你本地开发机是 Intel x86_64。如果你用mvn package打包时没有指定-Dmaven.compiler.source11 -Dmaven.compiler.target11Maven 默认会使用你本地 JDK 的字节码版本。结果就是一个在 x86_64 上能跑的 jar在 ARM64 服务器上会抛出java.lang.UnsatisfiedLinkError因为它内部依赖的某些 native 库比如net模块的底层实现是 x86_64 编译的ARM64 根本不认识。解决方法很简单永远在 CI/CD 流水线里用与生产环境完全一致的 JDK 和操作系统来构建 jar 包。如果你没有 CI/CD那么至少要确保你的开发机 JDK 版本 生产环境 JDK 版本并且架构一致。一个实用的技巧是在pom.xml的properties里显式声明java.version11/java.version maven.compiler.source11/maven.compiler.source maven.compiler.target11/maven.compiler.target这样无论你本地用什么 JDKMaven 都会强制按 JDK 11 的标准来编译。3.2 外置配置文件的“路径迷宫”SpringBoot 的application.yml或application.properties默认是打包在 jar 包内部的。但在生产环境我们绝不能把数据库密码、Redis 地址这些敏感信息硬编码在代码里。标准做法是使用外置配置。SpringBoot 提供了多种方式其中最常用、最灵活的是--spring.config.location参数。例如java -jar myapp.jar --spring.config.locationfile:/opt/myapp/config/application-prod.yml。这里的关键陷阱在于file:协议后面的路径。很多人会想当然地写成file:./config/application-prod.yml认为这是相对路径。但java -jar命令的“当前工作目录”Working Directory是它被执行时所在的目录而不是 jar 包所在的目录。这意味着如果你在/root目录下执行java -jar /opt/myapp/myapp.jar那么./config/就会去找/root/config/而不是/opt/myapp/config/。这是一个经典的“路径错位”问题。正确的做法是使用绝对路径或者利用 SpringBoot 的另一个特性--spring.config.additional-location。这个参数会将指定的配置文件作为“额外的”配置源与 jar 包内的默认配置进行合并且优先级更高。更重要的是它支持classpath:、file:、https:等多种协议而且file:后面的路径会被spring-boot-loader自动解析为相对于 jar 包所在目录的路径。所以更稳健的命令是java -jar /opt/myapp/myapp.jar --spring.config.additional-locationfile:./config/application-prod.yml。这里的./就是指/opt/myapp/这个目录。这个细节能帮你省下无数个ls -l和pwd的调试时间。3.3 端口与防火墙的“双重门禁”SpringBoot 默认监听8080端口但这只是应用层的“门”。在 Linux 服务器上还有操作系统层面的“门禁”——防火墙。CentOS 7 默认使用firewalldUbuntu 16.04 默认使用ufw。如果你只配置了 SpringBoot 的server.port8080却没有在防火墙里放行这个端口那么外部请求在到达你的 Java 进程之前就会被防火墙无情地丢弃。firewalld的放行命令是sudo firewall-cmd --permanent --add-port8080/tcp sudo firewall-cmd --reload。ufw的命令是sudo ufw allow 8080。但还有一个更隐蔽的“门禁”SELinux。这是 RedHat 系发行版如 CentOS、RHEL、国产麒麟特有的强制访问控制机制。它默认会阻止非标准端口上的网络连接。即使你的防火墙是开着的netstat -tuln | grep 8080也能看到进程在监听但curl依然超时。这时你需要检查 SELinux 状态sestatus。如果Current mode是enforcing那么你需要给 8080 端口打上一个 SELinux 标签sudo semanage port -a -t http_port_t -p tcp 8080。这个命令的意思是“告诉 SELinux8080 端口是用来跑 HTTP 服务的跟 80 端口享受同等待遇。” 这个步骤是很多从 Ubuntu 转战 CentOS 的开发者最容易忽略的“坑”。3.4 日志权限与磁盘空间的“慢性死亡”一个健康的服务必须有健康、可追溯的日志。但日志本身也会成为服务的“掘墓人”。最常见的两个问题一是日志文件权限错误。如果你用root用户启动了服务那么生成的日志文件如app.log的所有者就是root。当你后续想用普通用户比如appuser去tail -f app.log查看日志时会提示Permission denied。更糟的是如果你的systemd服务配置了Userappuser但日志文件是root创建的appuser就没有权限往里面写导致日志“静默丢失”。解决方案是在systemd的.service文件里明确指定User和Group并确保日志目录如/opt/myapp/logs/的权限属于该用户sudo chown -R appuser:appuser /opt/myapp/logs/。二是日志文件无限增长。很多开发者会把logging.file.name/opt/myapp/app.log直接写死这会导致日志文件越来越大最终撑爆磁盘。一个 50GB 的磁盘可能被一个没做轮转的日志文件在一天内占满。正确的做法是使用logging.file.path/opt/myapp/logs让 SpringBoot 自动创建带日期的滚动日志如spring.log.2024-06-15.0.gz并配合logback-spring.xml配置最大文件大小和保留天数。这才是一个生产级服务应有的日志素养。4. 实操过程详解手把手带你完成一个systemd方式的完整部署现在让我们把前面所有的理论落地为一次真实的、可复现的部署操作。我会以一个典型的 SpringBoot 2.7.x 项目为例目标是将其部署在一台全新的 CentOS 7 服务器上并通过systemd进行守护。整个过程我将模拟一个真实的工作流从环境准备到 jar 包上传再到服务配置与启动最后是 Nginx 反向代理。每一步我都会解释“为什么这么做”而不仅仅是“怎么做”。4.1 环境准备搭建一个干净、可控的“沙盒”首先SSH 登录你的 CentOS 7 服务器。不要用root用户直接操作这是安全大忌。我们先创建一个专用的部署用户# 创建用户组和用户 sudo groupadd springboot sudo useradd -m -g springboot -s /bin/bash appuser # 为 appuser 设置密码生产环境建议用密钥登录此处为演示简化 sudo passwd appuser # 将 appuser 加入 wheel 组以便后续使用 sudo sudo usermod -aG wheel appuser接下来安装并配置 JDK。我们选择 OpenJDK 11这是 SpringBoot 2.7.x 的官方推荐版本。# 更新系统 sudo yum update -y # 安装 OpenJDK 11 sudo yum install -y java-11-openjdk-devel # 验证安装 java -version # 输出应为openjdk version 11.0.x ...然后创建项目目录结构。一个规范的部署目录应该清晰地分离代码、配置、日志和数据# 切换到 appuser 用户 su - appuser # 创建主目录 mkdir -p /opt/myapp/{lib,config,logs,data} # lib 目录存放 jar 包 # config 目录存放外置配置文件 # logs 目录存放日志文件 # data 目录存放应用产生的数据文件如上传的图片 # 设置目录权限 sudo chown -R appuser:springboot /opt/myapp sudo chmod -R 755 /opt/myapp这个步骤看似繁琐但它建立了一个清晰、安全、可审计的部署基线。每一个目录的用途都一目了然权限也恰到好处既保证了appuser的操作自由又防止了越权访问。4.2 配置文件准备让应用“知道”自己身处何方现在我们需要为生产环境准备一个application-prod.yml。这个文件应该放在/opt/myapp/config/目录下。内容如下请根据你的实际环境修改# /opt/myapp/config/application-prod.yml spring: profiles: active: prod datasource: url: jdbc:mysql://127.0.0.1:3306/myapp?useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: myapp_user password: your_secure_password driver-class-name: com.mysql.cj.jdbc.Driver redis: host: 127.0.0.1 port: 6379 password: your_redis_password server: port: 8080 servlet: context-path: /myapp logging: level: root: INFO com.mycompany: DEBUG file: path: /opt/myapp/logs注意几个关键点server.servlet.context-path设置了上下文路径这在 Nginx 反向代理时至关重要logging.file.path指向了我们之前创建的logs目录所有敏感信息数据库密码、Redis 密码都已填写。切记这个文件的权限必须是600只有所有者可读写否则会有严重的安全风险。执行chmod 600 /opt/myapp/config/application-prod.yml。4.3 systemd 服务单元文件编写你的“部署说明书”这是整个部署过程中最核心的一步。我们创建一个systemd服务单元文件它将定义你的应用如何被操作系统管理。文件路径为/etc/systemd/system/myapp.service# /etc/systemd/system/myapp.service [Unit] DescriptionMy SpringBoot Application Documentationhttps://mycompany.com/docs/myapp Afternetwork.target [Service] Typesimple Userappuser Groupspringboot WorkingDirectory/opt/myapp # 关键指定 JDK 路径避免系统 PATH 污染 EnvironmentJAVA_HOME/usr/lib/jvm/java-11-openjdk-11.0.x.x-0.el7_9.x86_64 EnvironmentPATH/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin # 启动命令指定 profile 和外置配置 ExecStart/usr/bin/java -Xms512m -Xmx1024m -jar /opt/myapp/lib/myapp.jar --spring.profiles.activeprod --spring.config.additional-locationfile:/opt/myapp/config/ # 重启策略 Restartalways RestartSec10 # 健康检查如果进程在 30 秒内没有响应视为失败 TimeoutStartSec30 # 标准输出和错误输出重定向到 journald StandardOutputjournal StandardErrorjournal # 限制内存使用防止 OOM 影响其他服务 MemoryLimit1536M [Install] WantedBymulti-user.target这个文件的每一行都有其深意。Environment确保了 JDK 路径的绝对准确ExecStart使用了--spring.config.additional-location这是我们前面强调过的、最可靠的外置配置方式Restartalways和RestartSec10构成了强大的守护机制MemoryLimit是一个保险丝当你的应用内存泄漏时systemd会主动将其杀死而不是让它拖垮整台服务器。创建完文件后重新加载systemd配置sudo systemctl daemon-reload4.4 启动与验证从“启动成功”到“服务可用”的完整闭环现在我们可以启动服务了# 启动服务 sudo systemctl start myapp # 设置开机自启 sudo systemctl enable myapp # 检查服务状态 sudo systemctl status myappsystemctl status的输出是你判断服务是否“真正健康”的第一道关卡。它会显示Active: active (running)并且下面会列出最近的几行日志。如果看到Failed to start或failed字样说明启动失败你需要立即用journalctl查看详细日志# 查看实时日志 sudo journalctl -u myapp -f # 查看最近 100 行日志 sudo journalctl -u myapp -n 100如果一切顺利你应该能在日志里看到类似Started My SpringBoot Application和Tomcat started on port(s): 8080 (http)的字样。此时服务已经在8080端口监听。但别急着庆祝这只是“应用层”可用。我们还需要验证“网络层”是否通畅# 在服务器本地用 curl 测试 curl -I http://localhost:8080/myapp/actuator/health # 应该返回 HTTP/1.1 200 OK # 检查端口监听 sudo netstat -tuln | grep :8080 # 检查防火墙 sudo firewall-cmd --list-ports | grep 8080如果curl成功但外部网络比如你的公司电脑访问不了那一定是防火墙没放行。执行sudo firewall-cmd --permanent --add-port8080/tcp sudo firewall-cmd --reload即可。4.5 Nginx 反向代理为你的服务披上“生产级外衣”最后一步是用 Nginx 把8080端口“藏”起来并提供一个友好的域名访问入口。首先安装 Nginxsudo yum install -y nginx sudo systemctl start nginx sudo systemctl enable nginx然后创建 Nginx 的虚拟主机配置文件/etc/nginx/conf.d/myapp.conf# /etc/nginx/conf.d/myapp.conf upstream myapp_backend { server 127.0.0.1:8080; } server { listen 80; server_name myapp.example.com; # 替换为你的域名 # 将所有请求代理到上游 location / { proxy_pass http://myapp_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 传递 WebSocket 连接如果应用用到了 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } # 静态资源缓存如果应用有前端 location /static/ { alias /opt/myapp/static/; expires 1h; } }这个配置的核心思想是Nginx 作为“门卫”监听80端口接收所有来自myapp.example.com的请求然后把它们“转发”给127.0.0.1:8080上的真实 SpringBoot 应用。proxy_set_header系列指令是为了让后端应用能获取到真实的客户端 IP 和协议类型HTTP/HTTPS这对于日志记录和安全审计至关重要。配置完成后测试并重载 Nginx# 测试配置语法 sudo nginx -t # 重载配置 sudo systemctl reload nginx至此整个部署流程完成。你的 SpringBoot 应用已经通过systemd守护、firewalld保护、Nginx代理成为一个符合生产环境标准的、稳定、安全、可维护的服务。5. 常见问题与排查技巧实录那些年我在生产环境踩过的坑部署从来不是一帆风顺的。以下是我和我的团队在过去十年里在数十个不同客户、不同行业的生产环境中反复遇到、反复解决的典型问题。我把它们整理成一张速查表并附上了独家的、教科书里找不到的排查技巧。问题现象可能原因排查命令/技巧独家心得systemctl status myapp显示failed但journalctl里没有有效日志systemd的StandardOutput和StandardError没有正确重定向或者应用启动太快就崩溃了日志还没来得及刷到journald1. 先用sudo journalctl -u myapp --no-pager -n 100查看最新 100 行加--no-pager避免分页干扰。2. 如果还是空改用最原始的方法sudo -u appuser /usr/bin/java -jar /opt/myapp/lib/myapp.jar --spring.profiles.activeprod --spring.config.additional-locationfile:/opt/myapp/config/ 21 | head -50直接在前台运行把所有输出包括错误都打印到屏幕上。这是排查“启动即崩溃”问题的黄金法则。systemd的日志缓冲区有时会丢掉最开头的几行错误而前台运行则能捕获一切。curl http://localhost:8080返回Connection refused但netstat确实显示8080端口在监听SpringBoot 的server.address配置被设为了127.0.0.1导致它只监听本地回环地址不监听0.0.0.0所有网卡sudo ss -tuln | grep :8080。ss比netstat更快更准。如果输出是127.0.0.1:8080那就证实了问题。解决方案在application-prod.yml中添加server.address: 0.0.0.0。server.address是一个极易被忽略的配置项。它的默认值是0.0.0.0但很多开发者为了“安全”会手动改成127.0.0.1结果在部署时把自己坑了。记住127.0.0.1是“只给自己看”0.0.0.0才是“欢迎所有人”。Nginx 代理后应用里的HttpServletRequest.getRemoteAddr()获取到的 IP 总是127.0.0.1Nginx 没有正确设置X-Real-IP和X-Forwarded-For请求头或者 SpringBoot 应用没有配置信任的代理 IP1. 在 Nginx 配置里确认proxy_set_header X-Real-IP $remote_addr;已存在。2. 在 SpringBoot 的application-prod.yml中添加server.forward-headers-strategy: nativeSpringBoot 2.6或server.tomcat.remoteip.remote-ip-header: x-forwarded-for旧版。这个问题直接影响风控、限流、日志分析等所有依赖真实 IP 的功能。forward-headers-strategy: native是 SpringBoot 2.6 引入的新配置它会自动识别并信任X-Forwarded-*头比手动配置remoteip更简洁、更安全。应用启动后数据库连接失败日志里报Access denied for user myapp_userlocalhostMySQL 的用户权限是基于host字段的。myapp_userlocalhost只允许从localhost即 Unix socket连接而 SpringBoot 通过127.0.0.1连接时MySQL 会将其视为myapp_user127.0.0.1这是一个不同的用户mysql -u root -p -e SELECT User,Host FROM mysql.user;。如果只看到myapp_userlocalhost那就需要创建myapp_user127.0.0.1。执行CREATE USER myapp_user127.0.0.1 IDENTIFIED BY password; GRANT ALL PRIVILEGES ON myapp.* TO myapp_user127.0.0.1; FLUSH PRIVILEGES;MySQL 的localhost和127.0.0.1是两个完全不同的 host这是 MySQL 的一个历史遗留设计。很多 DBA 都会犯这个错误以为创建了localhost用户就万事大吉了。除了以上表格我还想分享一个贯穿始终的终极排查心法永远相信日志但永远要验证日志的来源。systemd的日志、Nginx 的access.log、SpringBoot 的app.log它们构成了一个完整的调用链。当问题出现时不要只盯着一个日志看。要像侦探一样从客户端发起请求开始顺着Nginx access.log - Nginx error.log - SpringBoot app.log - systemd journal这条链路一级一级地追踪。很多时候真相就藏在Nginx error.log里一行被忽略的upstream timed out或者systemd journal里一条被淹没的Out of memory。这种系统性的、链条式的排查思维比任何具体的命令都重要。它不是一个技巧而是一种职业习惯是区分一个“能干活的工程师”和一个“能解决问题的工程师”的关键分水岭。6. 运维与监控让部署不是终点而是服务生命周期的起点部署完成服务上线这绝不是故事的结束而恰恰是服务生命周期管理的真正开始。一个只“能跑”却“看不见、管不住、救不
1. 项目概述为什么“Linux 部署 SpringBoot 项目”是每个后端工程师绕不开的硬技能你手头刚写完一个功能完整的 SpringBoot 项目本地mvn clean package打出一个xxx.jar双击或者java -jar xxx.jar一跑浏览器打开http://localhost:8080页面秒开心里美滋滋。但当你把 jar 包传到公司那台崭新的 CentOS 服务器上敲下java -jar xxx.jar然后满怀期待地在公司电脑上输入服务器 IP 加端口——页面打不开连curl -I http://server-ip:8080都返回Connection refused。这时候你才真正意识到写完代码只是万里长征第一步让代码在生产环境里稳稳当当地跑起来才是检验一个工程师是否成熟的分水岭。这就是“Linux 部署 SpringBoot 项目”的真实意义。它不是教你怎么写 Hello World而是教你如何把一个开发态的、依赖 IDE 和本地环境的 Java 应用变成一个生产态的、能扛住并发、能自动恢复、能被监控、能被运维团队一眼看懂的“服务”。这个标题背后藏着至少三层硬核需求。第一层是环境适配你的开发机可能是 macOS 或 WindowsJDK 版本是 17Maven 是 3.9而生产服务器大概率是 CentOS 7/8、Ubuntu 20.04 或国产麒麟、统信系统JDK 可能是 OpenJDK 11甚至还要考虑 ARM64 架构比如华为鲲鹏、飞腾 CPU。第二层是进程守护java -jar命令在终端里一执行你关掉 SSH 连接进程就跟着挂了。生产环境要求服务 7x24 小时在线这需要systemd或supervisord这类进程管理器来拉起、监控、重启。第三层是网络暴露与安全直接把 SpringBoot 的 8080 端口暴露在公网上这是运维大忌。必须通过 Nginx 做反向代理隐藏真实端口统一处理 HTTPS、静态资源、负载均衡甚至 WAF 防护。所以当你看到“Linux 部署 SpringBoot 项目”这个标题它本质上是在问“我如何把一个开发玩具变成一个能放进生产环境货架里的工业品” 这个问题的答案决定了你写的代码是“能跑”还是“敢上线”。它适合所有刚从校园走向职场的 Java 初级工程师也适合那些常年在 SpringCloud 微服务里摸爬滚打、却对单体应用部署细节已经生疏的中高级开发者。因为无论架构多复杂最底层的那个服务实例终究要落在一台 Linux 机器上靠java命令启动。掌握它你就拿到了进入生产环境的那把钥匙。2. 核心思路拆解从“能跑”到“稳跑”的四条技术路径与选型逻辑面对一个.jar包摆在你面前的不是一条路而是四条截然不同、各有利弊的技术路径。选择哪一条不取决于哪个“听起来更酷”而取决于你当前所处的阶段、团队的技术栈和项目的实际规模。我干了十多年运维和 DevOps见过太多人因为选错路在项目上线前一周疯狂踩坑。2.1 路径一最原始的java -jarnohup新手入门临时验证这是所有人的起点也是最脆弱的一条路。核心命令就一句nohup java -jar myapp.jar app.log 21 。它的逻辑极其简单nohup让进程忽略SIGHUP信号即 SSH 断开信号重定向标准输出到日志文件21把错误输出也合并进去最后的让它在后台运行。优点是零学习成本三秒上手适合你第一次把 jar 包扔到测试服务器上快速验证“它到底能不能跑起来”。但它的致命缺陷在于“无守护”。如果 JVM 因为 OOM 崩溃了或者你的代码里有个未捕获的RuntimeException进程会直接退出而nohup不会管它死活也不会尝试重启。你第二天早上来上班发现服务挂了一夜日志里只有一行java.lang.OutOfMemoryError: Java heap space然后开始漫长的排查。所以这条路径的定位非常清晰仅限于五分钟内的快速验证绝不允许出现在任何预发布或生产环境。我见过最惨的案例是一个创业公司的 MVP 产品就用nohup跑在一台阿里云 ECS 上结果某天凌晨内存泄漏服务挂了老板早上六点打电话过来整个技术团队手忙脚乱花了两小时才恢复。这种“裸奔”式部署代价远高于你花十分钟配置一个systemd服务。2.2 路径二systemd守护服务生产环境事实标准推荐首选systemd是现代 Linux 发行版CentOS 7、Ubuntu 16.04的默认初始化系统它早已不是简单的“开机自启”工具而是一个功能完备的进程生命周期管理器。选择systemd是因为它解决了nohup的所有痛点并且与操作系统深度集成。它的核心优势有三点一是强健的进程守护。你可以配置Restartalways只要进程退出systemd就会立刻拉起一个新的还可以配置RestartSec10每次重启前等待 10 秒避免进程反复崩溃导致的“雪崩”二是精准的依赖管理。你可以声明Afternetwork.target确保网络服务启动完成后再启动你的应用三是标准化的日志与状态查询。所有systemd管理的服务日志都统一由journalctl收集journalctl -u myapp.service -f就能实时查看再也不用满/var/log目录去翻.log文件。更重要的是systemd的配置文件.service文件本身就是一份清晰的“部署说明书”它明明白白地告诉你这个服务用了什么 JDK、什么参数、监听什么端口、以什么用户身份运行。这对于团队协作和后续的审计、交接价值巨大。所以如果你的服务器是较新的发行版systemd是我毫无保留的首选。它不是最炫的但它是“最稳的”是经过千万次生产环境锤炼出来的可靠方案。2.3 路径三Docker 容器化微服务与云原生基石中长期必学Docker 的本质是给你的 SpringBoot 应用套上一个“标准化的集装箱”。它把你的 jar 包、JDK、甚至 Linux 内核的特定版本全部打包进一个镜像里。这样你在开发机上构建的镜像和在生产服务器上运行的镜像保证是 100% 一致的。这彻底消灭了“在我机器上是好的”这类经典甩锅话术。Docker 的部署流程是先写一个Dockerfile里面定义好基础镜像如openjdk:11-jre-slim、复制 jar 包、暴露端口然后docker build -t myapp .构建镜像最后docker run -d --name myapp -p 8080:8080 myapp启动容器。它的优势在于环境一致性和可移植性。一个 Docker 镜像可以无缝地从你的笔记本跑到腾讯云的 CVM再跑到阿里云的 ACK 集群甚至跑到边缘计算设备上完全不需要关心底层 OS 的差异。这也是为什么所有云厂商都在力推容器服务。但它的学习曲线比systemd更陡峭。你需要理解镜像分层、数据卷挂载、网络模式bridge/host、以及如何安全地管理敏感配置如数据库密码。对于一个只有单体应用、且没有专职运维的小团队过早引入 Docker可能会把简单问题复杂化。我的建议是把它当作一项“中长期投资”。当你开始规划微服务拆分或者准备上云Docker 就不再是可选项而是必选项。2.4 路径四宝塔面板等可视化工具小白友好但需警惕“黑盒陷阱”宝塔面板这类工具把systemd、Nginx、MySQL 等所有操作都封装成了图形界面的按钮。你只需要上传 jar 包点几下鼠标填几个表单服务就起来了。这对完全没有 Linux 基础的开发者简直是福音。它极大地降低了入门门槛让你能把精力集中在业务代码上。然而正如此前论坛里大量用户的吐槽所揭示的这种“傻瓜式”操作背后是一个巨大的“黑盒陷阱”。当你点击“一键部署”后宝塔在后台究竟做了什么它创建了哪个systemd服务它生成的 Nginx 配置文件在哪里它用的是哪个 JDK 版本这些关键信息都被隐藏在了图形界面之下。一旦服务出了问题比如端口冲突、配置文件加载失败、或者升级后功能异常你就会陷入一种“看得见、摸不着”的绝望境地。因为你无法像调试代码一样去逐行检查部署脚本。你只能在界面上点来点去或者去翻那些被宝塔自动生成、格式混乱、注释缺失的配置文件。所以我的经验是宝塔可以作为你学习的“脚手架”但绝不能成为你生产的“拐杖”。我建议的正确用法是先用宝塔快速部署一个 demo然后立刻 SSH 登录服务器找到它生成的所有配置文件通常在/www/server/panel/vhost/和/www/wwwroot/下把它们全部拷贝出来一行一行地读搞懂每一行的作用。当你把宝塔背后的“黑盒”全部拆解成白盒之后你就可以自信地抛弃它转而用纯命令行的方式进行部署和维护。这才是技术成长的正道。3. 核心细节解析SpringBoot 部署中那些“不起眼”却致命的细节很多工程师在部署时会把注意力全部放在“怎么启动”这个动作上却忽略了启动之前和启动过程中那些决定成败的“毛细血管”级细节。这些细节往往不会在报错日志里直接体现但会让你在排查问题时耗费数小时甚至数天。3.1 JDK 版本与架构的“隐形杀手”SpringBoot 项目对 JDK 的版本有严格要求。一个用 SpringBoot 2.7.x 开发的项目其pom.xml中spring-boot-starter-parent的版本决定了它编译时使用的 JDK 特性。如果你在开发机上用 JDK 17 编译然后把 jar 包扔到一台只装了 OpenJDK 8 的 CentOS 7 服务器上java -jar命令会直接报错Unsupported major.minor version 61.0。这个错误码61.0就是 JDK 17 的内部版本号。更隐蔽的问题是CPU 架构不匹配。现在越来越多的国产服务器如华为泰山、浪潮 K1 Power使用 ARM64 架构而你本地开发机是 Intel x86_64。如果你用mvn package打包时没有指定-Dmaven.compiler.source11 -Dmaven.compiler.target11Maven 默认会使用你本地 JDK 的字节码版本。结果就是一个在 x86_64 上能跑的 jar在 ARM64 服务器上会抛出java.lang.UnsatisfiedLinkError因为它内部依赖的某些 native 库比如net模块的底层实现是 x86_64 编译的ARM64 根本不认识。解决方法很简单永远在 CI/CD 流水线里用与生产环境完全一致的 JDK 和操作系统来构建 jar 包。如果你没有 CI/CD那么至少要确保你的开发机 JDK 版本 生产环境 JDK 版本并且架构一致。一个实用的技巧是在pom.xml的properties里显式声明java.version11/java.version maven.compiler.source11/maven.compiler.source maven.compiler.target11/maven.compiler.target这样无论你本地用什么 JDKMaven 都会强制按 JDK 11 的标准来编译。3.2 外置配置文件的“路径迷宫”SpringBoot 的application.yml或application.properties默认是打包在 jar 包内部的。但在生产环境我们绝不能把数据库密码、Redis 地址这些敏感信息硬编码在代码里。标准做法是使用外置配置。SpringBoot 提供了多种方式其中最常用、最灵活的是--spring.config.location参数。例如java -jar myapp.jar --spring.config.locationfile:/opt/myapp/config/application-prod.yml。这里的关键陷阱在于file:协议后面的路径。很多人会想当然地写成file:./config/application-prod.yml认为这是相对路径。但java -jar命令的“当前工作目录”Working Directory是它被执行时所在的目录而不是 jar 包所在的目录。这意味着如果你在/root目录下执行java -jar /opt/myapp/myapp.jar那么./config/就会去找/root/config/而不是/opt/myapp/config/。这是一个经典的“路径错位”问题。正确的做法是使用绝对路径或者利用 SpringBoot 的另一个特性--spring.config.additional-location。这个参数会将指定的配置文件作为“额外的”配置源与 jar 包内的默认配置进行合并且优先级更高。更重要的是它支持classpath:、file:、https:等多种协议而且file:后面的路径会被spring-boot-loader自动解析为相对于 jar 包所在目录的路径。所以更稳健的命令是java -jar /opt/myapp/myapp.jar --spring.config.additional-locationfile:./config/application-prod.yml。这里的./就是指/opt/myapp/这个目录。这个细节能帮你省下无数个ls -l和pwd的调试时间。3.3 端口与防火墙的“双重门禁”SpringBoot 默认监听8080端口但这只是应用层的“门”。在 Linux 服务器上还有操作系统层面的“门禁”——防火墙。CentOS 7 默认使用firewalldUbuntu 16.04 默认使用ufw。如果你只配置了 SpringBoot 的server.port8080却没有在防火墙里放行这个端口那么外部请求在到达你的 Java 进程之前就会被防火墙无情地丢弃。firewalld的放行命令是sudo firewall-cmd --permanent --add-port8080/tcp sudo firewall-cmd --reload。ufw的命令是sudo ufw allow 8080。但还有一个更隐蔽的“门禁”SELinux。这是 RedHat 系发行版如 CentOS、RHEL、国产麒麟特有的强制访问控制机制。它默认会阻止非标准端口上的网络连接。即使你的防火墙是开着的netstat -tuln | grep 8080也能看到进程在监听但curl依然超时。这时你需要检查 SELinux 状态sestatus。如果Current mode是enforcing那么你需要给 8080 端口打上一个 SELinux 标签sudo semanage port -a -t http_port_t -p tcp 8080。这个命令的意思是“告诉 SELinux8080 端口是用来跑 HTTP 服务的跟 80 端口享受同等待遇。” 这个步骤是很多从 Ubuntu 转战 CentOS 的开发者最容易忽略的“坑”。3.4 日志权限与磁盘空间的“慢性死亡”一个健康的服务必须有健康、可追溯的日志。但日志本身也会成为服务的“掘墓人”。最常见的两个问题一是日志文件权限错误。如果你用root用户启动了服务那么生成的日志文件如app.log的所有者就是root。当你后续想用普通用户比如appuser去tail -f app.log查看日志时会提示Permission denied。更糟的是如果你的systemd服务配置了Userappuser但日志文件是root创建的appuser就没有权限往里面写导致日志“静默丢失”。解决方案是在systemd的.service文件里明确指定User和Group并确保日志目录如/opt/myapp/logs/的权限属于该用户sudo chown -R appuser:appuser /opt/myapp/logs/。二是日志文件无限增长。很多开发者会把logging.file.name/opt/myapp/app.log直接写死这会导致日志文件越来越大最终撑爆磁盘。一个 50GB 的磁盘可能被一个没做轮转的日志文件在一天内占满。正确的做法是使用logging.file.path/opt/myapp/logs让 SpringBoot 自动创建带日期的滚动日志如spring.log.2024-06-15.0.gz并配合logback-spring.xml配置最大文件大小和保留天数。这才是一个生产级服务应有的日志素养。4. 实操过程详解手把手带你完成一个systemd方式的完整部署现在让我们把前面所有的理论落地为一次真实的、可复现的部署操作。我会以一个典型的 SpringBoot 2.7.x 项目为例目标是将其部署在一台全新的 CentOS 7 服务器上并通过systemd进行守护。整个过程我将模拟一个真实的工作流从环境准备到 jar 包上传再到服务配置与启动最后是 Nginx 反向代理。每一步我都会解释“为什么这么做”而不仅仅是“怎么做”。4.1 环境准备搭建一个干净、可控的“沙盒”首先SSH 登录你的 CentOS 7 服务器。不要用root用户直接操作这是安全大忌。我们先创建一个专用的部署用户# 创建用户组和用户 sudo groupadd springboot sudo useradd -m -g springboot -s /bin/bash appuser # 为 appuser 设置密码生产环境建议用密钥登录此处为演示简化 sudo passwd appuser # 将 appuser 加入 wheel 组以便后续使用 sudo sudo usermod -aG wheel appuser接下来安装并配置 JDK。我们选择 OpenJDK 11这是 SpringBoot 2.7.x 的官方推荐版本。# 更新系统 sudo yum update -y # 安装 OpenJDK 11 sudo yum install -y java-11-openjdk-devel # 验证安装 java -version # 输出应为openjdk version 11.0.x ...然后创建项目目录结构。一个规范的部署目录应该清晰地分离代码、配置、日志和数据# 切换到 appuser 用户 su - appuser # 创建主目录 mkdir -p /opt/myapp/{lib,config,logs,data} # lib 目录存放 jar 包 # config 目录存放外置配置文件 # logs 目录存放日志文件 # data 目录存放应用产生的数据文件如上传的图片 # 设置目录权限 sudo chown -R appuser:springboot /opt/myapp sudo chmod -R 755 /opt/myapp这个步骤看似繁琐但它建立了一个清晰、安全、可审计的部署基线。每一个目录的用途都一目了然权限也恰到好处既保证了appuser的操作自由又防止了越权访问。4.2 配置文件准备让应用“知道”自己身处何方现在我们需要为生产环境准备一个application-prod.yml。这个文件应该放在/opt/myapp/config/目录下。内容如下请根据你的实际环境修改# /opt/myapp/config/application-prod.yml spring: profiles: active: prod datasource: url: jdbc:mysql://127.0.0.1:3306/myapp?useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: myapp_user password: your_secure_password driver-class-name: com.mysql.cj.jdbc.Driver redis: host: 127.0.0.1 port: 6379 password: your_redis_password server: port: 8080 servlet: context-path: /myapp logging: level: root: INFO com.mycompany: DEBUG file: path: /opt/myapp/logs注意几个关键点server.servlet.context-path设置了上下文路径这在 Nginx 反向代理时至关重要logging.file.path指向了我们之前创建的logs目录所有敏感信息数据库密码、Redis 密码都已填写。切记这个文件的权限必须是600只有所有者可读写否则会有严重的安全风险。执行chmod 600 /opt/myapp/config/application-prod.yml。4.3 systemd 服务单元文件编写你的“部署说明书”这是整个部署过程中最核心的一步。我们创建一个systemd服务单元文件它将定义你的应用如何被操作系统管理。文件路径为/etc/systemd/system/myapp.service# /etc/systemd/system/myapp.service [Unit] DescriptionMy SpringBoot Application Documentationhttps://mycompany.com/docs/myapp Afternetwork.target [Service] Typesimple Userappuser Groupspringboot WorkingDirectory/opt/myapp # 关键指定 JDK 路径避免系统 PATH 污染 EnvironmentJAVA_HOME/usr/lib/jvm/java-11-openjdk-11.0.x.x-0.el7_9.x86_64 EnvironmentPATH/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin # 启动命令指定 profile 和外置配置 ExecStart/usr/bin/java -Xms512m -Xmx1024m -jar /opt/myapp/lib/myapp.jar --spring.profiles.activeprod --spring.config.additional-locationfile:/opt/myapp/config/ # 重启策略 Restartalways RestartSec10 # 健康检查如果进程在 30 秒内没有响应视为失败 TimeoutStartSec30 # 标准输出和错误输出重定向到 journald StandardOutputjournal StandardErrorjournal # 限制内存使用防止 OOM 影响其他服务 MemoryLimit1536M [Install] WantedBymulti-user.target这个文件的每一行都有其深意。Environment确保了 JDK 路径的绝对准确ExecStart使用了--spring.config.additional-location这是我们前面强调过的、最可靠的外置配置方式Restartalways和RestartSec10构成了强大的守护机制MemoryLimit是一个保险丝当你的应用内存泄漏时systemd会主动将其杀死而不是让它拖垮整台服务器。创建完文件后重新加载systemd配置sudo systemctl daemon-reload4.4 启动与验证从“启动成功”到“服务可用”的完整闭环现在我们可以启动服务了# 启动服务 sudo systemctl start myapp # 设置开机自启 sudo systemctl enable myapp # 检查服务状态 sudo systemctl status myappsystemctl status的输出是你判断服务是否“真正健康”的第一道关卡。它会显示Active: active (running)并且下面会列出最近的几行日志。如果看到Failed to start或failed字样说明启动失败你需要立即用journalctl查看详细日志# 查看实时日志 sudo journalctl -u myapp -f # 查看最近 100 行日志 sudo journalctl -u myapp -n 100如果一切顺利你应该能在日志里看到类似Started My SpringBoot Application和Tomcat started on port(s): 8080 (http)的字样。此时服务已经在8080端口监听。但别急着庆祝这只是“应用层”可用。我们还需要验证“网络层”是否通畅# 在服务器本地用 curl 测试 curl -I http://localhost:8080/myapp/actuator/health # 应该返回 HTTP/1.1 200 OK # 检查端口监听 sudo netstat -tuln | grep :8080 # 检查防火墙 sudo firewall-cmd --list-ports | grep 8080如果curl成功但外部网络比如你的公司电脑访问不了那一定是防火墙没放行。执行sudo firewall-cmd --permanent --add-port8080/tcp sudo firewall-cmd --reload即可。4.5 Nginx 反向代理为你的服务披上“生产级外衣”最后一步是用 Nginx 把8080端口“藏”起来并提供一个友好的域名访问入口。首先安装 Nginxsudo yum install -y nginx sudo systemctl start nginx sudo systemctl enable nginx然后创建 Nginx 的虚拟主机配置文件/etc/nginx/conf.d/myapp.conf# /etc/nginx/conf.d/myapp.conf upstream myapp_backend { server 127.0.0.1:8080; } server { listen 80; server_name myapp.example.com; # 替换为你的域名 # 将所有请求代理到上游 location / { proxy_pass http://myapp_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 传递 WebSocket 连接如果应用用到了 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } # 静态资源缓存如果应用有前端 location /static/ { alias /opt/myapp/static/; expires 1h; } }这个配置的核心思想是Nginx 作为“门卫”监听80端口接收所有来自myapp.example.com的请求然后把它们“转发”给127.0.0.1:8080上的真实 SpringBoot 应用。proxy_set_header系列指令是为了让后端应用能获取到真实的客户端 IP 和协议类型HTTP/HTTPS这对于日志记录和安全审计至关重要。配置完成后测试并重载 Nginx# 测试配置语法 sudo nginx -t # 重载配置 sudo systemctl reload nginx至此整个部署流程完成。你的 SpringBoot 应用已经通过systemd守护、firewalld保护、Nginx代理成为一个符合生产环境标准的、稳定、安全、可维护的服务。5. 常见问题与排查技巧实录那些年我在生产环境踩过的坑部署从来不是一帆风顺的。以下是我和我的团队在过去十年里在数十个不同客户、不同行业的生产环境中反复遇到、反复解决的典型问题。我把它们整理成一张速查表并附上了独家的、教科书里找不到的排查技巧。问题现象可能原因排查命令/技巧独家心得systemctl status myapp显示failed但journalctl里没有有效日志systemd的StandardOutput和StandardError没有正确重定向或者应用启动太快就崩溃了日志还没来得及刷到journald1. 先用sudo journalctl -u myapp --no-pager -n 100查看最新 100 行加--no-pager避免分页干扰。2. 如果还是空改用最原始的方法sudo -u appuser /usr/bin/java -jar /opt/myapp/lib/myapp.jar --spring.profiles.activeprod --spring.config.additional-locationfile:/opt/myapp/config/ 21 | head -50直接在前台运行把所有输出包括错误都打印到屏幕上。这是排查“启动即崩溃”问题的黄金法则。systemd的日志缓冲区有时会丢掉最开头的几行错误而前台运行则能捕获一切。curl http://localhost:8080返回Connection refused但netstat确实显示8080端口在监听SpringBoot 的server.address配置被设为了127.0.0.1导致它只监听本地回环地址不监听0.0.0.0所有网卡sudo ss -tuln | grep :8080。ss比netstat更快更准。如果输出是127.0.0.1:8080那就证实了问题。解决方案在application-prod.yml中添加server.address: 0.0.0.0。server.address是一个极易被忽略的配置项。它的默认值是0.0.0.0但很多开发者为了“安全”会手动改成127.0.0.1结果在部署时把自己坑了。记住127.0.0.1是“只给自己看”0.0.0.0才是“欢迎所有人”。Nginx 代理后应用里的HttpServletRequest.getRemoteAddr()获取到的 IP 总是127.0.0.1Nginx 没有正确设置X-Real-IP和X-Forwarded-For请求头或者 SpringBoot 应用没有配置信任的代理 IP1. 在 Nginx 配置里确认proxy_set_header X-Real-IP $remote_addr;已存在。2. 在 SpringBoot 的application-prod.yml中添加server.forward-headers-strategy: nativeSpringBoot 2.6或server.tomcat.remoteip.remote-ip-header: x-forwarded-for旧版。这个问题直接影响风控、限流、日志分析等所有依赖真实 IP 的功能。forward-headers-strategy: native是 SpringBoot 2.6 引入的新配置它会自动识别并信任X-Forwarded-*头比手动配置remoteip更简洁、更安全。应用启动后数据库连接失败日志里报Access denied for user myapp_userlocalhostMySQL 的用户权限是基于host字段的。myapp_userlocalhost只允许从localhost即 Unix socket连接而 SpringBoot 通过127.0.0.1连接时MySQL 会将其视为myapp_user127.0.0.1这是一个不同的用户mysql -u root -p -e SELECT User,Host FROM mysql.user;。如果只看到myapp_userlocalhost那就需要创建myapp_user127.0.0.1。执行CREATE USER myapp_user127.0.0.1 IDENTIFIED BY password; GRANT ALL PRIVILEGES ON myapp.* TO myapp_user127.0.0.1; FLUSH PRIVILEGES;MySQL 的localhost和127.0.0.1是两个完全不同的 host这是 MySQL 的一个历史遗留设计。很多 DBA 都会犯这个错误以为创建了localhost用户就万事大吉了。除了以上表格我还想分享一个贯穿始终的终极排查心法永远相信日志但永远要验证日志的来源。systemd的日志、Nginx 的access.log、SpringBoot 的app.log它们构成了一个完整的调用链。当问题出现时不要只盯着一个日志看。要像侦探一样从客户端发起请求开始顺着Nginx access.log - Nginx error.log - SpringBoot app.log - systemd journal这条链路一级一级地追踪。很多时候真相就藏在Nginx error.log里一行被忽略的upstream timed out或者systemd journal里一条被淹没的Out of memory。这种系统性的、链条式的排查思维比任何具体的命令都重要。它不是一个技巧而是一种职业习惯是区分一个“能干活的工程师”和一个“能解决问题的工程师”的关键分水岭。6. 运维与监控让部署不是终点而是服务生命周期的起点部署完成服务上线这绝不是故事的结束而恰恰是服务生命周期管理的真正开始。一个只“能跑”却“看不见、管不住、救不
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
