JeecgBoot3.8.3信创环境深度部署实战本文档承接上一阶段总结聚焦于2026年8月16日至8月18日的第二轮深度部署过程涵盖从源码编译失败到最终稳定运行、配置模板化、备份与迁移、测试机验证的全链路实践。所有内容基于真实对话记录整理保留原始问题、解决思路、具体命令及最终效果。由于工作原因导致疏忽仅保存草稿未发表现补发致歉后续会根据工作情况逐步调整更新节奏和内容敬请谅解一、实战目标1.1 核心目标在 openEuler 24.03 服务器上完成 JeecgBoot 3.8.3 后端的稳定部署并实现✅ 启用 AI 模块Liteflow AI 聊天✅ 使用 PostgreSQL 替代 MySQL✅ 配置文件脱敏并模板化便于多环境复用✅ 构建可一键部署的备份包含所有依赖、JAR、配置、脚本✅ 在另一台测试机上验证部署包的可移植性二、部署环境项目生产服务器源测试服务器目标操作系统openEuler 24.03 LTS SP4openEuler 24.03 LTS SP4全新安装CPUIntel Xeon同左x86_64内存128GB8GB测试机内核6.6.0-159.4.3.154.oe2403sp4.x86_64同左JDK17.0.11 (BiSheng)17.0.11通过备份包安装PostgreSQL15.615.6RPM 安装Redis7.2.57.2.5Docker26.1.3未使用未安装备份包版本jeecg-full-20260818.tar.gz同左三、核心问题与解决路径3.1 编译与依赖问题延续上一阶段问题1找不到ISysBaseApi、SysUserDepartVO等核心类现象jeecg-system-biz模块编译时大量报错提示程序包org.jeecg.common.system.api不存在。原因分析JeecgBoot 3.8.3 已将通用接口移至jeecg-boot-base-core模块中的CommonAPI。pom.xml中缺少对jeecg-system-local-api的正确依赖且javax.annotation-api未引入JDK 17 移除。解决思路修改SysBaseApiImpl.java将implements ISysBaseApi改为implements CommonAPI。在pom.xml中添加javax.annotation-api和jeecg-system-local-api依赖。具体操作bash# 修改 Java 文件 perl -i -pe s/implements ISysBaseApi/implements CommonAPI/g SysBaseApiImpl.java perl -i -pe s/import org\.jeecg\.common\.system\.api\.ISysBaseApi;/import org.jeecg.common.api.CommonAPI;/g SysBaseApiImpl.javaxml!-- pom.xml 添加 -- dependency groupIdjavax.annotation/groupId artifactIdjavax.annotation-api/artifactId version1.3.2/version /dependency dependency groupIdorg.jeecgframework.boot3/groupId artifactIdjeecg-system-local-api/artifactId /dependency预期效果编译不再报错。实际结果编译通过后续启动正常。3.2 YAML 配置文件格式问题问题2多次手动修改导致 YAML 格式损坏现象启动时抛出ScannerException: mapping values are not allowed here或DuplicateKeyException。原因使用sed直接替换文本破坏了缩进和键值结构。解决思路放弃sed改用专用 YAML 工具yq进行所有修改。具体操作bash# 安装 yq wget https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64 -O /usr/local/bin/yq chmod x /usr/local/bin/yq # 修改数据库密码 yq eval .spring.datasource.dynamic.datasource.master.password postgres123 -i application-dev.yml # 添加 primary 数据源 yq eval .spring.datasource.dynamic.primary master -i application-dev.yml # 删除 Quartz JDBC 配置 yq eval del(.spring.quartz.jdbc) -i application-dev.yml预期效果YAML 格式始终正确。实际结果后续所有 YAML 操作均使用yq再无格式错误。3.3 Quartz 定时任务配置问题3Quartz 报错No local DataSource found现象启动失败提示SchedulerConfigException: No local DataSource found for configuration - dataSource property must be set。原因Quartz 默认使用 JDBC 存储需要数据库表但配置不完整或表不存在。解决思路改为内存模式RAMJobStore避免数据库依赖。具体操作在application-dev.yml中设置spring.quartz.job-store-type: memory。删除spring.quartz.jdbc和spring.quartz.properties块。启动时添加参数bash--spring.quartz.job-store-typememory \ --spring.quartz.properties.org.quartz.jobStore.classorg.quartz.simpl.RAMJobStore \ --spring.quartz.auto-startupfalse预期效果Quartz 使用内存存储无需建表。实际结果Quartz 成功初始化应用正常启动。3.4 LiteflowAI 模块配置问题4Liteflow 报错You did not define the applicationName property现象启动时 Liteflow 抛出ELSQLException提示缺少applicationName和chainTableName。原因Liteflow 的rule-source-ext-data中未指定这两个必要字段。解决思路在 JSON 扩展数据中补齐applicationName和chainTableName并确保airag_flow表存在且包含示例数据。具体操作bashyq eval .liteflow.rule-source-ext-data {\dataSourceName\:\master\,\applicationName\:\jeecg-boot\,\chainTableName\:\airag_flow\} -i application-dev.ymlsqlCREATE TABLE airag_flow ( id VARCHAR(36) PRIMARY KEY, application_name VARCHAR(255), chain_name VARCHAR(255), el_data TEXT, status VARCHAR(20) DEFAULT enable, create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); INSERT INTO airag_flow (id, application_name, chain_name, el_data, status) VALUES (1, jeecg-boot, default, THEN(start, end), enable);预期效果Liteflow 成功加载流程定义。实际结果AI 模块正常启用流程相关接口可用。3.5 配置文件脱敏与模板化问题5配置文件包含明文密码不适合公开分享解决思路只替换密码和用户名保留所有 IP、端口、邮箱等默认值不变。使用{{VAR}}占位符配合envsubst生成最终配置。具体操作从原始配置复制模板bashcp application-dev.yml.original application-dev-template.yml sed -i s/password: postgres123/password: {{DB_PASSWORD}}/g application-dev-template.yml sed -i s/password: jeecg1314/password: {{JM_PASSWORD}}/g application-dev-template.yml sed -i s/username: postgres/username: {{DB_USER}}/g application-dev-template.yml sed -i s/username: jeecg/username: {{JM_USER}}/g application-dev-template.yml # AI-RAG 部分单独处理 sed -i /ai-rag:/,/^[^ ]/ s/user: postgres/user: {{AI_DB_USER}}/ application-dev-template.yml sed -i /ai-rag:/,/^[^ ]/ s/password: postgres/password: {{AI_DB_PASSWORD}}/ application-dev-template.yml创建env.sh存放默认值bashexport DB_PASSWORDpostgres123 export JM_PASSWORDjeecg1314 export DB_USERpostgres export JM_USERjeecg export AI_DB_USERpostgres export AI_DB_PASSWORDpostgres创建generate-config.shbashcat application-dev-template.yml | sed -E s/\{\{([A-Z_])\}\}/\$\1/g | envsubst application-dev.yml预期效果敏感信息被占位符替代可安全上传至 Gitee。实际结果模板与原始配置diff无差异脱敏成功。3.6 备份包制作与传输问题6如何制作可离线部署的完整备份解决思路收集所有系统依赖 RPM 包JDK17、PostgreSQL、Redis、Nginx、Maven、Git 等。备份 JAR 包、配置模板、部署脚本、Nginx 配置文件。编写一键安装/恢复脚本含 JDK 切换、数据库初始化、建表、启动服务。打包为jeecg-full-$(date %Y%m%d).tar.gz。具体操作生产服务器bashmkdir -p /data/backup/rpms dnf download $(dnf repoquery --installed | grep -E java-17|postgresql|redis|nginx|git|maven) --destdir/data/backup/rpms/ cp /usr/local/bin/yq /data/backup/rpms/ cp /data/jeecg-boot-3.8.3-stable-20260817/jeecg-system-start-3.8.3.jar /data/backup/ cp /etc/nginx/conf.d/jeecg.conf /data/backup/nginx-jeecg.conf # 创建 01-06 分步脚本见下文 cd /data tar -czf jeecg-full-20260818.tar.gz backup/分步脚本摘要01-install-deps.sh从本地 RPM 或在线源安装依赖。02-setup-java.sh切换默认 Java 为 17。03-init-db.sh初始化 PostgreSQL创建数据库和airag_flow表。04-start-redis.sh启动并启用 Redis。05-deploy-app.sh复制 JAR、生成配置、启动后端。06-setup-nginx.sh恢复 Nginx 反向代理配置。传输到本地 F 盘Windows PowerShellpowershellscp rootIP:/data/jeecg-full-20260818.tar.gz F:\预期效果新服务器解压后执行脚本即可完成完整部署。实际结果在测试机成功恢复环境并启动服务。3.8 测试机一键部署验证问题8测试机原系统存在 PagePlug 干扰现象访问 8080 端口显示 PagePlug 页面而非 JeecgBoot。原因测试机之前运行过 PagePlug Docker 容器占用了端口或代理。解决清理 Docker 容器和镜像停止旧服务。bashdocker stop $(docker ps -aq) 2/dev/null docker rm $(docker ps -aq) 2/dev/null docker rmi $(docker images -q) 2/dev/null systemctl stop nginx pkill -f jeecg-system-start预期效果8080 端口仅由 JeecgBoot 使用。实际结果清理后 JeecgBoot 正常响应。四、我的观点与策略阶段观点依据初始使用最新版 3.8.3启用 AI 模块功能完整符合未来需求遇到编译困难不轻易降级死磕依赖问题AI 模块是核心亮点放弃可惜配置管理坚持配置外置、模板化、变量化便于多环境部署和版本控制备份策略制作全量离线备份包应对内网环境实现“解压即用”文档记录每一步都记录命令和结果为后续复盘和分享做准备五、最终状态总结项目状态说明生产服务器后端✅ 稳定运行进程持续运行Swagger 可访问AI 模块✅ 已启用Liteflow 成功加载airag_flow表存在配置模板✅ 已脱敏并上传 Gitee含 MIT 许可证可公开备份包✅ 已制作并下载本地包含所有依赖和脚本测试机恢复成功测试机部署✅ 成功通过备份包一键部署服务正常启动文章准备✅ 完成 CSDN 和知乎版本分别面向技术实操和观点分享六、关键命令速查bash# 查看后端进程 ps aux | grep jeecg-system-start | grep -v grep # 检查端口监听 ss -tlnp | grep 8080 # 测试接口 curl -I http://localhost:8080/jeecg-boot/doc.html # 修改 YAML推荐 yq yq eval .path.to.key value -i file.yml # 生成配置模板化 cat template.yml | sed -E s/\{\{([A-Z_])\}\}/\$\1/g | envsubst config.yml # 打包备份 tar -czf jeecg-full-$(date %Y%m%d).tar.gz backup/ # 传输备份 scp jeecg-full-*.tar.gz root目标IP:/root/七、经验与教训工具选型至关重要yq替代sed处理 YAML避免了 90% 的格式错误。环境隔离使用envsubst实现配置模板化环境差异只需修改env.sh。备份包策略将系统依赖、JAR、脚本、配置统一打包新服务器部署时间从 2 天缩短至 20 分钟。渐进式验证先在宿主机编译运行再制作备份包最后在测试机验证确保每一步可控。文档驱动记录每一条命令和报错后续复盘和写作时极大节省时间。八、后续建议若需要前端部署可参考官方 Vue3 构建方案同样使用 Nginx 代理。建议将备份包存放在内网仓库供后续服务器批量部署。若 AI 模块后续升级可只更新 JAR 包和airag_flow表结构无需重新部署环境。
JeecgBoot3.8.3信创环境深度部署实战
JeecgBoot3.8.3信创环境深度部署实战本文档承接上一阶段总结聚焦于2026年8月16日至8月18日的第二轮深度部署过程涵盖从源码编译失败到最终稳定运行、配置模板化、备份与迁移、测试机验证的全链路实践。所有内容基于真实对话记录整理保留原始问题、解决思路、具体命令及最终效果。由于工作原因导致疏忽仅保存草稿未发表现补发致歉后续会根据工作情况逐步调整更新节奏和内容敬请谅解一、实战目标1.1 核心目标在 openEuler 24.03 服务器上完成 JeecgBoot 3.8.3 后端的稳定部署并实现✅ 启用 AI 模块Liteflow AI 聊天✅ 使用 PostgreSQL 替代 MySQL✅ 配置文件脱敏并模板化便于多环境复用✅ 构建可一键部署的备份包含所有依赖、JAR、配置、脚本✅ 在另一台测试机上验证部署包的可移植性二、部署环境项目生产服务器源测试服务器目标操作系统openEuler 24.03 LTS SP4openEuler 24.03 LTS SP4全新安装CPUIntel Xeon同左x86_64内存128GB8GB测试机内核6.6.0-159.4.3.154.oe2403sp4.x86_64同左JDK17.0.11 (BiSheng)17.0.11通过备份包安装PostgreSQL15.615.6RPM 安装Redis7.2.57.2.5Docker26.1.3未使用未安装备份包版本jeecg-full-20260818.tar.gz同左三、核心问题与解决路径3.1 编译与依赖问题延续上一阶段问题1找不到ISysBaseApi、SysUserDepartVO等核心类现象jeecg-system-biz模块编译时大量报错提示程序包org.jeecg.common.system.api不存在。原因分析JeecgBoot 3.8.3 已将通用接口移至jeecg-boot-base-core模块中的CommonAPI。pom.xml中缺少对jeecg-system-local-api的正确依赖且javax.annotation-api未引入JDK 17 移除。解决思路修改SysBaseApiImpl.java将implements ISysBaseApi改为implements CommonAPI。在pom.xml中添加javax.annotation-api和jeecg-system-local-api依赖。具体操作bash# 修改 Java 文件 perl -i -pe s/implements ISysBaseApi/implements CommonAPI/g SysBaseApiImpl.java perl -i -pe s/import org\.jeecg\.common\.system\.api\.ISysBaseApi;/import org.jeecg.common.api.CommonAPI;/g SysBaseApiImpl.javaxml!-- pom.xml 添加 -- dependency groupIdjavax.annotation/groupId artifactIdjavax.annotation-api/artifactId version1.3.2/version /dependency dependency groupIdorg.jeecgframework.boot3/groupId artifactIdjeecg-system-local-api/artifactId /dependency预期效果编译不再报错。实际结果编译通过后续启动正常。3.2 YAML 配置文件格式问题问题2多次手动修改导致 YAML 格式损坏现象启动时抛出ScannerException: mapping values are not allowed here或DuplicateKeyException。原因使用sed直接替换文本破坏了缩进和键值结构。解决思路放弃sed改用专用 YAML 工具yq进行所有修改。具体操作bash# 安装 yq wget https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64 -O /usr/local/bin/yq chmod x /usr/local/bin/yq # 修改数据库密码 yq eval .spring.datasource.dynamic.datasource.master.password postgres123 -i application-dev.yml # 添加 primary 数据源 yq eval .spring.datasource.dynamic.primary master -i application-dev.yml # 删除 Quartz JDBC 配置 yq eval del(.spring.quartz.jdbc) -i application-dev.yml预期效果YAML 格式始终正确。实际结果后续所有 YAML 操作均使用yq再无格式错误。3.3 Quartz 定时任务配置问题3Quartz 报错No local DataSource found现象启动失败提示SchedulerConfigException: No local DataSource found for configuration - dataSource property must be set。原因Quartz 默认使用 JDBC 存储需要数据库表但配置不完整或表不存在。解决思路改为内存模式RAMJobStore避免数据库依赖。具体操作在application-dev.yml中设置spring.quartz.job-store-type: memory。删除spring.quartz.jdbc和spring.quartz.properties块。启动时添加参数bash--spring.quartz.job-store-typememory \ --spring.quartz.properties.org.quartz.jobStore.classorg.quartz.simpl.RAMJobStore \ --spring.quartz.auto-startupfalse预期效果Quartz 使用内存存储无需建表。实际结果Quartz 成功初始化应用正常启动。3.4 LiteflowAI 模块配置问题4Liteflow 报错You did not define the applicationName property现象启动时 Liteflow 抛出ELSQLException提示缺少applicationName和chainTableName。原因Liteflow 的rule-source-ext-data中未指定这两个必要字段。解决思路在 JSON 扩展数据中补齐applicationName和chainTableName并确保airag_flow表存在且包含示例数据。具体操作bashyq eval .liteflow.rule-source-ext-data {\dataSourceName\:\master\,\applicationName\:\jeecg-boot\,\chainTableName\:\airag_flow\} -i application-dev.ymlsqlCREATE TABLE airag_flow ( id VARCHAR(36) PRIMARY KEY, application_name VARCHAR(255), chain_name VARCHAR(255), el_data TEXT, status VARCHAR(20) DEFAULT enable, create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); INSERT INTO airag_flow (id, application_name, chain_name, el_data, status) VALUES (1, jeecg-boot, default, THEN(start, end), enable);预期效果Liteflow 成功加载流程定义。实际结果AI 模块正常启用流程相关接口可用。3.5 配置文件脱敏与模板化问题5配置文件包含明文密码不适合公开分享解决思路只替换密码和用户名保留所有 IP、端口、邮箱等默认值不变。使用{{VAR}}占位符配合envsubst生成最终配置。具体操作从原始配置复制模板bashcp application-dev.yml.original application-dev-template.yml sed -i s/password: postgres123/password: {{DB_PASSWORD}}/g application-dev-template.yml sed -i s/password: jeecg1314/password: {{JM_PASSWORD}}/g application-dev-template.yml sed -i s/username: postgres/username: {{DB_USER}}/g application-dev-template.yml sed -i s/username: jeecg/username: {{JM_USER}}/g application-dev-template.yml # AI-RAG 部分单独处理 sed -i /ai-rag:/,/^[^ ]/ s/user: postgres/user: {{AI_DB_USER}}/ application-dev-template.yml sed -i /ai-rag:/,/^[^ ]/ s/password: postgres/password: {{AI_DB_PASSWORD}}/ application-dev-template.yml创建env.sh存放默认值bashexport DB_PASSWORDpostgres123 export JM_PASSWORDjeecg1314 export DB_USERpostgres export JM_USERjeecg export AI_DB_USERpostgres export AI_DB_PASSWORDpostgres创建generate-config.shbashcat application-dev-template.yml | sed -E s/\{\{([A-Z_])\}\}/\$\1/g | envsubst application-dev.yml预期效果敏感信息被占位符替代可安全上传至 Gitee。实际结果模板与原始配置diff无差异脱敏成功。3.6 备份包制作与传输问题6如何制作可离线部署的完整备份解决思路收集所有系统依赖 RPM 包JDK17、PostgreSQL、Redis、Nginx、Maven、Git 等。备份 JAR 包、配置模板、部署脚本、Nginx 配置文件。编写一键安装/恢复脚本含 JDK 切换、数据库初始化、建表、启动服务。打包为jeecg-full-$(date %Y%m%d).tar.gz。具体操作生产服务器bashmkdir -p /data/backup/rpms dnf download $(dnf repoquery --installed | grep -E java-17|postgresql|redis|nginx|git|maven) --destdir/data/backup/rpms/ cp /usr/local/bin/yq /data/backup/rpms/ cp /data/jeecg-boot-3.8.3-stable-20260817/jeecg-system-start-3.8.3.jar /data/backup/ cp /etc/nginx/conf.d/jeecg.conf /data/backup/nginx-jeecg.conf # 创建 01-06 分步脚本见下文 cd /data tar -czf jeecg-full-20260818.tar.gz backup/分步脚本摘要01-install-deps.sh从本地 RPM 或在线源安装依赖。02-setup-java.sh切换默认 Java 为 17。03-init-db.sh初始化 PostgreSQL创建数据库和airag_flow表。04-start-redis.sh启动并启用 Redis。05-deploy-app.sh复制 JAR、生成配置、启动后端。06-setup-nginx.sh恢复 Nginx 反向代理配置。传输到本地 F 盘Windows PowerShellpowershellscp rootIP:/data/jeecg-full-20260818.tar.gz F:\预期效果新服务器解压后执行脚本即可完成完整部署。实际结果在测试机成功恢复环境并启动服务。3.8 测试机一键部署验证问题8测试机原系统存在 PagePlug 干扰现象访问 8080 端口显示 PagePlug 页面而非 JeecgBoot。原因测试机之前运行过 PagePlug Docker 容器占用了端口或代理。解决清理 Docker 容器和镜像停止旧服务。bashdocker stop $(docker ps -aq) 2/dev/null docker rm $(docker ps -aq) 2/dev/null docker rmi $(docker images -q) 2/dev/null systemctl stop nginx pkill -f jeecg-system-start预期效果8080 端口仅由 JeecgBoot 使用。实际结果清理后 JeecgBoot 正常响应。四、我的观点与策略阶段观点依据初始使用最新版 3.8.3启用 AI 模块功能完整符合未来需求遇到编译困难不轻易降级死磕依赖问题AI 模块是核心亮点放弃可惜配置管理坚持配置外置、模板化、变量化便于多环境部署和版本控制备份策略制作全量离线备份包应对内网环境实现“解压即用”文档记录每一步都记录命令和结果为后续复盘和分享做准备五、最终状态总结项目状态说明生产服务器后端✅ 稳定运行进程持续运行Swagger 可访问AI 模块✅ 已启用Liteflow 成功加载airag_flow表存在配置模板✅ 已脱敏并上传 Gitee含 MIT 许可证可公开备份包✅ 已制作并下载本地包含所有依赖和脚本测试机恢复成功测试机部署✅ 成功通过备份包一键部署服务正常启动文章准备✅ 完成 CSDN 和知乎版本分别面向技术实操和观点分享六、关键命令速查bash# 查看后端进程 ps aux | grep jeecg-system-start | grep -v grep # 检查端口监听 ss -tlnp | grep 8080 # 测试接口 curl -I http://localhost:8080/jeecg-boot/doc.html # 修改 YAML推荐 yq yq eval .path.to.key value -i file.yml # 生成配置模板化 cat template.yml | sed -E s/\{\{([A-Z_])\}\}/\$\1/g | envsubst config.yml # 打包备份 tar -czf jeecg-full-$(date %Y%m%d).tar.gz backup/ # 传输备份 scp jeecg-full-*.tar.gz root目标IP:/root/七、经验与教训工具选型至关重要yq替代sed处理 YAML避免了 90% 的格式错误。环境隔离使用envsubst实现配置模板化环境差异只需修改env.sh。备份包策略将系统依赖、JAR、脚本、配置统一打包新服务器部署时间从 2 天缩短至 20 分钟。渐进式验证先在宿主机编译运行再制作备份包最后在测试机验证确保每一步可控。文档驱动记录每一条命令和报错后续复盘和写作时极大节省时间。八、后续建议若需要前端部署可参考官方 Vue3 构建方案同样使用 Nginx 代理。建议将备份包存放在内网仓库供后续服务器批量部署。若 AI 模块后续升级可只更新 JAR 包和airag_flow表结构无需重新部署环境。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
