做后台管理系统重要的不是界面有多炫而是业务能不能真正串成一条完整的线。最近我在维护一套办公ERP管理系统后端用Spring Boot搭起的JavaWeb工程前端用EasyUI加原生HTML写管理界面数据落在MySQL里依赖由Maven统一管理覆盖了从审批协同到采购、库存、销售的日常经营流程。整个过程走下来感觉这套组合虽然不算新潮却非常务实——只要理解了它的骨架就能快速应对企业中后台系统的大多数需求。这篇文章主要面向两类人一是刚学完JavaWeb基础、想接触真实业务系统的同学二是正在做企业内部信息化项目、需要一套可落地参考方案的工程师。我会把项目的模块设计、数据库表关系、权限控制、前后端集成细节、部署流程和实际踩过的坑都摊开来讲尽量做到能照着文档复现。1. 项目概述办公ERP到底在管哪些事1.1 系统定位与解决的业务问题办公ERP这两个词放在一起容易让人误以为是个什么都能装的“大杂烩系统”。实际上办公指的是协同办公比如请假审批、报销申请、公告通知、待办任务ERP则偏向企业资源计划比如供应商管理、采购订单、物料库存、销售发货。两者结合就成了一个中小型企业内部流转的主干线人走审批流程物走库存流程钱跟着订单和单据走。我接触的这个项目业务场景设定在某类中小型制造企业里。这类企业不像大厂有那么复杂的组织架构但日常管理同样有一个绕不开的痛点单据分散在纸质、Excel和个人微信里。采购员下单靠口头仓管员发货靠感觉老板想看当月的采购总额、销售回款还得让财务手工汇总好几天。这套系统要解决的就是把“人、事、单、物”统一收口到一个平台上让每一个动作都有记录、有状态、有归属人。1.2 功能模块总览系统按业务域划分大致有七个核心模块模块名称主要功能业务对象系统管理用户、角色、菜单、部门、按钮权限后台基础数据协同办公请假、报销、用章申请与审批流审批单据采购管理供应商档案、采购订单、采购入库供应商、采购单库存管理物料档案、出入库、库存台账、盘点物料、库存流水销售管理客户档案、销售订单、发货出库客户、销售单生产任务生产工单、领料出库、完工入库工单、物料消息中心待办提醒、通知公告、操作日志消息、日志这些模块不是孤立的。比如销售订单审核通过后会自动生成一条生产任务生产任务开工时工人领料会扣减原料库存采购到货后入库库存增加同时关联到采购订单的入库状态。这种“单据驱动库存”的模型才是ERP和普通增删改查系统最本质的区别。1.3 与普通CRUD演示项目的差异网上能搜到大量的后台管理系统模板点开就是一个用户列表加几个表单看似什么都有其实什么都没有。这类项目有个共性缺点表和表之间是松散的用户在用户表订单在订单表两者之间没有业务约束删一个用户不会影响任何单据。而这套办公ERP的设计重点不在增删改查本身而在于单据状态流转、权限数据范围和库存数据的一致性。理解了这一点后面看表结构、看代码逻辑的时候思路会完全不一样。2. 技术选型拆解为什么是这套组合2.1 Spring Boot从传统JavaWeb到自动化配置标题中的“javaweb”不是随便写的。理解Spring Boot最好先理解它对传统JavaWeb的演进。过去开发一个Servlet项目要手动建Servlet类、写web.xml、配置监听器、处理字符编码、配置数据库连接池光环境搭建就能耗掉一两天。Spring Boot把这些重复性的配置自动化了内嵌了Tomcat容器一个Application类启动后整个应用就跑起来了但底层仍然是基于Servlet规范的JavaWeb应用。选Spring Boot而不是继续用传统的SSM框架手写配置原因很实际后续要接API接口、要做定时任务、要打不同环境的部署包自动配置能省下大量时间。而且Spring Boot的生态已经非常成熟出问题随便一查就有解决方案。对一个小型ERP系统来说用Spring Boot天然就比手动拼SSM要稳。2.2 EasyUI老牌后台组件库的实用价值很多人看到EasyUI会觉得不够时髦毕竟现在前端都玩Vue和React了。但这个项目选择EasyUI有它的道理。首先EasyUI是完全以jQuery为基础的引入一个jquery.easyui.min.js和一个样式文件在HTML里写class和data-options就能出效果不需要Node.js环境不需要打包构建。其次系统是纯后台管理界面Datagrid表格、Tree树、Dialog对话框、Messager消息提示这几个组件基本覆盖了90%的页面需求而这些恰恰是EasyUI最成熟的组件。换句话说对这个项目来说前端最核心的价值是稳定和快速产出而不是复杂的交互动效。用EasyUI还有一个附带的好处后端返回的JSON只要按固定格式组织Datagrid能直接解析渲染分页、排序都有现成接口少写大量JavaScript。2.3 Maven依赖与构建的“统一管家”一个ERP系统后端会用到很多第三方库Spring Boot相关依赖、MyBatis、MySQL驱动、Druid连接池、FastJSON等等。如果不借助Maven光是把这些jar包下载全、版本对应上就是一件让人头疼的事。Maven通过pom.xml统一管理依赖坐标和版本项目克隆下来后执行一条mvn命令就能下载全部依赖并完成构建。除依赖管理外Maven还有两个优势是实际开发中真正离不开的。一是多环境打包通过profile可以将开发环境、测试环境、生产环境的配置分离打包时指定环境即可二是项目结构规范源码、资源文件、测试代码各归其位团队协作时不会出现谁把配置文件放错目录的问题。2.4 MySQL轻量可靠的业务数据中枢选择MySQL而不是其它数据库核心考量是成本和团队熟悉度。中小型ERP的并发量并没有想象中那么大MySQL的InnoDB存储引擎在事务支持上已经足够可靠配合主键索引和查询优化能够满足日常业务需求。使用MySQL时有几个细节值得注意。字符集要统一设为utf8mb4这能支持存储生僻字和部分特殊符号避免中文乱码表设计尽量用InnoDB并且明确主键MyISAM虽然在某些读场景下快但ERP系统对事务完整性要求高遇到单据和库存的更新操作必须支持行级锁数据库连接参数中要加上useSSLfalse和serverTimezoneAsia/Shanghai否则在新版本驱动下连本地库都会报错。3. 核心功能模块设计与业务流转3.1 组织、用户与RBAC权限模型一个企业内部系统的第一件事不是写业务功能而是把组织架构理清楚。用户、部门、角色、菜单这四者构成了权限控制的基础。用户挂在部门下用户再关联角色角色关联菜单和按钮权限。这套模型就是RBAC基于角色的访问控制简单、好理解又能覆盖大多数后台系统的权限需求。我设计的具体表关系是用户表保存账号、密码摘要、姓名、部门ID、状态角色表保存角色编码、角色名称比如“admin”“采购主管”“仓库员”用户角色关联表一个用户可多角色一个角色可多用户多对多菜单表系统目录和功能页面用树形结构保存父子关系额外有菜单类型目录/页面/按钮、路由地址、权限标识角色菜单关联表角色能访问哪些菜单、按钮全在这里过滤。权限控制的粒度要到位尤其按钮权限。如果只控制到菜单级别用户进了采购订单页面可能把“删除”“审核”按钮也看得到这在实际业务中是绝对不行的。所以菜单表里要区分页面节点和按钮节点按钮节点的权限标识类似于purchase:order:audit后端拦截器在用户调用审核接口时校验该权限标识不在列表中就直接拒绝。3.2 审批流的简化设计与状态机办公模块中审批是核心。请假、报销、用章申请本质上都是同一种流程申请人提交单据上级或指定角色审批通过或驳回。真实的ERP可能会引入工作流引擎但中小型系统用一张“业务类型”字段加上状态机就能解决大部分需求。以请假单为例我设计了三张核心表申请表主键、单据编号、申请类型leave/reimburse/stamp、申请人ID、申请内容、表单JSON、当前状态、当前处理人、创建时间表单明细表扩展字段比如请假类型、开始时间、结束时间、天数、事由或者报销费用明细、附件路径审批记录表每次审批动作都写入一条记录包含审批人、审批结果同意/驳回、审批意见、审批时间。审批状态我使用数字状态机表达0草稿、1审批中、2已通过、3已驳回、4已撤销。当前处理人字段很关键保存的是下一步该谁来处理。用户登录后首页待办数量其实就是查当前处理人等于自己的申请单数量。驳回时当前处理人回退到申请人同时状态变为已驳回等待申请人修改后重新提交。这个设计的优点是效率高缺点是复杂的会签、并行审批做不了。如果后续真有并行审批需求可以把“当前处理人”扩展为“审批流转节点表”但业务量不大的前提下简单方案往往更稳定。3.3 采购到入库的业务闭环采购模块是ERP的典型入口。业务主线的起点是需求终点是入库和应付账款的产生。简化后的流程是业务员选择供应商、填写采购订单明细表记录物料、数量、单价、提交审核、审核通过后订单状态变为已确认、后续到货时做采购入库单。采购订单和供应商是父子关系供应商必须先在供应商档案中维护不能直接录入名字。这样做的目的是保证后续统计供应商到货情况、退货比例时数据是结构化的而不是一个自由文本。采购订单明细里的数量字段一定要用Decimal不能用Double或Float否则累计到一定数量会出现精度偏差金额对不上。采购入库时逻辑上要确保两点一是入库数量不能超过订单剩余未入库数量防止超收二是入库完成后同步生成库存出入库流水记录库存台账数量同步增加。这两个动作必须在同一个数据库事务里完成任何一个失败都要回滚否则就会出现“单据写了但库存没变”的脏数据。3.4 库存台账与出入库流水库存管理是整个ERP系统中复杂度最高的部分。物料档案不需要多说重点在于两张表的设计库存台账表和库存流水表。库存台账表保存的是某一物料在当前仓库的结存数量本质是一个快照库存流水表则记录每一次数量变动的明细包括变动类型采购入库、销售出库、领料出库、盘盈、盘亏、变动前数量、变动数量、变动后数量、关联单据编号、操作人。这样的设计能实现两件事第一追账。任何一次库存数量变化都能在流水表中找到来源单据是哪个订单、哪个工单导致的出了问题可追溯第二对账。盘点时如果台账数量与实物不一致通过流水可以还原整个变化过程定位是漏记还是重复登记。并发问题是库存操作最需要防范的。两个车间同时领同一种原料如果程序先查库存再减库存高并发下会出现超领。解决这个问题最简单可靠的方式是使用数据库行锁在更新语句中直接加上FOR UPDATE或者用UPDATE库存SET数量数量-? WHERE物料ID? AND数量?这样的原子操作让数据库自己判断。后一种方式不仅能防超领还能省掉一次查询我实际项目中更推荐这种做法。3.5 销售订单到发货出库销售侧的业务与采购侧是对称的。客户录入客户档案销售员创建销售订单订单审核后根据交货日期做发货单发货单提交后扣减库存同时记录应收款。与采购入库类似发货出库的扣减也要走原子更新加流水记录。有一点值得单独提出来销售订单如果因为客户取消而终止不能直接删订单而要做一个“关闭”操作。在订单状态字段中增加一个“已关闭”的状态值。这样设计第一是为了保留历史数据第二是防止报表统计时金额凭空蒸发。财务对账时无论订单取消还是部分发货每一步都有状态记录才能给出可信的销售统计。3.6 消息中心与待办机制消息中心虽然不显眼却直接影响系统的好用程度。审批人不可能一直盯着系统看必须靠消息推动。我的实现方式不复杂业务单据状态发生变化时向消息表插入一条待办消息接收人为下一节点处理人用户登录后首页右上角展示未读消息数点击消息列表可以直接跳转到对应单据处理页面。通知公告则按照组织层级下发可以在发布时指定接收部门或指定角色已读状态单独记录。虽然实现起来只是一张消息表加已读标记但这个模块把系统的“被动等待”变成了“主动推送”上线后用户的接受度马上不一样。4. 数据库设计要点与关键SQL4.1 核心表清单与作用整个系统的数据库表可以归为几类。基础数据类sys_user、sys_role、sys_menu、sys_user_role、sys_role_menu、sys_dept协同办公类oa_apply、oa_apply_detail、oa_approve_record采购库存销售类base_supplier、base_material、base_customer、pur_purchase_order、pur_purchase_order_item、pur_stock_in、inv_inventory、inv_stock_flow、sal_sales_order、sal_delivery生产类prd_work_order、prd_work_order_item。总共二十多张表每个表都要有主键、创建时间、更新时间这些通用字段。表设计上我有一个习惯所有业务单据都使用独立的单号字段比如“PO202501001”而不是只用自增主键。原因有三个一是业务人员线下沟通时习惯用单号二是自增主键容易被猜测遍历存在越权风险三是财务审计时要能识别单据类型和日期。4.2 状态字段与数据一致性约束在设计任何一位业务表时都不要只给一个“状态”字段还要给“业务类型”和“当前处理人”概念。比如采购订单的状态至少包含草稿、待审核、已审核、已入库、已关闭。状态之间的流转要在代码里控制不能允许用户从前端任意跳转状态。我采取的方法是所有状态变更操作都统一走Service层的“变更状态”方法入参为单据ID、目标状态、操作人方法内部先校验当前状态是否允许流转再更新。跨表数据一致性方面我基本不使用数据库物理外键。ERP系统写入频率高物理外键的性能开销在数据量上来后会变得明显而且后期想要调整表结构会很麻烦。一致性靠的是“事务程序校验”数据库层面只建必要索引比如每个订单明细表的订单ID索引、流水表的物料ID和时间索引。4.3 关键查询与事务脚本示例库存扣减用原子更新是并发场景下的核心SQL。下面这段是物料领料出库时的核心操作-- 原子扣减库存数量不小于领用数量时才允许更新 UPDATE inv_inventory SET stock_qty stock_qty - #{outQty} WHERE material_id #{materialId} AND warehouse_id #{warehouseId} AND stock_qty #{outQty};如果影响行数为0说明库存不足或物料不存在程序立即抛异常回滚整个事务。这个写法比“先SELECT再UPDATE”多了一重天然屏障能有效避免两个人同时领料导致的超领。每月采购汇总统计可以用下面这个查询SELECT DATE_FORMAT(create_time, %Y-%m) AS month, COUNT(DISTINCT order_id) AS order_cnt, SUM(total_amount) AS total_amount FROM pur_purchase_order WHERE status ! 已关闭 AND create_time DATE_SUB(CURDATE(), INTERVAL 12 MONTH) GROUP BY DATE_FORMAT(create_time, %Y-%m) ORDER BY month;这类SQL就是报表模块的数据来源。实际项目里不要直接把报表查询放到业务代码里拼SQL拆成独立的统计Service通过定时任务或点击报表页面时实时计算即可。4.4 索引与查询性能优化ERP系统用得越久业务表的数据量增长越快。以库存流水表为例一天生产领料几百上千条一年就是几十万条如果查询不加条件直接刷全表页面会卡到无法使用。我针对高频查询场景建的索引主要包括库存流水表的物料ID、创建时间联合索引采购订单明细表的订单ID索引销售订单表的客户ID索引审批记录表的申请单ID索引。与此同时列表页默认加载只查最近三个月的数据系统提供时间范围选择避免一次性渲染过多。分页查询配合索引实际使用中基本没有出现慢SQL超过一秒的情况。5. 后端架构与关键实现5.1 项目分层与包结构后端代码包结构我习惯这样划分controller接收前端请求负责参数校验的入口和请求转发service业务逻辑事务边界都在这一层mapperMyBatis的Mapper接口一个接口对应一个XML或注解SQLentity数据库表对应的实体类vo视图对象不直接暴露数据库实体给前端common统一返回结果、常量、异常处理器、工具类。这套分层看起来是老生常谈但它在实际维护中有两个明显好处。第一事务只加在Service层避免事务范围过大导致数据库锁时间过长第二当某个接口结构变化时只需要改Controller层组装逻辑不需要动底层SQL。值得强调的一个细节是前端需要的列表页面通常不只是单表数据。比如采购订单列表页除了订单主表字段还要展示供应商名称、创建人姓名、订单总金额。如果直接返回Entity对象很多字段是没用的甚至有安全隐患。所以我为列表页专门设计了VO对象把关联查询的冗余字段直接放在VO里SQL通过联表一次查出来减少循环查库。5.2 统一返回结构与全局异常处理前端EasyUI的Datagrid对后台返回格式有固定要求分页查询必须返回total和rows两个字段普通操作则期望code、msg、data的格式。为了避免每个接口写一套返回组装代码我定义了一个统一返回类Result成功时返回Result.success(data)失败时返回Result.error(code, message)。全局异常处理也用Spring Boot的RestControllerAdvice来实现。业务异常比如库存不足、没有权限、状态不允许流转会由Service层主动抛出被全局处理器解析后转为对应JSON返回未捕获的系统异常则统一记录日志并提示“系统繁忙请稍后重试”不把堆栈信息直接暴露给前端。这样前后端联调时接口返回风格完全一致前端统一处理省了很多沟通成本。5.3 登录认证与权限拦截的实现这个系统没有引入Spring Security原因是项目本身定位轻量权限模型是RBAC且主要面向企业内部用拦截器加自定义注解完全可以胜任。用户登录成功后用户ID、用户名、角色列表、权限标识集合会被写入Session。自定义一个权限注解RequiresPerm标注在Controller方法上例如RequiresPerm(purchase:order:audit) PostMapping(/audit) public Result audit(RequestBody PurchaseOrderAuditVO vo) { return purchaseOrderService.audit(vo); }拦截器在preHandle阶段从Session或缓存中取出当前用户的权限集合校验请求方法上的注解权限。权限不匹配直接返回JSON提示“无权访问”而不是跳转到登录页这样用户即使手动输入接口地址也无法越权。拦截器注册时有一个非常容易踩的坑要排除登录接口、静态资源、EasyUI组件引用的JS和CSS路径。如果不做排除访问系统的JS文件都会被拦截器重定向页面样式和功能全部丢失还容易出现登录重定向死循环。所以WebMvcConfigurer里要明确定义排除路径列表常用写法是排除结尾的.js、.css、.png、/login、/captcha等静态资源路径。5.4 Maven多环境与打包配置开发环境、测试环境、生产环境的数据库地址和账号密码一定不相同。如果每次换环境都要手动改配置文件既容易出错又浪费时间。我用Maven的profile机制实现多环境配置src/main/resources下放application.yml再放application-dev.yml、application-prod.ymlpom.xml中定义两个profiles打包命令指定mvn clean package -Dmaven.test.skiptrue -Pprod打包时Maven会把对应环境的配置复制到classes目录应用启动自动读取。这个配置方式不复杂但对团队协作很重要——谁都不会因为改错数据库地址而把测试环境的库给覆盖掉。关于打包形式我最终选择了打成war包部署到独立的Tomcat。虽然Spring Boot支持jar包内嵌Tomcat直接启动但考虑到这套系统所在服务器上还运行着其它JavaWeb项目多个应用使用同一个Tomcat便于统一维护端口和日志。同时要把spring-boot-starter-tomcat的依赖范围设为provided保证打成war包时不会把Tomcat打进war里导致冲突。如果想单机快速演示直接执行Spring Boot的main类也能以内嵌Tomcat方式跑起来两种模式兼容。6. 前端EasyUI页面集成实践6.1 整体布局与菜单加载前端采用了EasyUI的标准后台布局顶部是系统标题和用户信息左侧是可折叠的菜单树右侧是标签页容器。页面入口是一个单独未引入任何框架的静态HTML用户在浏览器输入登录页地址后输入账号密码后台校验通过返回的页面加载后通过Ajax获取当前用户的菜单树数据。菜单树数据结构要按EasyUI tree的格式返回每一个节点有id、text、iconCls如果是父菜单children数组中递归嵌套子节点。页面拿到JSON后用tree组件的loadData方法一次性渲染。点击菜单树节点时通过onClick事件判断节点类型是页面类型就在中心的tabs组件中添加一个新标签页标签页内容通过iframe加载对应HTML页面。iframe方式虽然被很多前端开发者诟病但在EasyUI这种老式后台体系中依然是最稳妥的做法子页面相互独立互不干扰刷新父页面不会丢失打开的多个标签。缺点是不可控的重复加载问题但只要业务页面不过度复杂实际体验完全可以接受。6.2 Datagrid与CRUD对话框列表页的标配是Datagrid。Datagrid的URL属性指向后端的列表查询地址前端会自动把page、rows参数传给后端后端封装PageResult返回包含total和rows的JSON表格就能自动分页展示。新增和编辑功能则通过Dialog组件实现。页面里放一个隐藏的dialog内含一个form表单点击“新增”按钮时清空表单并打开对话框点击“编辑”按钮时先通过row.getSelected()获取选中行数据再用form回填数据。提交时使用form的submit方法action指向后端保存接口返回JSON中的code字段为200时就关闭对话框并通过datagrid.reload()刷新表格。表单校验用的是EasyUI自带的validatebox与表单控件配合可以省掉大量手写JS。比如物料编码必填、数量必须大于0、日期格式必须正确这些在控件上声明requiredtrue就生效了。实际使用中要特别注意日期控件的格式化字符串EasyUI默认日期格式是yyyy-MM-dd后台Jackson序列化时如果没有保持一致回显到输入框会变成错乱的数字这个坑我调了整整一下午归根到底是前端格式和后端日期格式没对齐。6.3 按钮级权限的隐藏控制后端拦截器控制了接口权限前端还需要做一件事无论什么用户打开页面不能让他们看到自己没有权限的按钮。我的做法是在菜单加载时把当前用户的所有按钮权限标识集合放在一个全局JavaScript变量中页面初始化时根据这个集合控制按钮显隐。if (hasPerm(purchase:order:audit)) { $(#btnAudit).show(); } else { $(#btnAudit).hide(); }有的项目图省事不做按钮隐藏结果就是普通用户在页面上看到了“审核”“删除”按钮点下去才弹出“无权限”提示。这种行为对用户体验伤害很大会让用户觉得自己被系统白白戏弄了一遍。从产品逻辑上讲没有权限的操作入口就应该直接不展示而不是点击后才给一个冷冰冰的错误。6.4 静态资源版本管理与缓存问题使用HTML加EasyUI这种纯静态前端时会面临一个特别常见的问题上线后用户浏览器还在使用旧的JS文件缓存导致新增功能看不到或者接口调整后页面调用报错。解决方案很简单我在引用JS和CSS时统一加版本号参数每次发布时手动或借助构建脚本递增版本号script srcjs/purchase/order.js?v20250120/script用这种方式强制浏览器加载最新文件。团队的开发人员必须养成习惯改了前端文件就更新版本参数否则就会出现“代码已上线但用户说没改”的诡异现象。7. 本地部署与上线的完整操作记录7.1 环境要求与版本选择这套系统的开发和运行环境相对主流。JDK 8是Spring Boot 2.x系列最常见的运行版本MySQL 5.7或8.0均可Maven使用3.6以上版本独立的Tomcat 9用来部署war包。前端不需要任何Node环境EasyUI的依赖文件直接放到static目录下即可。这里有一个版本兼容性的细节如果使用MySQL 8.0以上版本驱动类要从com.mysql.jdbc.Driver改成com.mysql.cj.jdbc.Driver并且连接URL中必须加serverTimezoneAsia/Shanghai。很多新手在这里报错连接数据库一直提示CST时区无法识别其实就是缺少这个时区参数。7.2 部署步骤实录完整部署流程大概是这几步在MySQL中创建数据库字符集选择utf8mb4导入项目提供的init.sql脚本脚本会创建所有表并初始化管理员账号修改application-prod.yml中的数据库地址、用户名、密码确认驱动配置正确打开命令行进入项目根目录执行打包命令mvn clean package -Dmaven.test.skiptrue -Pprod在target目录下得到war包将war包复制到Tomcat的webapps目录中启动Tomcat系统会自动解压war包启动完成后访问服务器的8080端口加项目名即可看到登录页使用管理员账号登录验证系统管理、办公审批、采购库存几个核心菜单是否能正常打开。部署中有个隐蔽的问题值得提醒如果Tomcat下已经压入了旧版本的war包重新部署前必须删除webapps中对应的解压目录和war包否则新代码不会生效旧文件残留还容易引发类加载冲突。我通常习惯先停掉Tomcat进程清空webapps下的旧目录再放入新war包启动这样能最大程度避免“改了很多次好像没改”的假象。7.3 上线后的日常运维要点ERP系统上线后维护工作不只是看服务器是否宕机。数据库的定时备份是第一优先级我习惯每天凌晨通过系统自带的mysqldump做一次全量备份保留最近7天的备份文件。因为ERP是覆盖财务和库存的核心系统数据丢失的代价远远高于硬件损坏的代价。同时要留意Tomcat的日志文件定期查看是否有权限校验异常、SQL执行异常、库存扣减失败的记录。日志中如果频繁出现悲观锁等待超时提示说明库存表并发竞争激烈可以考虑在高峰期错峰操作或对库存逻辑做队列化处理。8. 常见问题与排查技巧实录8.1 EasyUI表格出现中文乱码这个问题基本集中在字符集配置上。检查三层数据库连接URL里是否设置了characterEncodingutf8数据库表本身是否为utf8mb4Tomcat的server.xml中Connector是否配置了URIEncodingUTF-8。三者缺一不可。如果前端页面用GBK而数据是UTF-8页面也会乱码所以要统一全链路UTF-8。有一个快速判断方法在浏览器开发者工具中看接口返回文本的Content-Type确认charset是否为UTF-8很容易锁定是哪一环出问题。8.2 访问登录接口后一直跳回首页登录后访问任意页面都会被拦截器拦截并提示重新登录这大概率是Session失效问题。排查点有两个一是Spring Boot的Cookie配置把Session ID过期时间设得过短二是部署在有负载均衡的多台Tomcat环境时没有配置Session共享会话请求打到不同机器时Session对不上。单机部署场景下最常见的还是把server.servlet.session.timeout的值设成非常大或负数用户关掉浏览器后重新打开Tomcat仍能认出旧Session就会出现怪异的一会儿登录一会儿未登录的状态。8.3 静态文件加载之后样式混乱常见的JS或CSS加载顺序问题EasyUI组件对加载顺序有要求。必须是jquery.min.js在前jquery.easyui.min.js在后再引用EasyUI的CSS主题文件。页面中如果先加载了自己的业务脚本再去引用EasyUI的JS组件初始化会失败表现为表格样式丢失或按钮点击无反应。我排查这个问题时第一步就是打开浏览器控制台看JS报错信息如果有EasyUI is not defined或者“$”相关报错基本就是加载顺序不对。8.4 库存数据变成负数或对不上库存负数最直接的诱因就是并发操作没有做原子扣减。如果代码是标准的“查库存→判断库存是否够→扣减”就可能在两个请求同时通过判断后扣减时库存实际已经不够了。更隐蔽的原因是对同一张库存台账表记录在更新时没有加版本控制导致一个旧事务覆盖了新事务的扣减结果。解决办法就是在更新语句中携带版本号或使用库存量条件更新这一点在前面的事务脚本部分已经写过了实际运行时可以把库存流水表和库存台账表的数据量做定期对比如果流水增加和台账减少的总和不一致说明有脏写发生。8.5 打包后找不到配置文件Maven多环境打包最让人头疼的问题是IDE中运行正常打包后启动报错找不到数据库配置。原因通常是resources目录下某些配置文件被打包时被过滤掉了或者多个环境配置文件的名称与application.yml中激活的profile不一致。排查方法是直接解压war包检查classes目录下是否存在application.yml和application-prod.yml确认内容没问题再看启动日志中active profile打印的是哪个环境。8.6 操作常见问题速查表现象可能原因解决建议列表页中文乱码字符集未统一检查MySQL连接、Tomcat编码、页面charset页面登录后访问接口提示无权限按钮权限标识不匹配对比数据库菜单权限标识与代码注解值库存扣减后账面与实物不符事务没加或并发没控制检查Service层是否有Transactional库存用原子更新上传附件失败或附件中文名乱码Tomcat对文件名的编码处理配置URIEncoding并统一请求编码页面打开后第三方组件样式全无JS/CSS引用顺序错误按jQuery、EasyUI、业务脚本的顺序引入已发布代码但浏览器仍显示旧页面静态资源缓存JS和CSS引用加版本号强制刷新采购入库后订单状态未更新事务拆分或状态更新漏执行统一在单据Service中管理入库和状态更新最后再分享一些个人经验做这套系统过程中我最深的体会是办公ERP真正考验人的不是某个技术点而是能否把“状态流转”“数据一致性”“权限边界”这三件事揉进每一个业务功能里。一个采购订单从创建到审核再到入库每一步都有一个状态和一组可执行的校验逻辑这比写一百个没有业务含义的CRUD接口有价值得多。如果正在准备做类似项目我的建议是先把数据库表结构画清楚最好在纸上或者绘图工具中把所有关键状态流转梳理一遍直到一个订单从生到死的每个环节都能说清楚再动手写代码。表结构定了业务逻辑就不会跑偏状态流转定了代码结构才不会乱。等把这套系统跑起来之后你再看其它后台管理系统就会很快抓住它的骨架而不是被密密麻麻的页面描述带乱节奏。