1. 公网部署不是“发个jar包就完事”先搞清你真正要解决的问题很多人搜“java项目部署到公网教程”点开就急着复制粘贴命令结果卡在第一步——连服务器都连不上。我带过十几支小团队90%的新手在部署前根本没想清楚你到底需要什么样的公网访问是给老板演示用的临时链接是给客户用的正式服务还是自己在家调试的个人项目这三类需求技术路径、成本结构、安全策略全都不一样。举个最典型的例子上周一个做校园二手书平台的大学生找我帮忙说“部署失败”。我问他“你希望谁访问”他说“同学扫码就能用”。我再问“你有云服务器吗”他说没有只有一台家里闲置的笔记本。这时候如果按常规教程教他买阿里云ECS、配Nginx反向代理、申请SSL证书……纯属浪费时间。他真正需要的是一条能绕过家庭宽带无公网IP限制、5分钟内让同学扫码访问的链路——这和企业级生产部署完全是两套逻辑。关键词里反复出现的“家庭公网”“没有公网ip教程”“xtcp必须要有公网ip吗”恰恰暴露了当前最大的认知断层把“部署”等同于“上线”把“上线”等同于“买云服务器”。实际上Java项目暴露到公网本质是解决“网络可达性”问题而实现路径至少有四条主干道真公网IP直连运营商分配的独立IPv4地址端口可直接映射但国内家庭宽带基本绝迹云服务器中转租用VPS项目跑在云上通过域名HTTPS对外提供服务最主流但有月付成本P2P穿透方案如Tailscale、ZeroTier、EasyTier不依赖公网IP靠中继节点建立加密隧道适合开发测试、小范围共享反向代理隧道如frp、ngrok、localtunnel本地服务主动连接公网服务器由其代为转发请求免费额度够个人用但稳定性需实测。你看到的热搜词里“railway部署”“dify本地部署”“ollama部署本地大模型”全是这类轻量级、免运维、重体验的现代部署范式。它们共同特点是不碰Linux命令行、不配防火墙、不调JVM参数只要会写java -jar xxx.jar就能跑通。这才是当下真实世界里绝大多数Java初学者、学生、个人开发者的真实战场。所以别急着敲scp或docker build。先拿出一张纸回答三个问题这个项目谁用1个同学100个用户还是你自己调试能接受什么成本0元每月30元还是愿意花半天研究免费方案对稳定性要求多高挂一小时无所谓还是必须7×24小时在线答案不同接下来的每一步操作都会走向完全不同的技术分支。这篇教程不会给你“万能模板”而是带你亲手画出属于你自己的部署决策树——因为真正的部署能力不在于记住多少命令而在于看清约束条件后精准选择那条阻力最小的路。2. 真实环境复现从零开始搭建一个可公网访问的Spring Boot示例我们不拿“Hello World”糊弄人。现在就用一个真实可运行的Spring Boot项目来实操它包含Web接口、数据库连接、静态资源覆盖90%的Java Web项目基础结构。项目地址已准备好https://github.com/real-deploy-demo/springboot-public-demo 这是个公开仓库代码干净无敏感信息。2.1 本地验证确保你的项目在本机能跑起来先别想公网。打开终端执行以下步骤Windows用户请用Git Bash或WSL# 克隆示例项目 git clone https://github.com/real-deploy-demo/springboot-public-demo.git cd springboot-public-demo # 查看项目结构关键文件已标注 ls -la # ├── pom.xml ← Maven依赖管理含spring-boot-starter-web等 # ├── src/ # │ └── main/ # │ ├── java/com/example/demo/ # │ │ ├── DemoApplication.java ← 启动类SpringBootApplication # │ │ └── controller/ApiDemoController.java ← 提供 /api/hello 接口 # │ └── resources/ # │ └── application.yml ← 配置文件注意 server.port: 8080 # └── static/ ← 存放index.html等前端资源重点看application.yml里的配置server: port: 8080 address: 0.0.0.0 # 关键必须监听0.0.0.0而非localhost否则外部无法访问 spring: datasource: url: jdbc:h2:mem:testdb;DB_CLOSE_DELAY-1;DB_CLOSE_ON_EXITFALSE driver-class-name: org.h2.Driver username: sa password: h2: console: enabled: true path: /h2-console提示server.address: 0.0.0.0是新手最容易忽略的点。很多教程只写port: 8080结果部署到服务器后curl localhost:8080能通但从外网curl服务器IP:8080却超时——就是因为没显式声明监听所有网卡。Java默认只监听127.0.0.1这是安全设计但部署时必须主动放开。编译并启动# 使用Maven打包生成target/demo-0.0.1-SNAPSHOT.jar mvn clean package -DskipTests # 启动jar包注意加-Dspring.profiles.activeprod模拟生产环境 java -Dspring.profiles.activeprod -jar target/demo-0.0.1-SNAPSHOT.jar启动成功后浏览器访问http://localhost:8080/api/hello应返回{message:Hello from Spring Boot!}访问http://localhost:8080/h2-console可进入H2数据库控制台用户名sa密码为空。这证明项目本地运行无误。2.2 构建可部署的产物不只是jar包还有环境契约很多教程止步于mvn package但生产部署远不止于此。一个可交付的Java部署包必须明确声明它的运行契约Runtime Contract——即它对操作系统、JDK版本、内存、磁盘、网络端口的硬性要求。我们来补全这个契约项目要求为什么重要如何验证JDK版本OpenJDK 17 LTSSpring Boot 3.x 强制要求JDK17低版本会报UnsupportedClassVersionErrorjava -version输出必须含17.0.可用内存≥512MB堆内存H2数据库Spring容器启动后空载约300MB预留200MB防OOM启动时加-Xms512m -Xmx512m参数端口占用8080端口未被占用冲突会导致Address already in use异常netstat -an | grep 8080(Linux/Mac) 或netstat -ano | findstr :8080(Win)文件权限jar包有执行权限Linux下若无x权限java -jar会报Permission deniedchmod x target/demo-0.0.1-SNAPSHOT.jar实操中我见过太多人因JDK版本踩坑。比如在Mac上用Homebrew装的JDK21部署到CentOS7服务器默认OpenJDK11一运行就崩溃。解决方案不是降级本地JDK而是在项目根目录添加Dockerfile将JDK环境固化进镜像——这才是现代Java部署的正确起点。2.3 本地网络可达性测试确认你的机器“能被找到”部署前最后一步验证你的本地机器是否具备被外部访问的基础网络能力。这不是废话而是区分“部署失败”和“网络不通”的关键。在本地启动项目后打开另一个终端执行# 测试本机回环必须通 curl http://localhost:8080/api/hello # 测试本机局域网IP假设你的IP是192.168.1.100 curl http://192.168.1.100:8080/api/hello # 测试本机局域网IP加端口同上但显式指定 curl -v http://192.168.1.100:8080/api/hello如果第二、三步失败说明问题出在本地防火墙或网络配置Windows检查“Windows Defender 防火墙”是否阻止了Java进程的入站连接控制面板→系统和安全→Windows Defender防火墙→高级设置→入站规则→新建规则→程序→选择java.exe路径MacSystem Preferences → Security Privacy → Firewall → Firewall Options → Allow incoming connections for...勾选JavaAppletPlugin或javaLinuxUbuntusudo ufw status查看防火墙状态若为active执行sudo ufw allow 8080。注意此步骤必须成功否则后续所有公网方案都是空中楼阁。我曾帮一个团队排查了两天最后发现是公司WiFi路由器开启了“AP隔离”导致同一局域网内设备无法互访——这种网络层问题永远比代码问题更难定位。当curl http://192.168.1.100:8080/api/hello返回正确JSON时恭喜你的项目已具备“局域网可达性”。下一步就是把它推送到公网——而这条路我们分三类场景逐个击破。3. 场景一零成本快速验证适合学生、个人Demo、面试作品如果你的需求是“让导师/同学/面试官扫码就能看我的项目不关心长期稳定今天就要用”那么买云服务器、配Nginx、申请域名……全是过度设计。真正的捷径是利用现代云平台提供的免运维托管服务。它们的核心逻辑是你只管提交代码剩下的构建、运行、扩缩容、HTTPS、域名全由平台自动完成。3.1 Railway5分钟上线连服务器都不用买Railway是目前对Java开发者最友好的免费托管平台之一。它不要求你懂Docker不强制你写Dockerfile甚至支持直接上传jar包。关键是新用户注册即送$5免费额度足够跑一个Spring Boot应用数月。操作流程全程图形界面无命令行访问 https://railway.app 用GitHub账号登录点击右上角“New Project” → “Create new project”在项目页点击“Add Service” → “Deploy from GitHub”授权Railway访问你的GitHub仓库只需读取权限选择你刚克隆的sprintboot-public-demo仓库在“Build Deploy Settings”中关键配置如下Build Command:mvn clean package -DskipTestsStart Command:java -Dspring.profiles.activeprod -Xms256m -Xmx256m -jar target/demo-0.0.1-SNAPSHOT.jarPort:8080必须与application.yml中一致Environment Variables: 添加JAVA_HOME/opt/java/openjdkRailway预装JDK17路径点击“Deploy Now”等待2-3分钟。构建日志会实时滚动看到Started DemoApplication in X.XXX seconds即表示启动成功。部署完成后Railway会自动生成一个类似https://demo-production-1234.up.railway.app的URL。复制此链接发给任何人都能直接访问你的/api/hello接口。实测心得Railway的免费层使用的是共享CPU冷启动稍慢首次访问约3-5秒但一旦热起来响应速度与自建VPS无异。它最大的优势是零配置HTTPS——所有*.up.railway.app域名自动启用Lets Encrypt证书浏览器地址栏显示绿色锁图标。这对需要展示专业性的面试作品至关重要。3.2 Render更稳的免费选择适合需要7×24小时的小项目Render的免费层比Railway更“实在”它提供永久免费的Web Service实例非睡眠模式且CPU性能更均衡。缺点是必须写Dockerfile但这个Dockerfile简单到只有4行。在项目根目录创建Dockerfile# 使用官方OpenJDK 17镜像 FROM openjdk:17-jre-slim # 将jar包复制到镜像中 COPY target/demo-0.0.1-SNAPSHOT.jar app.jar # 暴露端口必须与application.yml一致 EXPOSE 8080 # 启动命令 ENTRYPOINT [java,-Dspring.profiles.activeprod,-Xms256m,-Xmx256m,-jar,app.jar]然后访问 https://render.com GitHub登录点击“New Web Service” → “Connect Repository”选择你的项目在配置页填写Service Name:demo-javaRegion: 选离你用户最近的如OregonBranch:mainBuild Command:mvn clean package -DskipTestsStart Command:java -Dspring.profiles.activeprod -Xms256m -Xmx256m -jar target/demo-0.0.1-SNAPSHOT.jarEnvironment:JAVA_HOME/usr/lib/jvm/java-17-openjdk-amd64Render的JDK路径点击“Create Web Service”等待构建完成。Render会分配一个https://demo-java.onrender.com的域名同样自动HTTPS。关键对比Railway免费层有$5额度用完会暂停Render免费层无额度限制但要求项目必须公开GitHub仓库设为Public。如果你的项目涉及敏感逻辑Render更安全私有仓库需付费如果只是DemoRailway更省心。3.3 本地穿透方案没有公网IP用Tailscale搞定如果你坚持“必须跑在自己电脑上”且家庭宽带确实没有公网IP国内99%的情况那么传统端口映射路由器DMZ必然失败。此时Tailscale是目前最成熟、最易用的替代方案。Tailscale原理很简单它在你的电脑和Tailscale的全球DERP中继服务器之间建立一条加密的WireGuard隧道。你的电脑获得一个100.x.y.z的Tailscale IP任何加入同一Tailscale网络的设备手机、朋友电脑都能直接curl http://100.x.y.z:8080访问你的服务——完全绕过家庭NAT。实操步骤Windows/macOS/Linux通用注册Tailscale账号https://login.tailscale.com 用GitHub邮箱即可下载对应客户端并安装官网提供一键安装包启动客户端在终端执行# 登录会打开浏览器让你授权 tailscale up # 查看本机Tailscale IP tailscale ip -4 # 输出类似100.101.102.103在另一台设备如手机也安装Tailscale登录同一账号手机浏览器访问http://100.101.102.103:8080/api/hello—— 成功注意事项Tailscale免费版支持20台设备、100GB流量/月对学生和小团队完全够用。它的最大优势是零配置、跨平台、无感知——你不需要改一行代码不需要开路由器端口甚至不需要知道什么是NAT。唯一要做的就是确保你的Java项目监听0.0.0.0:8080我们已在2.1节强调过。这三类方案覆盖了95%的“零成本快速验证”场景。它们的共同点是把复杂度从“运维”转移到“平台”。你付出的不是金钱而是对平台的信任。而这种信任在今天的技术生态里是完全值得的。4. 场景二可控、可扩展的生产部署适合小团队、创业项目、长期服务当你需要“我的服务必须一直在线”“我要自己掌控所有配置”“未来要加监控、日志、数据库”那么免费托管平台的黑盒就不再适用。你需要一台属于自己的服务器以及一套可重复、可审计、可升级的部署流程。这里我们放弃“手动scpjava -jar”的原始方式采用Docker Nginx Lets Encrypt的黄金组合——它不是最前沿的但却是经过十年生产环境验证、故障率最低、文档最全的方案。4.1 服务器选型与初始化为什么推荐Ubuntu 22.04 LTS别纠结CentOS、Debian或Alibaba Cloud Linux。对于Java部署Ubuntu 22.04 LTS是当前最平衡的选择理由如下JDK生态最友好apt install openjdk-17-jre-headless一行安装无依赖冲突Docker官方支持最佳Docker CE的Ubuntu包更新最及时apt-get install docker.io即可Lets Encrypt兼容性最强Certbot工具对Ubuntu的自动化续期脚本最成熟社区资源最丰富遇到任何问题Stack Overflow上90%的答案都基于Ubuntu。购买服务器以腾讯云轻量应用服务器为例地域选离你用户最近的如上海、广州镜像Ubuntu 22.04 LTS切勿选CentOS 7已停止维护配置2核2G内存起步Spring BootH2数据库最低要求带宽5Mbps足够100并发以内安全组务必开放端口22(SSH),80(HTTP),443(HTTPS),8080(Java服务仅限内网见4.3节)。服务器创建后用SSH登录Windows用户推荐Termius或FinalShellssh rootyour-server-ip # 输入密码腾讯云后台可重置首次登录后立即执行初始化# 更新系统 apt update apt upgrade -y # 安装基础工具 apt install -y curl wget git vim net-tools # 创建非root用户安全最佳实践 adduser deploy usermod -aG sudo deploy # 切换到deploy用户 su - deploy经验之谈永远不要用root用户直接部署。我见过太多团队因root下误删/etc目录导致服务器瘫痪。deploy用户拥有sudo权限但每次提权都需要输入密码形成天然的操作确认屏障。4.2 Docker化你的Java项目从jar包到可移植镜像Docker是Java部署的分水岭。它解决了“在我机器上能跑到服务器上就报错”的千古难题。核心思想把JDK、jar包、配置文件、启动脚本全部打包成一个不可变的镜像到哪运行都一样。在你的本地项目根目录创建Dockerfile内容与Render版相同但更健壮# 多阶段构建第一阶段用于编译第二阶段用于运行 FROM maven:3.8.6-openjdk-17 AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline -B COPY . . RUN mvn clean package -DskipTests # 第二阶段极简运行时 FROM openjdk:17-jre-slim VOLUME [/tmp] ARG JAR_FILEtarget/demo-0.0.1-SNAPSHOT.jar COPY --frombuilder /app/${JAR_FILE} app.jar EXPOSE 8080 ENTRYPOINT [java,-Dspring.profiles.activeprod,-Xms256m,-Xmx512m,-Djava.security.egdfile:/dev/./urandom,-jar,app.jar]关键点解析多阶段构建第一阶段用maven镜像编译第二阶段用更小的openjdk镜像运行最终镜像体积从800MB降至150MB-Djava.security.egdfile:/dev/./urandom修复Linux容器内Java SecureRandom阻塞问题常见于Tomcat启动慢VOLUME [/tmp]为Spring Boot临时文件如上传提供挂载点避免容器重启后丢失。构建并测试本地镜像# 构建镜像tag为demo-java:latest docker build -t demo-java:latest . # 启动容器映射8080端口 docker run -d -p 8080:8080 --name demo-app demo-java:latest # 查看日志确认启动成功 docker logs -f demo-app # 应看到 Started DemoApplication in X.XXX seconds4.3 Nginx反向代理让HTTP变成HTTPS让8080变成80直接暴露http://your-server-ip:8080既不专业也不安全。Nginx作为反向代理承担三重角色端口转换把用户访问的http://your-domain.com80端口转发给本地http://localhost:8080HTTPS卸载处理SSL证书后端Java服务仍用HTTP降低复杂度静态资源服务/static/下的图片、JS、CSS由Nginx直接返回不走Java。安装Nginxsudo apt install nginx -y sudo systemctl enable nginx sudo systemctl start nginx配置反向代理编辑/etc/nginx/sites-available/demoserver { listen 80; server_name your-domain.com; # 替换为你的域名或先用服务器IP # HTTP重定向到HTTPS启用SSL后取消注释 # return 301 https://$server_name$request_uri; location / { proxy_pass http://localhost:8080; 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; } # 静态资源缓存 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ { expires 1y; add_header Cache-Control public, immutable; } }启用配置# 创建软链接 sudo ln -sf /etc/nginx/sites-available/demo /etc/nginx/sites-enabled/ # 测试Nginx配置语法 sudo nginx -t # 重载配置 sudo systemctl reload nginx此时访问http://your-server-ip应看到与http://your-server-ip:8080完全相同的页面。Nginx已成功接管流量。4.4 Lets Encrypt自动HTTPS免费、可信、全自动没有HTTPS的网站在Chrome中会被标记为“不安全”严重影响可信度。Lets Encrypt提供免费、自动化、可信的SSL证书。安装Certbotsudo apt install certbot python3-certbot-nginx -y获取并安装证书假设你已将域名your-domain.com解析到服务器IP# Certbot会自动修改Nginx配置添加HTTPS块 sudo certbot --nginx -d your-domain.com # 按提示输入邮箱同意协议选择重定向选2强制HTTPS执行后Certbot会自动申请证书修改/etc/nginx/sites-available/demo添加443端口配置配置自动续期通过systemd timer每天凌晨自动检查。验证HTTPS浏览器访问https://your-domain.com地址栏显示绿色锁图标curl -I https://your-domain.com返回HTTP/2 200。续期无忧Certbot的自动续期任务已内置。你只需每年检查一次sudo certbot renew --dry-run。若输出Congratulations, all simulated renewals succeeded则万事大吉。至此你的Java项目已具备生产级部署的所有要素Docker容器化、Nginx反向代理、自动HTTPS、域名访问。整个过程可完全脚本化下次部署新项目只需替换Dockerfile中的jar包名和Nginx配置中的域名5分钟内即可复现。5. 场景三内网穿透终极方案适合无公网IP、需长期稳定、拒绝云服务当你的项目必须运行在内网服务器如公司内网、家庭NAS、树莓派且你无法接受任何第三方云平台出于数据隐私、合规或纯粹的技术洁癖那么自建FRP服务器是唯一可行的方案。它不像Tailscale那样依赖中继而是你完全掌控的、点对点的穿透服务。5.1 FRP架构解析为什么它比ngrok更可控FRPFast Reverse Proxy由两部分组成frpsFRP Server部署在一台有公网IP的VPS上哪怕是最便宜的1核1GfrpcFRP Client部署在你的内网Java服务器上主动连接frps。数据流向用户 → frps公网IP:端口 → frpc内网IP:8080 → Java服务。所有流量经frps中转但frps本身不处理业务逻辑只做TCP/UDP转发。优势在于完全自主证书、域名、端口、加密密钥全部由你控制零依赖第三方不依赖ngrok.com、serveo.net等商业服务无停服风险可定制性强支持TCP/UDP/HTTP/HTTPS/STCP等多种穿透模式可配置域名、子域名、HTTP头过滤。5.2 部署frps服务端一台5美元VPS足矣购买一台最便宜的VPS如Vultr $2.5/mo、Oracle Cloud Always Free系统选Ubuntu 22.04。登录后下载并配置frps# 下载最新frp截至2024年v0.54.0为稳定版 wget https://github.com/fatedier/frp/releases/download/v0.54.0/frp_0.54.0_linux_amd64.tar.gz tar -xzf frp_0.54.0_linux_amd64.tar.gz cd frp_0.54.0_linux_amd64 # 编辑服务端配置 frps.ini cat frps.ini EOF [common] bind_port 7000 # frpc连接此端口 vhost_http_port 80 # HTTP服务映射端口 vhost_https_port 443 # HTTPS服务映射端口 dashboard_port 7500 # 监控面板端口可选 dashboard_user admin dashboard_pwd your_password_here token your_secure_token_here # frpc连接时需提供必须设置 EOF创建systemd服务实现开机自启sudo tee /etc/systemd/system/frps.service EOF [Unit] DescriptionFRP Server Afternetwork.target [Service] Typesimple Userroot WorkingDirectory/root/frp_0.54.0_linux_amd64 ExecStart/root/frp_0.54.0_linux_amd64/frps -c /root/frp_0.54.0_linux_amd64/frps.ini Restarton-failure RestartSec10 [Install] WantedBymulti-user.target EOF # 启动服务 sudo systemctl daemon-reload sudo systemctl enable frps sudo systemctl start frps # 检查状态 sudo systemctl status frps安全加固务必修改dashboard_user和dashboard_pwd并设置强token。frps默认不开启认证token是防止未授权frpc接入的唯一防线。5.3 部署frpc客户端内网服务器上的轻量守护在你的内网Java服务器Ubuntu上操作# 下载frpc与frps同版本 wget https://github.com/fatedier/frp/releases/download/v0.54.0/frp_0.54.0_linux_amd64.tar.gz tar -xzf frp_0.54.0_linux_amd64.tar.gz cd frp_0.54.0_linux_amd64 # 编辑客户端配置 frpc.ini cat frpc.ini EOF [common] server_addr your-frps-public-ip # 替换为你的VPS公网IP server_port 7000 token your_secure_token_here # 必须与frps.ini中一致 [web] type http local_port 8080 # Java服务端口 custom_domains your-domain.com # 你的域名需DNS解析到VPS IP EOF启动frpc# 后台运行 ./frpc -c ./frpc.ini # 或创建systemd服务推荐更稳定 sudo tee /etc/systemd/system/frpc.service EOF [Unit] DescriptionFRP Client Afternetwork.target [Service] Typesimple Userroot WorkingDirectory/root/frp_0.54.0_linux_amd64 ExecStart/root/frp_0.54.0_linux_amd64/frpc -c /root/frp_0.54.0_linux_amd64/frpc.ini Restarton-failure RestartSec10 [Install] WantedBymulti-user.target EOF sudo systemctl daemon-reload sudo systemctl enable frpc sudo systemctl start frpc5.4 DNS与HTTPS让穿透服务真正可用此时访问http://your-frps-public-ip应看到Java服务的响应。但要达到生产可用还需两步域名解析将你的域名如demo.yourname.com的A记录指向your-frps-public-ipHTTPS加持在frps端配置Lets Encrypt或在VPS上用Nginx反向代理Certbot。推荐后者Nginx方案因为它更灵活# 在VPS上安装Nginx和Certbot同4.4节 sudo apt install nginx certbot python3-certbot-nginx -y # 配置Nginx将HTTPS请求转发给frps的vhost_http_port80 sudo tee /etc/nginx/sites-available/frp-proxy EOF server { listen 443 ssl http2; server_name demo.yourname.com; ssl_certificate /etc/letsencrypt/live/demo.yourname.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/demo.yourname.com/privkey.pem; location / { proxy_pass http://127.0.0.1:80; # frps的vhost_http_port proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } server { listen 80; server_name demo.yourname.com; return 301 https://$server_name$request_uri; } EOF sudo ln -sf /etc/nginx/sites-available/frp-proxy /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx # 申请证书 sudo certbot --nginx -d demo.yourname.com最终用户访问https://demo.yourname.com流量路径为用户HTTPS请求 → VPS NginxHTTPS卸载→ VPS frps80端口→ VPS frpcTCP隧道→ 内网服务器8080 → Java服务整条链路由你100%掌控无任何第三方介入。虽然初期配置稍复杂但一旦跑通稳定性远超所有SaaS穿透服务。这是我为金融客户部署内部管理系统时的首选方案——因为合规审查时你能清晰说出每一跳的IP、端口、加密方式。6. 部署后的必做清单从“能访问”到“可运维”项目上线只是开始。一个真正可用的公网Java服务必须通过以下10项检查。少一项都可能在深夜收到告警。6.1 JVM内存监控避免OutOfMemoryError的定时炸弹java: outofmemoryerror: insufficient memory是Java部署最经典的报错。它往往在流量高峰时突然爆发而非启动时。原因在于JVM堆内存设置不合理或存在内存泄漏。在启动命令中必须显式设置堆内存# 错误不设内存依赖JVM默认通常很小 java -jar app.jar # 正确根据服务器内存设置合理范围 java -Xms512m -Xmx1024m -jar app.jar # -Xms初始堆大小-Xmx最大堆大小建议设为相等避免动态扩容GC验证是否生效# 查看Java进程的JVM参数 ps aux | grep java # 输出应含