信创环境（openEuler24.03）部署JeecgBoot3.8.3实战经验总结

本文续前节讲述零基础零成本部署JeecgBoot3.8.3全程实战踩坑点，为了让大家少踩坑，将总结干货拿出来与大家分享。结论先行，经过多轮测视，X86架构能够兼容部署（欧拉/麒麟+JeecgBoot），但在部署过程中前后端联调通过，POST出现问题，最终决定仅改动源码中的YML文件，再进行调试，后面测试结果会不定期更新。

1. 背景与环境

• 服务器：OpenEuler 24.03

• 后端：Java 进程（jeecg-system-start-3.8.3.jar）运行于宿主机，监听 8080，数据库 PostgreSQL 已启动。

• 前端：源码位于 /tmp/jeecg-src/JeecgBoot-v3.8.3/jeecgboot-vue3，需构建并部署到 Nginx。

• 目标：通过 Nginx 托管前端静态文件，并反向代理 /jeecg-boot 至后端。

---

2. 部署流程与排障记录

2.1 环境准备与配置修改

• 检查源码位置

  ls -la /tmp/jeecg-src/JeecgBoot-v3.8.3/
  

  存在 jeecgboot-vue3 目录

• 修改生产环境 API 地址（避免跨域）

  cd /tmp/jeecg-src/JeecgBoot-v3.8.3/jeecgboot-vue3
  cp .env.production .env.production.bak
  sed -i 's#^VITE_GLOB_API_URL=.*#VITE_GLOB_API_URL=/jeecg-boot#' .env.production
  grep VITE_GLOB_API_URL .env.production
  

  输出：VITE_GLOB_API_URL=/jeecg-boot

2.2 构建前端（依赖冲突与解决）

• 执行构建

  npm install
  npm run build
  

• 报错

  npm ERR! ERESOLVE unable to resolve dependency tree
  peer stylelint@">= 11.x < 15" from stylelint-config-prettier@9.0.5
  

• 原因：stylelint 版本过高（16.x），不满足 stylelint-config-prettier 的 peer 依赖。

• 解决：使用 --legacy-peer-deps 忽略依赖冲突。

  npm install --legacy-peer-deps
  npm run build
  

• 结果：构建成功，生成 dist 目录及 _app.config.js 等文件。

2.3 部署静态文件至 Nginx

• 初始部署（有交互提示）

  cp -r dist/* /usr/share/nginx/html/
  # 提示“是否覆盖 index.html”
  

• 问题：未输入 y 导致 index.html 未被覆盖，浏览器仍显示 Nginx 默认欢迎页。

• 解决：强制覆盖（\cp 绕过别名，-f 强制）。

  \cp -rf dist/* /usr/share/nginx/html/
  chown -R nginx:nginx /usr/share/nginx/html/
  

• 验证文件

  ls -l /usr/share/nginx/html/index.html
  # 大小应为 5KB+（非默认的 3.5KB）
  

2.4 Nginx 反向代理配置

• 检查现有配置

  grep -r "location /jeecg-boot" /etc/nginx/
  # 发现 /etc/nginx/conf.d/jeecg.conf 已含 location /jeecg-boot/
  

• 配置不完整问题
  原 jeecg.conf 仅有代理部分，缺少 root 和 location /（SPA 路由支持）。
  浏览器能访问页面是因为主配置或其他 conf.d 文件有默认 root，但配置分散，不利于管理。

• 最终统一配置（建议替换 jeecg.conf 内容）

  server {
  listen 80 default_server;
  server_name _;
  root /usr/share/nginx/html;
  index index.html;
  location / {
      try_files $uri $uri/ /index.html;
  }
  location /jeecg-boot/ {
      proxy_pass http://127.0.0.1:8080/jeecg-boot/;
      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;
  }
  }
  

• 重载 Nginx

  nginx -t && nginx -s reload
  

2.5 验证前端服务

• 命令行验证

  curl -I -o /dev/null -s -w "%{http_code}\n" http://127.0.0.1/
  
  # 返回 200
  
  curl -I -o /dev/null -s -w "%{http_code}\n" http://127.0.0.1/jeecg-boot/doc.html
  
  # 返回 200
  

• 浏览器访问 http://服务器IP/，显示 JEECGBoot 登录页。

---

3、关键问题与解决方案

3.1 数据库连接失败（容器内 127.0.0.1 不可达）

报错：Connection to 127.0.0.1:5432 refused

原因：容器使用 --net host 模式下，127.0.0.1 仍指向容器自身（或解析问题），应使用 localhost。

解决：修改配置文件中的数据库 URL，将 127.0.0.1 替换为 localhost。

sed -i 's/127.0.0.1/localhost/g' application-dev.yml

---

3.2 YAML 配置文件重复键（DuplicateKeyException）

报错：org.yaml.snakeyaml.constructor.DuplicateKeyException: found duplicate key server

原因：配置文件中存在多个 server: 或 jeecg: 顶级键，Spring Boot 加载时报错。

解决：使用 yq 安全删除重复键，或手动编辑保留第一个。

# 删除重复的 server: 块（保留第一个）

yq eval 'del(select(di == 1).server)' -i application-dev.yml   # 需谨慎

# 或用 sed 脚本删除第二个出现

---

3.3 LiteFlow 初始化失败（ClassNotFoundException / 表缺失）

3.3.1 错误：ClassNotFoundException: sql

原因：配置了 liteflow.rule-source: sql，但未引入 SQL 解析依赖。

尝试方案：引入 liteflow-rule-db-sql 或 liteflow-rule-db-postgresql，但发现：

• liteflow-rule-db-sql 仅支持 MySQL/MariaDB/H2

• liteflow-rule-db-postgresql 仅在 2.16.1+ 版本可用

解决：升级 LiteFlow 版本至 2.16.1，并添加 PostgreSQL 专属依赖。

<dependency>
    <groupId>com.yomahub</groupId>
    <artifactId>liteflow-rule-db-postgresql</artifactId>
    <version>${liteflow.version}</version>
</dependency>

---

3.3.2 错误：表 "lf_chain" 不存在 或 字段 "node_id" 不存在

原因：手动创建的表结构与 LiteFlow 期望的字段不一致。

解决：使用 LiteFlow 2.16.1 官方的 PostgreSQL DDL 建表（注意字段名和类型）。

最终正确的 DDL（部分）：

CREATE TABLE lf_script (
    id BIGSERIAL PRIMARY KEY,
    application_name VARCHAR(64) NOT NULL,
    node_id VARCHAR(128) NOT NULL,          -- 关键字段
    script_name VARCHAR(128) NOT NULL,
    script_type VARCHAR(32) NOT NULL,
    script_language VARCHAR(32) NOT NULL,
    script_data TEXT NOT NULL,
    version INT DEFAULT 1,
    content_md5 VARCHAR(32),
    enable SMALLINT DEFAULT 1,
    gmt_create TIMESTAMP DEFAULT NOW(),
    gmt_modified TIMESTAMP DEFAULT NOW()
);

---

3.4 LiteFlow 配置方式选择（最终采用 Rule-DB）

推荐配置（生产环境）：

liteflow:
  rule-db:
    postgresql:
      datasource-bean-name: master   # 指定项目中主数据源名称
      # auto-init-table: true       # 如开启，需注意权限和版本

• 不推荐使用 liteflow.rule-source: liteflow-flow.xml 与 DB 模式混用。

• 不推荐使用排除自动配置 @SpringBootApplication(exclude = {...})，应正确配置。

---

3.5 源码编译与容器部署

编译命令（跳过测试）：

mvn clean package -DskipTests -Dmaven.test.skip=true -U

运行容器（挂载新 jar 和外部配置）：

docker run -d --name jeecg-app \
  --net host \
  -v /path/to/new/app.jar:/app/app.jar \
  -v /path/to/application-dev.yml:/app/application-dev.yml \
  jeecg-boot:prod \
  java -jar app.jar --spring.config.location=file:/app/application-dev.yml

---

4、常见报错汇总

报错信息	原因	解决方案
Connection refused	数据库地址配置错误	改为 localhost 或实际 IP
DuplicateKeyException	YAML 重复键	使用 yq 删除冗余
ClassNotFoundException: sql	缺少 SQL 解析依赖	引入 liteflow-rule-db-postgresql
table "lf_chain" does not exist	未建表或 schema 不对	执行官方 DDL，或添加 currentSchema=public
column "node_id" does not exist	表结构不匹配	更新表结构匹配官方 2.16.1
database [PostgreSQL] is unsupported	使用了不支持 PostgreSQL 的模块	改用 liteflow-rule-db-postgresql

---

5、经验与建议

1. 优先使用官方推荐方式：对于 LiteFlow 此类框架，严格遵循官方文档，尤其是版本对应的配置。

2. 注意依赖版本：LiteFlow 2.15.0 与 2.16.1 的 Rule-DB 模块有较大差异，务必对齐。

3. YAML 处理工具：使用 yq 代替 sed 处理 YAML，避免破坏结构。

4. 日志过滤：使用 grep -E "ERROR|WARN|Exception" 快速定位问题。

5. 备份与回滚：操作前备份数据库、配置文件、源码，确保可回退。

6. 前端构建：遇到 peer 依赖冲突时，可使用 --legacy-peer-deps 快速绕过。

7. 部署：务必使用 \cp -rf 避免交互式覆盖提示，导致文件未更新。

8. Nginx 配置：将 root 和代理放在同一个 server 块，并添加 try_files 支持 SPA 路由，避免配置分散。

9. 验证：始终通过 curl 确认后端代理连通性，再使用浏览器测试。

10. 数据库：新环境务必初始化表结构，否则登录会因表不存在而失败。

---

6、总结与教训

1. 验证结果 curl前端后端均返回200，理应正常启动并能登录系统，但是一直返回用户名密码错误。
2. 失败原因 因为了快速验证核心模块是否正常运行，改动了pom和Quartz，导致LiteFlow经常报错，并且部署前期未正确执行所需的sql脚本，导致提示各种表缺失或表字段类型报错。
3. 教训总结 之前所有部署均拉取的是3.8.3版本仓，仓中无PostgreSQL的sql建表脚本，浏览仓发现最终版本是3.8.3last，并且存在PostgreSQL的sql建表脚本，因此周一开始全部推到重来，先执行sql建表脚本，再进行编译和docker镜像，部署过程中仅修改yml文件。