JeecgBoot与Vue3应用在TongWeb上的WAR包部署实战

发布时间:2026/8/7 23:53:56
JeecgBoot与Vue3应用在TongWeb上的WAR包部署实战 1. 项目背景与核心挑战最近在帮一个客户做项目迁移从原来的单体架构升级到前后端分离的微服务架构后端选型了JeecgBoot前端自然是Vue3。整个技术栈看起来挺现代但部署环境却是个“老熟人”——东方通的TongWeb应用服务器。这个组合在实际落地时踩了不少坑也总结出了一套相对高效的部署方案。今天就来聊聊如何把基于Spring Boot的JeecgBoot后端和Vue3前端平滑、稳定地部署到TongWeb上特别是如何处理那个让人头疼的WAR包问题。JeecgBoot作为一个基于Spring Boot的低代码开发平台其默认的打包和运行方式是内嵌的Tomcat通过可执行的JAR包直接运行这在其官方文档和大多数社区讨论中是主流。然而很多传统企业或特定行业的信息化项目出于合规、运维习惯或现有技术栈统一管理的考虑会要求将应用部署到指定的商用中间件上比如东方通的TongWeb、金蝶的Apusic、或者IBM的WebSphere等。这就带来了第一个核心矛盾Spring Boot的“约定大于配置”与商用中间件严格部署规范之间的冲突。TongWeb作为一款符合Java EE规范的应用服务器期望接收的是标准的WARWeb Application Archive包而不是一个包含了整个Servlet容器的Fat Jar。前端方面Vue3项目通过构建工具如Vite或Webpack生成的是纯粹的静态资源HTML、CSS、JS。在开发环境我们依赖npm run dev启动的Dev Server在生产环境则需要将这些静态文件放到一个Web服务器上。常见的做法是使用Nginx单独部署或者将构建产物放入Spring Boot项目的src/main/resources/static目录下随后端一起打包。当后端需要打WAR包部署到TongWeb时前端的集成方式就需要仔细考量以确保路由、接口代理、资源加载都能正常工作。因此这个“高效部署方案”的目标非常明确将JeecgBoot后端改造为可部署于TongWeb的标准WAR应用并优雅地集成Vue3前端静态资源实现一键构建、统一部署同时保证应用在TongWeb环境下的性能与稳定性。下面我们就从环境准备开始一步步拆解这个过程中的技术选型、配置改造和避坑指南。2. 环境准备与项目结构剖析在动手改造之前我们必须先理清两个项目的基线状态和依赖关系。一个清晰的起点能避免后续很多混乱。2.1 后端JeecgBoot项目初始化与依赖审视首先确保你有一个可运行的JeecgBoot项目。你可以从官方Git仓库拉取最新的代码。重点检查pom.xml文件打包方式默认应该是jar。这是我们第一个要改动的地方。!-- 修改前 -- packagingjar/packaging !-- 修改后 -- packagingwar/packaging内嵌Tomcat依赖作用域Spring Boot项目内嵌了Tomcat但当我们部署到外部的TongWeb它本身就是一个Servlet容器时就需要避免内嵌容器与外部容器的冲突。我们需要将内嵌Tomcat的依赖标记为provided意味着编译和测试时需要但最终打包WAR时不会包含进去。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId scopeprovided/scope !-- 关键修改 -- /dependency有些JeecgBoot项目可能还引入了spring-boot-starter-web它默认传递了Tomcat依赖。同样需要排除它或者确保其作用域正确。更稳妥的做法是在spring-boot-starter-web依赖上也显式设置Tomcat为provided但这通常通过上面的spring-boot-starter-tomcat设置即可生效因为Maven依赖传递会尊重这个作用域。Servlet API依赖确保项目包含了javax.servlet:javax.servlet-api或jakarta.servlet:jakarta.servlet-api取决于你使用的Java EE/Jakarta EE版本并且作用域也是provided。TongWeb会提供这些API。2.2 前端Vue3项目构建产出分析使用Vite或Vue CLI创建的Vue3项目运行npm run build或yarn build、pnpm build后默认会在项目根目录下生成一个dist文件夹。这个文件夹里通常包含index.html: 应用入口文件。assets/: 存放编译后的JS、CSS文件以及图片等资源。可能还有其他如favicon.ico等文件。我们的目标是将这个dist目录下的所有内容作为静态资源集成到后端的WAR包中。这样当TongWeb启动应用后用户访问应用根路径就能直接访问到前端的index.html前端再通过Ajax调用后端的REST API。2.3 工具链统一Maven与Node.js环境整个部署流程会涉及Maven构建Java后端和Node构建前端。建议在CI/CD服务器或本地构建环境中统一管理JDK: 8或11与JeecgBoot及TongWeb版本兼容建议使用JeecgBoot官方推荐的版本。Maven: 3.6。Node.js: 16 或 18与Vue3构建工具兼容。npm/yarn/pnpm: 任选其一确保锁文件package-lock.json,yarn.lock,pnpm-lock.yaml一致性避免环境差异导致构建失败。3. 后端改造从Spring Boot Jar到TongWeb War这是整个方案的核心技术环节。我们不能简单地把打包方式从jar改成war就了事需要让Spring Boot应用学会在“别人的地盘”TongWeb上正确启动。3.1 修改启动类继承SpringBootServletInitializerSpring Boot应用要部署为WAR包其主启动类必须继承SpringBootServletInitializer并重写configure方法。这个类的作用是在WAR包被外部Servlet容器如TongWeb加载时提供入口点来引导Spring Boot应用。找到你的Application类通常命名为JeecgApplication或Application进行如下改造import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.boot.builder.SpringApplicationBuilder; import org.springframework.boot.web.servlet.support.SpringBootServletInitializer; SpringBootApplication public class JeecgApplication extends SpringBootServletInitializer { // 1. 继承 Override // 2. 重写configure方法 protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) { // 指定配置源即当前的启动类 return builder.sources(JeecgApplication.class); } public static void main(String[] args) { SpringApplication.run(JeecgApplication.class, args); } }为什么必须这么做当你在IDE中直接运行main方法或者用java -jar命令启动JAR包时Spring Boot的内嵌容器会直接启动。但当应用被打包成WAR并部署到TongWeb时容器会按照Servlet规范寻找并初始化ServletContainerInitializer的实现类。SpringBootServletInitializer就是Spring Boot提供的这个实现它的configure方法会在容器启动时被调用从而完成Spring应用上下文的构建。3.2 处理静态资源路径与上下文根在默认的Spring Boot Jar运行模式下应用上下文根Context Path通常是/。但在TongWeb中部署WAR包上下文根默认是WAR包的文件名不含.war后缀例如你的WAR包叫jeecg-app.war那么访问地址可能就是http://server:port/jeecg-app/。这会对前端资源的加载和后端API的访问路径产生影响。后端API路径JeecgBoot中的Controller路径通常以/开头如RequestMapping(“/sys/user”)。在上下文根为/jeecg-app的情况下完整的访问路径会变成/jeecg-app/sys/user。这本身不是问题只要前端在请求API时带上这个上下文根即可。但为了灵活性建议在application.yml或application.properties中配置server.servlet.context-path使其与预期的部署路径一致或者在代码中避免对根路径做硬编码假设。前端静态资源集成这是关键。我们需要将Vue3构建出的dist目录内容复制到WAR包中WEB-INF目录之外的某个位置例如根目录并确保Spring Boot能将其作为静态资源提供服务。3.3 使用Maven插件集成前端构建为了实现“一键构建”我们可以在后端项目的pom.xml中配置Maven插件让Maven在打包过程中自动触发前端构建并将产物复制到正确位置。这里推荐使用frontend-maven-plugin和maven-resources-plugin组合。build plugins !-- 插件1用于执行前端构建命令 (npm/yarn/pnpm) -- plugin groupIdcom.github.eirslett/groupId artifactIdfrontend-maven-plugin/artifactId version1.12.1/version configuration !-- 假设前端项目目录与后端平级名为 web-vue3 -- workingDirectory../web-vue3/workingDirectory installDirectorytarget/installDirectory /configuration executions execution idinstall node and npm/id goals goalinstall-node-and-npm/goal /goals !-- 可配置特定Node版本 -- configuration nodeVersionv18.16.0/nodeVersion /configuration /execution execution idnpm install/id goals goalnpm/goal /goals configuration argumentsinstall/arguments /configuration /execution execution idnpm run build/id goals goalnpm/goal /goals configuration argumentsrun build/arguments /configuration phaseprepare-package/phase !-- 在打包阶段之前执行 -- /execution /executions /plugin !-- 插件2将前端构建产物复制到WAR包的指定位置 -- plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-resources-plugin/artifactId version3.3.0/version executions execution idcopy-vue-dist/id phaseprepare-package/phase !-- 与前端构建同一阶段 -- goals goalcopy-resources/goal /goals configuration resources resource !-- 源目录前端构建输出目录 -- directory../web-vue3/dist/directory /resource /resources !-- 目标目录WAR包的根目录 -- outputDirectory${project.build.directory}/${project.build.finalName}/outputDirectory overwritetrue/overwrite /configuration /execution /executions /plugin !-- 插件3Spring Boot Maven Plugin用于打包 -- plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId !-- 注意当打包方式为war时这个插件主要作用是提供Spring Boot的依赖管理支持 实际的WAR包打包是由maven-war-plugin完成的。 -- configuration !-- 如果你需要排除一些内嵌容器相关的依赖可以在这里配置 -- excludes exclude groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId /exclude /excludes /configuration /plugin /plugins /build配置解析与避坑点workingDirectory: 这个路径必须指向你前端项目的根目录。如果前端项目在后端项目内部例如src/main/frontend则路径需要相应调整。绝对路径和相对路径要写对这是第一个容易出错的地方。phase:prepare-package阶段会在Maven执行package目标生成WAR/JAR之前运行确保前端先构建好资源先复制好。outputDirectory:${project.build.directory}通常是target${project.build.finalName}是你的项目名加版本号如jeecg-app-1.0.0。这个配置会把dist下的所有文件复制到WAR包解压后的根目录。这样index.html就在WAR包的根路径下了。环境一致性frontend-maven-plugin会在构建时下载指定版本的Node和npm到target目录这有助于保证不同构建环境的一致性。但如果你的服务器网络受限也可以预先安装好Node并在插件配置中跳过install-node-and-npm这个execution。4. 前端适配构建配置与API代理设置前端项目也需要进行一些调整以适配与后端WAR包一起部署的模式。4.1 修改Vue Router的历史模式与Base URLVue Router有两种模式hash模式和history模式。在history模式下URL看起来更美观没有#但它需要服务器端的配合。当用户直接访问一个深层次的路由如/user/profile时服务器需要能正确返回index.html而不是404。由于我们将前端静态文件放在了WAR包根目录TongWeb或任何Servlet容器默认会对像/user/profile这样的路径去寻找对应的资源文件或Servlet显然找不到。我们需要在前端和后端都做配置。前端路由配置在Vue Router的配置文件中设置base选项和history模式。// router/index.js import { createRouter, createWebHistory } from vue-router const router createRouter({ // 假设你的应用部署在 /jeecg-app 下 history: createWebHistory(‘/jeecg-app/‘), // 关键设置基础路径 routes: [...] })这个base值必须与后端应用在TongWeb中的上下文根Context Path一致。这样Vue Router生成的所有路由链接都会自动带上这个前缀。静态资源路径在vite.config.js或vue.config.js中配置baseVite或publicPathVue CLI确保JS、CSS等静态资源能被正确加载。// vite.config.js export default defineConfig({ base: ‘/jeecg-app/‘, // 与路由base保持一致 // ...其他配置 })// vue.config.js module.exports { publicPath: ‘/jeecg-app/‘, // ...其他配置 }4.2 配置生产环境API请求基地址在开发时我们通常使用Vite或Webpack Dev Server的代理功能来解决跨域问题API请求发向localhost:8080。但在生产环境前端和后端在同一域名和端口下都通过TongWeb访问不存在跨域问题API请求应该直接发向后端的相对路径。我们需要根据环境变量来动态设置请求的基地址Base URL。可以使用Axios为例// src/utils/request.js import axios from ‘axios‘ // 判断是否是开发环境 const isDevelopment process.env.NODE_ENV ‘development‘ // 创建axios实例 const service axios.create({ // 基础地址开发环境使用代理前缀需在vite.config.js中配置生产环境使用空字符串相对路径或完整上下文路径 baseURL: isDevelopment ? ‘/api‘ : ‘‘, // 或者 ‘/jeecg-app‘ 如果后端Controller没有配置context-path timeout: 10000 }) // 请求拦截器、响应拦截器等... export default service然后在你的Vite配置中设置开发环境代理// vite.config.js export default defineConfig({ // ...其他配置 server: { proxy: { ‘/api‘: { target: ‘http://localhost:8080‘, // 后端开发服务器地址 changeOrigin: true, rewrite: (path) path.replace(/^\/api/, ‘/jeecg-app‘) // 重写路径去掉/api前缀加上上下文根 } } } })这样在开发时请求/api/sys/user会被代理到http://localhost:8080/jeecg-app/sys/user在生产环境请求就直接是/jeecg-app/sys/user因为前端和后台在同一个应用上下文内。5. TongWeb服务器配置与部署实战一切准备就绪接下来就是真刀真枪地部署到TongWeb了。5.1 TongWeb版本选择与基础配置首先确认你的TongWeb版本与JDK版本的兼容性。JeecgBoot 3.x 通常需要JDK 8或11确保TongWeb支持对应的Java版本。登录TongWeb的管理控制台通常地址是http://server:port/console。数据源配置JeecgBoot需要连接数据库。在TongWeb控制台的“资源”-“JDBC”-“数据源”中创建一个新的数据源。关键参数如下JNDI名称例如java:comp/env/jdbc/jeecg-boot。这个名称需要与JeecgBoot配置文件中的jndi-name对应。数据库驱动上传并选择对应的JDBC驱动JAR包如MySQL的mysql-connector-java-8.0.xx.jar。连接URL、用户名、密码按实际数据库填写。连接池参数根据应用负载设置初始连接数、最大连接数、最小连接数等。这里有个坑TongWeb的数据源配置参数名可能与常见的Druid、HikariCP有些差异需要仔细阅读文档。例如测试连接是否成功的“验证查询”Validation QueryMySQL通常是SELECT 1。应用部署在“应用”-“Web应用”中点击“部署”。选择你打包好的WAR文件jeecg-app.war。上下文根这是最重要的设置之一。你可以在这里指定应用的访问路径。如果留空默认就是WAR文件名不含后缀。为了清晰我建议在这里显式设置为/jeecg-app与前端配置的base保持一致。虚拟主机一般选择默认主机。点击“部署”后TongWeb会将WAR包解压到其应用部署目录如$TONGWEB_HOME/webapps/jeecg-app。5.2 解决JeecgBoot在TongWeb中的常见问题部署后启动应用很可能会遇到一些问题。以下是几个典型问题及解决方案问题一应用启动失败报错No Spring WebApplicationInitializer types detected on classpath原因TongWeb没有正确识别到我们的SpringBootServletInitializer子类。这可能是因为WAR包结构有问题或者TongWeb的类加载器配置。排查检查WAR包内WEB-INF/classes目录下你的启动类如JeecgApplication.class是否存在。检查WEB-INF/lib目录下是否包含了所有必要的依赖JAR包特别是Spring相关的jar。确保没有因为scopeprovided/scope导致核心Spring Boot依赖缺失。注意provided的依赖是期望容器提供的但Spring Boot的核心JAR如spring-boot-*.jar不应该被标记为provided只有spring-boot-starter-tomcat才需要。在TongWeb控制台查看应用日志通常会有更详细的错误信息。问题二静态资源前端页面访问404原因Spring Boot的静态资源处理默认会映射/**到classpath:/static/,classpath:/public/,classpath:/resources/等目录。但我们通过Maven插件把前端dist放到了WAR包的根目录这不在上述默认映射里。解决方案我们需要自定义静态资源映射。在Spring Boot配置文件中application.yml添加spring: web: resources: static-locations: classpath:/META-INF/resources/,classpath:/resources/,classpath:/static/,classpath:/public/,file:${webapp.root}/ mvc: static-path-pattern: /**同时在Java代码中通过Configuration配置一个WebMvcConfigurer将根路径/映射到我们放置前端资源的物理目录。但更简单的方法是依赖TongWeb的默认静态文件服务因为我们将dist下的文件直接放在了WAR包根目录TongWeb会像对待普通HTML文件一样直接提供它们。只要确保没有其他Servlet比如Spring MVC的DispatcherServlet拦截了所有请求/*即可。Spring Boot默认的DispatcherServlet映射是/这意味着它不会拦截像.html,.js,.css这样的静态资源请求具体规则由spring.mvc.static-path-pattern和spring.web.resources.static-locations决定。我们的配置确保了静态资源请求能被正确响应。问题三数据库连接失败JNDI查找不到数据源原因JeecgBoot配置文件中指定的JNDI名称与TongWeb中配置的不一致或者应用没有权限访问JNDI资源。解决方案在application.yml中配置JNDI数据源spring: datasource: jndi-name: java:comp/env/jdbc/jeecg-boot同时必须在WAR包的WEB-INF/web.xml或通过Java Config中声明对这个资源引用的依赖。对于Spring Boot可以通过在启动类或配置类上添加EnableJpaRepositories等注解但更关键的是要确保应用有WEB-INF/web.xml文件。如果没有可以创建一个简单的web.xml?xml version1.0 encodingUTF-8? web-app xmlnshttp://xmlns.jcp.org/xml/ns/javaee xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd version3.1 resource-ref descriptionDB Connection/description res-ref-namejdbc/jeecg-boot/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref /web-app这个web.xml告诉TongWeb容器这个应用需要引用一个名为jdbc/jeecg-boot的DataSource资源。res-ref-name与spring.datasource.jndi-name中java:comp/env/后面的部分对应。问题四应用启动慢或首次访问超时原因TongWeb在部署WAR包时会进行解压、类加载、Spring上下文初始化等操作。JeecgBoot项目通常较大依赖多初始化耗时较长。优化建议预热在TongWeb中配置应用为“启动时加载”并在非业务高峰期进行部署或重启。调整JVM参数在TongWeb的启动脚本如startserver.sh中为JVM分配足够的内存-Xms,-Xmx并选择合适的垃圾回收器。精简依赖检查pom.xml移除不必要的依赖。使用mvn dependency:analyze命令分析未使用的依赖。使用TongWeb的部署优化有些应用服务器支持“分解式部署”Exploded Deployment即直接部署解压后的目录而不是WAR包可以避免每次解压。但管理上可能不如WAR包方便。6. 持续集成与部署优化对于企业级项目手动打包、上传、部署显然不够高效。我们可以将上述流程脚本化、自动化。6.1 基于Shell脚本的一键部署编写一个部署脚本deploy.sh可以放在项目根目录或CI/CD服务器上#!/bin/bash # 定义变量 APP_NAMEjeecg-app WAR_FILEtarget/${APP_NAME}.war TONGWEB_HOME/opt/tongweb TONGWEB_DEPLOY_DIR${TONGWEB_HOME}/webapps BACKUP_DIR/opt/backup/$(date %Y%m%d_%H%M%S) echo “开始部署 ${APP_NAME}...“ # 1. 备份当前运行的应用如果存在 if [ -d ${TONGWEB_DEPLOY_DIR}/${APP_NAME} ]; then echo “备份旧版本...“ mkdir -p ${BACKUP_DIR} cp -r ${TONGWEB_DEPLOY_DIR}/${APP_NAME} ${BACKUP_DIR}/ cp ${TONGWEB_DEPLOY_DIR}/${APP_NAME}.war ${BACKUP_DIR}/ 2/dev/null || true fi # 2. 停止应用通过TongWeb管理命令或API这里以直接删除文件触发热部署为例生产环境建议使用管理控制台操作 echo “停止应用...“ # 注意直接删除文件可能不优雅生产环境建议使用TongWeb的停止命令或REST API rm -f ${TONGWEB_DEPLOY_DIR}/${APP_NAME}.war rm -rf ${TONGWEB_DEPLOY_DIR}/${APP_NAME} # 3. 复制新的WAR包 echo “复制新WAR包...“ if [ ! -f ${WAR_FILE} ]; then echo “错误WAR文件 ${WAR_FILE} 不存在请先执行Maven打包。“ exit 1 fi cp ${WAR_FILE} ${TONGWEB_DEPLOY_DIR}/ # 4. 等待TongWeb自动解压和部署监控日志 echo “等待应用启动...“ sleep 30 # 等待时间取决于应用大小可调整 # 5. 简单健康检查 HEALTH_URLhttp://localhost:8080/${APP_NAME}/sys/common/version # JeecgBoot的一个健康检查或版本接口 echo “执行健康检查: ${HEALTH_URL}“ max_attempts10 attempt1 while [ ${attempt} -le ${max_attempts} ]; do if curl -f -s ${HEALTH_URL} /dev/null; then echo “应用启动成功“ exit 0 else echo “尝试 ${attempt}/${max_attempts}: 应用尚未就绪等待5秒...“ sleep 5 ((attempt)) fi done echo “错误应用在指定时间内未启动成功。“ exit 1注意这个脚本是一个简单示例直接操作文件系统。在生产环境中更安全的方式是通过TongWeb的管理控制台REST API如果提供来执行部署、启动、停止操作或者使用Ansible、SaltStack等配置管理工具。6.2 与Jenkins/GitLab CI集成在CI/CD流水线中可以定义如下阶段拉取代码从Git仓库拉取前后端代码。构建前端进入前端目录执行npm install和npm run build。构建后端进入后端目录执行mvn clean package -DskipTests。此时frontend-maven-plugin和maven-resources-plugin会自动执行完成前端构建和资源复制最终生成WAR包。制品归档将生成的jeecg-app.war保存为制品Artifact。部署将制品传输到目标服务器并执行上述的部署脚本或调用TongWeb的部署接口。通过自动化流水线可以实现代码提交后自动测试、构建、部署到测试环境大大提升交付效率。7. 监控、日志与性能调优应用部署上线后稳定运行离不开监控和调优。7.1 日志配置与收集JeecgBoot默认使用Logback日志配置在logback-spring.xml中。在TongWeb环境中需要注意日志文件的路径权限。日志路径避免将日志直接写在$TONGWEB_HOME目录下以免在TongWeb升级或清理时被误删。建议配置一个独立的日志目录如/var/log/jeecg-app/并确保TongWeb的运行用户对该目录有写权限。!-- 在logback-spring.xml中 -- property nameLOG_PATH value/var/log/jeecg-app/ appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender file${LOG_PATH}/app.log/file !-- ...滚动策略等 -- /appender日志级别生产环境通常将级别设为INFO或WARN。对于性能排查可以临时开启DEBUG级别但要注意日志量。TongWeb访问日志TongWeb自身也有访问日志可以在其管理控制台的“虚拟主机”-“HTTP”-“访问日志”中配置用于分析请求流量和响应时间。7.2 性能监控与JVM调优TongWeb控制台监控TongWeb管理控制台提供了对JVM内存、线程池、数据库连接池、请求统计等的监控面板。定期查看这些指标可以及时发现内存泄漏、连接池耗尽等问题。JVM参数调优根据服务器硬件和应用实际使用情况调整JVM堆内存大小。例如在$TONGWEB_HOME/bin/startserver.shLinux中JAVA_OPTS$JAVA_OPTS -Xms4096m -Xmx4096m -XX:UseG1GC -XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/opt/tongweb/logs/gc.log-Xms和-Xmx设置堆内存初始大小和最大值建议设为相同值以避免运行时调整带来的性能开销。-XX:UseG1GC使用G1垃圾收集器适用于多核大内存服务器能提供相对均衡的吞吐量和停顿时间。-Xloggc将GC日志输出到文件便于后续分析。数据库连接池监控在TongWeb控制台监控配置的数据源关注活跃连接数、等待连接数等指标。如果等待连接数持续很高可能需要增大连接池最大连接数或者优化应用中数据库操作的性能。7.3 常见故障排查思路当应用出现访问慢、报错时可以按以下步骤排查检查TongWeb应用日志首先查看TongWeb控制台中该应用的“日志查看器”或者直接查看$TONGWEB_HOME/logs目录下对应应用和日期的日志文件。错误堆栈信息是定位问题的第一手资料。检查应用自身日志查看我们配置的独立日志文件如/var/log/jeecg-app/app.log看是否有业务逻辑错误或异常。检查资源使用通过TongWeb控制台或服务器命令如top,free查看CPU、内存、磁盘I/O使用情况。如果内存使用率持续很高结合GC日志分析是否存在内存泄漏。检查网络与数据库使用ping、telnet或nc命令检查应用服务器与数据库服务器之间的网络连通性。在数据库端检查慢查询日志。简化问题如果问题复杂尝试剥离前端直接通过工具如Postman调用后端API看是否是后端问题。或者暂时将前端静态资源部署到独立的Nginx上看是否是TongWeb静态资源服务的问题。将JeecgBoot和Vue3应用部署到TongWeb是一个将现代开发框架与传统企业级中间件相结合的过程。核心在于理解Spring Boot WAR包部署的机制以及如何将前端静态资源无缝集成。方案的重点不仅仅是让应用“跑起来”更要确保其在生产环境下的性能、稳定性和可维护性。通过本文的步骤从项目改造、构建集成、服务器配置到自动化部署和监控形成了一套完整的闭环。在实际操作中可能还会遇到特定版本兼容性、依赖冲突等细节问题这就需要我们根据具体的错误信息结合Spring Boot、TongWeb的官方文档和社区资源具体问题具体分析了。记住耐心查看日志永远是解决问题的第一步。