JFinal企业办公系统源码实战：OA骨架、核心机制与二次开发指南

简介：基于JFinal框架的点狮企业办公系统设计源码，是一套面向企业信息化场景的完整项目，涵盖点狮OA、财务系统、办公系统、人力资源管理系统、档案管理、企业资源管理系统、客户资源管理及APP手机端等模块，适合JFinal开发者学习企业级工程结构，也便于需要搭建或二次开发办公系统的团队参考。压缩包共2000个文件，大小95.05MB，前端以HTML、CSS、JS等页面资源为主，后端包含约485个Java类，配合JSP、SQL、XML等配置与脚本，并有Docx、TXT说明文档，覆盖从界面交互、业务逻辑到数据存储的完整链路。目前已有403人学习下载，项目模块划分清晰、目录便于检索，可重点研读路由控制、模型设计、权限拦截等核心环节，了解财务、人事、审批、客户等多业务线的整合方式，整体价值适合中高级Java开发者用于实战复盘或功能扩展。

1. 点狮企业办公系统：一套JFinal源码把OA骨架摊开给你看

点狮企业办公系统这个名字，常见于各类Java源码项目合集，本质上就是一套基于JFinal框架的企业办公系统设计源码。JFinal在国内Java圈的位置一直比较特别：Spring Boot的光芒太强，但JFinal启动极快、不用写XML、Controller写法贴近Servlet习惯，做中小规模企业内部系统时开发效率并不输主流框架。这套标题值得被认真对待的点在于，它已经提前把企业OA最常见的模块——用户、部门、公告、审批流、附件上传、登录鉴权——全部串成了一套可运行的骨架，等同于替你把“用JFinal做办公系统”最难的部分先趟了一遍。适合谁？一类是正在做技术选型、需要一个完整JFinal项目来评估框架边界的人；另一类是团队技术栈定了JFinal、想直接拿现成骨架改造成内部管理系统的一线开发者。

2. 弄懂JFinal的三个核心机制，再回头看这套办公系统源码

读源码最怕一头扎进文件堆里。点狮的源码目录不长，但如果你不理解JFinal的路由方式、Model挂接方式和拦截器机制，读起来还是像在看黑匣子。我习惯把JFinal拆成三块理解：路由解决“URL进到哪个Controller”，ActiveRecord解决“表变成哪个对象”，拦截器解决“请求要先过哪些检查”。把这三块弄明白，这套办公系统跑起来的基本原理就清楚了。

2.1 路由配置：URL怎么和Controller挂上钩

JFinal和Spring MVC一个很明显的差别是没有web.xml，Controller的挂载全部集中在JFinalConfig的configRoute方法里。你打开这类系统源码里的配置类，看到的一般就是继承JFinalConfig的类，在configRoute里用Routes把每个模块的访问路径和Controller绑在一起。

// 文件：cn/dianshi/config/DianshiConfig.java（示意） public class DianshiConfig extends JFinalConfig { @Override public void configRoute(Routes me) { // 登录模块：/login 访问 LoginController me.add("/login", LoginController.class); // 公告模块：/oa/notice/xxx 访问 NoticeController // 第三个参数是视图文件所在的目录 me.add("/oa/notice", NoticeController.class, "/oa/notice"); // 审批流模块 me.add("/oa/workflow", WorkflowController.class, "/oa/workflow"); // 用户和部门管理 me.add("/sys/user", UserController.class, "/sys/user"); me.add("/sys/dept", DeptController.class, "/sys/dept"); } }

add方法的第一个参数是URL前缀，第二个是Controller类，第三个是视图目录。比如NoticeController挂在/oa/notice下，页面里的notice_list.html会优先在/oa/notice目录里找。Controller内部不需要写@RequestMapping这类注解，所有public方法天然成为Action，方法名就是URL的最后一段。这种约定式路由有个直接好处：拿到源码不用到处搜注解，顺着Routes列表就能把整个系统的功能模块过一遍。

2.2 ActiveRecord：表就是Model，不再有DAO层的概念

很多从Spring生态过来的人第一次看JFinal的Model会不太适应，因为找不到Mapper接口。JFinal的做法是让一个实体类继承Model 直接对应一张表，查改删操作全在这个类上完成，不需要额外生成DAO实现类。

// 文件：cn/dianshi/model/SysUser.java // 一个Model类对应sys_user表，dao是全局可用的单例 public class SysUser extends Model<SysUser> { public static final SysUser dao = new SysUser(); } // 使用示例，在任意Controller或Service里直接调用 SysUser user = SysUser.dao.findById(10086); // 根据主键查询 String username = user.getStr("username"); // 读取字段值 user.set("mobile", "13800001111").update(); // 链式修改并更新

findById是ActiveRecord插件自动提供的主键查询方法，查不到会返回null。getStr、getInt、getDate这些方法按数据库列名取字段值，这也是JFinal代码里到处是字符串列名的原因。表名和类名不符合下划线对应关系时，可以用注解指定表名和主键名，正规命名下一般不用管。这类系统里还会大量出现Db工具类，执行原生SQL并返回List ，适合统计报表这种复杂查询。简单说，单表增删改用Model，复杂查询用Db，两条路都不需要写Mapper文件。

2.3 把最小骨架跑起来：建库建表、配数据源、起服务

读这种源码最快的方式是让它先跑起来。落地路径是固定的：建一个数据库、配好数据源、直接启动main方法。这部分我按最常见的方式给一套最小操作。

-- 建库，注意使用utf8mb4，否则生僻字和特殊符号会报错 CREATE DATABASE dianshi_oa DEFAULT CHARSET utf8mb4; USE dianshi_oa; -- 建最小可用的用户表，其他表按这套结构扩展 CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录名', password VARCHAR(64) NOT NULL COMMENT '密码存储值', name VARCHAR(20) COMMENT '真实姓名', dept_id INT DEFAULT 0 COMMENT '所属部门ID', status TINYINT DEFAULT 1 COMMENT '1正常 0禁用' );

// 文件：cn/dianshi/config/DianshiConfig.java（保留关键部分） public class DianshiConfig extends JFinalConfig { @Override public void configConstant(Constants me) { me.setDevMode(true); // 开发模式：加载资源不缓存 me.setEncoding("UTF-8"); } @Override public void configPlugin(Plugins me) { // 连接池插件，参数依次是地址、账号、密码 String url = "jdbc:mysql://127.0.0.1:3306/dianshi_oa" + "?useUnicode=true&characterEncoding=utf8" + "&serverTimezone=Asia/Shanghai"; DruidPlugin dp = new DruidPlugin(url, "root", "你的密码"); me.add(dp); // ActiveRecord插件，把表与Model挂上映射 ActiveRecordPlugin arp = new ActiveRecordPlugin(dp); arp.addMapping("sys_user", SysUser.class); me.add(arp); } @Override public void configRoute(Routes me) { me.add("/sys/user", UserController.class, "/sys/user"); } // 内置Jetty启动方式，端口8080，项目根路径为/ public static void main(String[] args) { JFinal.start(DianshiConfig.class, 8080, "/"); } }

这里有两个参数是必定要改的：数据库密码和main方法里的端口号。DruidPlugin是JFinal生态里常见的连接池插件，如果你拿到的版本用的是别的连接池，替换成对应插件初始化即可，配置思路一致。启动后访问 http://127.0.0.1:8080/sys/user 能看到列表页面，最小链路就算通了。如果白屏或404，优先检查Routes里路径与Controller类有没有对不上的地方。

2.4 拦截器：登录校验和权限判定到底放哪一层

办公系统最核心的安全问题，就是未登录用户不能访问业务页面。这类系统的常规做法是加一个全局拦截器，实现JFinal的Interceptor接口后注册到所有请求之前。

// 文件：cn/dianshi/interceptor/AuthInterceptor.java（示意） public class AuthInterceptor implements Interceptor { @Override public void intercept(Invocation inv) { Controller c = inv.getController(); String actionKey = inv.getActionKey(); // 登录接口本身和静态资源不拦截，直接放行 if ("/login".equals(actionKey) || actionKey.startsWith("/static")) { inv.invoke(); return; } // 会话里没有userId就跳回登录页 Integer userId = c.getSessionAttr("userId"); if (userId == null) { c.redirect("/login"); return; } // 权限不足时统一返回403页面 if ("/sys/user".equals(actionKey) && !isAdmin(userId)) { c.renderError(403, "/error/403.html"); return; } inv.invoke(); // 放行，继续调用真正的Controller方法 } private boolean isAdmin(Integer userId) { return SysUser.dao.findById(userId).getInt("role_level") == 1; } }

JFinal的拦截器有两种挂法：全局注册和@Before局部挂载。全局注册写在configInterceptor里，对所有路由生效，适合登录校验这种全体请求都适用的逻辑。@Before(AuthInterceptor.class)放在某个Controller类或方法上，只对局部模块生效。读这套源码时留意哪些拦截器是全局的、哪些是局部的，基本就能看出整系统在安全上的设计思路：大面用全局兜底，敏感操作再单独挂一个权限校验。

3. 点狮办公系统核心模块拆解：先看表结构，再读业务代码

办公系统本质上是表单、列表、审批三件事来回组合。这类源码真正值得读的往往不是某个炫技算法，而是表和表之间的组织方式。下面按“表设计先行”的思路拆，你读代码时就有了坐标。

3.1 部门用户角色：组织架构的树怎么建模才够用

办公系统的第一张表往往不是用户表，而是部门表。几乎每个企业都是多级部门结构，最直接的建模方式是父ID自关联。

CREATE TABLE sys_dept ( id INT PRIMARY KEY AUTO_INCREMENT, parent_id INT NOT NULL DEFAULT 0 COMMENT '上级部门ID，0表示根', name VARCHAR(100) NOT NULL COMMENT '部门名称', order_no INT DEFAULT 0 COMMENT '同级排序，越小越靠前', status TINYINT DEFAULT 1 COMMENT '1启用 0停用' ); CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, dept_id INT DEFAULT 0 COMMENT '所属部门ID', name VARCHAR(20), role_level TINYINT DEFAULT 0 COMMENT '0普通成员 1管理员 2部门负责人' );

这种模型的三个特点要想清楚。第一，查询某个部门的全部子部门时，SQL要递归实现，或者一次性查出全量数据在内存里组树，数据量不大时后者更稳。第二，删除部门前必须检查是否还有子部门和在职员工，这类系统的DeptController里一般会有一段类似的防呆校验。第三，user表的dept_id加普通索引即可，不要建物理外键，JFinal这类轻框架在约定上不做物理外键，关联关系由代码维护。部门树的遍历在Java里常见做法是递归组装节点，把这段代码读一遍，你就理解了这套源码对组织架构的建模思路。

3.2 审批流的设计：不用重型工作流引擎，一张步骤表走天下

企业办公系统里最容易被过度设计的就是审批流。这种体量的项目通常不会引入独立工作流引擎这种重武器，而是自己维护状态机，核心就是两张表：一张记录审批实例当前走到第几步，一张记录每一步的审批人、审批结果和意见。

-- 审批实例表：一次请假/报销/合同审批就是一个实例 CREATE TABLE oa_workflow ( id INT PRIMARY KEY AUTO_INCREMENT, biz_type VARCHAR(32) NOT NULL COMMENT '业务类型：leave/expense/contract', biz_id INT NOT NULL COMMENT '关联的业务单据ID', apply_user_id INT NOT NULL COMMENT '发起人', current_step INT DEFAULT 1 COMMENT '当前进行到的步骤序号', status TINYINT DEFAULT 0 COMMENT '0处理中 1通过 2驳回 3撤销', create_time DATETIME, update_time DATETIME ); -- 审批步骤表：每个实例多行，每行一个待办/已办节点 CREATE TABLE oa_workflow_step ( id INT PRIMARY KEY AUTO_INCREMENT, workflow_id INT NOT NULL COMMENT '所属实例ID', step_no INT NOT NULL COMMENT '步骤序号，从1开始依次执行', approve_user_id INT NOT NULL COMMENT '这一步的审批人', comment VARCHAR(500) COMMENT '审批意见', status TINYINT DEFAULT 0 COMMENT '0待处理 1通过 2驳回', approve_time DATETIME );

这套设计的优点很明显：流程的每一步都是表里的一行数据，要改流程就改数据，不需要改代码。发起人提交时初始化workflow和step，审批人点同意时把当前step置为通过，把workflow的current_step加1，再把下一步的step状态置为0。想读明白流转逻辑，就盯住WorkflowService里的approve方法，里面通常会处理“当前是否是最后一步”和“驳回是否直接结束”两个分支。相比引入工作流引擎，这种方案能覆盖办公系统八成以上的审批场景，而且逻辑透明，排错时直接查表就能还原现场。

3.3 公告、任务、考勤：三个轻业务模块的共性写法

除了审批，剩下的大头就是公告、任务、考勤这类轻模块。它们的表结构高度相似：主表带几个通用字段，加一个状态字段，由不同的Controller控制查询范围。

CREATE TABLE oa_notice ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(200) NOT NULL, content TEXT, publisher_id INT NOT NULL COMMENT '发布人', top_flag TINYINT DEFAULT 0 COMMENT '1置顶', publish_time DATETIME, status TINYINT DEFAULT 1 COMMENT '1已发布 0草稿' ); CREATE TABLE oa_task ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(200) NOT NULL, assignee_id INT NOT NULL COMMENT '负责人', due_date DATE, priority TINYINT DEFAULT 0 COMMENT '0普通 1重要 2紧急', status TINYINT DEFAULT 0 COMMENT '0待办 1完成' );

看这类模块时，重点放Controller里的list方法：分页参数一般是page和pageSize，列表默认只查status对应生效状态的数据，排序字段通常按create_time或publish_time倒序。把第一个公告Controller的list和save方法读完，其余轻模块基本就是同一个套路，不需要逐文件精读。这也是JFinal在这种场景最舒服的地方：模板固定、接口开发快，业务边界一眼能看完。

4. 从源码到上线：配置、打包和部署的三步实操

很多人以为拿到一套Java源码最难的是读代码，其实让它在本地和服务器上都能跑起来，这一步翻车率反而最高。落地涉及五处配置、两条运行路线和一个资源路径约定。

4.1 动手部署前先改这五个参数

我按经验列了一张表，对应这类系统几乎都会有的配置项。拿到源码先检查这五处，再考虑读业务逻辑。

验证码开关值得多说一句。很多JFinal项目为了开发方便会做一个可开关的验证码逻辑，上线时忘了开，内网系统还能凑合，外网系统基本等于把登录接口裸奔。这也是我检查别人源码时优先级最高的一个点。

4.2 本地测试和生产部署：两条运行路线别混着用

JFinal项目最常见的两种运行方式是内置Jetty和打包成war部署到外部Servlet容器。开发期用内置Jetty，main方法直接启动；预发和生产环境打war包部署，项目隔离更干净。

# 开发期直接用maven编译后启动 mvn clean compile mvn exec:java -Dexec.mainClass="cn.dianshi.config.DianshiConfig" # 生产打包，跳过测试 mvn clean package -DskipTests ls target/*.war

两条路线容易踩坑的地方在于：内置Jetty时端口在main方法里写死，放到外部容器部署时端口由容器管理，main方法不再生效。如果源码打包方式不是war而是jar，那生产部署多半靠内置Jetty直接运行，这种方式部署简单，但运维上需要单独写启动脚本管理进程和日志。

4.3 模板和静态资源：路径规则决定页面能不能正常显示

Controller方法结束时调用render("notice_list.html")返回页面，这个视图路径是相对configRoute里定义的视图目录来找的。而项目里的CSS、JS、图片这类静态资源，一般放在webapp或src/main/webapp的static目录下，浏览器访问路径类似/static/css/app.css。这个前缀必须在拦截器白名单里放行，否则就会出现“页面能打开但样式全部丢失”的经典问题。

// 模板渲染示例：NoticeController里的列表方法 public void list() { Page<Notice> page = Notice.dao.paginate( getParaToInt("page", 1), 10, "select *", "from oa_notice where status=1 order by publish_time desc"); setAttr("page", page); render("notice_list.html"); // 在视图目录下找notice_list.html }

paginate方法第一个参数是页码，第二个是每页条数，后两个参数分别是查询前置部分和查询条件，框架会自动拼接count查询实现分页。改页面找不到样式文件时，先去webapp/static目录核对路径，再回到拦截器白名单里检查前缀。

5. 点狮式JFinal办公系统避坑指南：5个高频翻车现场

JFinal的文档不算少，但真实的坑大多是配置文件、框架约定和运行环境三者叠加出来的。下面这五条来自广泛项目里的高频踩坑记录，每条按现象、原因、解决三步排，照着排查能省半天起步。

5.1 时间字段整体差8小时

现象：列表页显示的时间比数据库里实际存的时间少了8小时，或者SQL写入后，数据库里看到的时间落在前一天23点。

原因：MySQL驱动与JVM默认时区不一致。新版驱动要求连接串必须显式声明serverTimezone，否则会读取到默认时区，结果就是所有时间字段偏移8小时。

解决：在数据库连接串上追加serverTimezone=Asia/Shanghai，并保留useUnicode=true和characterEncoding=utf8，避免中文乱码一起冒出来。改完重启服务，再插一条数据验证显示时间是否和当前时间一致。

5.2 列名命中保留字，查询没问题但更新全失败

现象：给表新增一个字段后，保存或更新操作直接报SQL语法错误，而同样的SQL在数据库客户端里手动执行却正常。

原因：字段名用了数据库保留字，比如desc、order、level这类词。客户端工具通常会做自动转义，但JFinal的ActiveRecord在拼接SQL时没有加反引号，一执行就报错。

解决：不要用保留字当业务字段名，优先改名。如果表已经上线没法改，那就绕开ORM，改用Db.update原生SQL执行并手动加反引号。代码里写成set("desc", xxx)这种形式，能不用就别用。

5.3 Linux部署后附件上传全部失败，本地却好好的

现象：Windows本地测试上传图片一切正常，部署到Linux服务器后，同一个接口报上传失败或返回500，日志里是文件目录相关的报错。

原因：上传目录配置的是相对路径，Linux下相对路径指向了进程工作目录或应用用户主目录，那个目录不存在，或应用运行账号没有写权限。问题往往不是权限位不对，而是目录压根没建。

解决：配置一个绝对路径作为上传目录，启动前手动创建目录并确认运行账号对其有读写权限。上线后传一个文件，去服务器上看实际落盘位置，不要只看接口返回码。

5.4 登录页和静态资源全被拦截器拦住了

现象：随便访问一个业务路径，页面直接跳登录页，但登录接口本身却访问不到，页面样式也全部丢失。

原因：全局拦截器对所有Action生效，而登录接口和CSS、JS资源没有进入放行名单。常见写法是只放行了/static/css，没放行/static/js，或者登录路径实际是/login.action但判断字符串写成/login。

解决：在拦截器最前面放行登录相关路径和/static整个目录，用actionKey.startsWith("/static")做前缀判断，而不是逐个目录列举。注意先放行再判断session，顺序错了照样会拦。

5.5 @Before(Tx.class)事务不生效

现象：业务方法里故意抛异常，但数据库里已经插入的数据没有回滚。

原因：JFinal的Tx事务依赖拦截器代理，只有Controller方法或者被正常代理调用的外部方法才能拦截到。在同一个类内部直接调用另一个加了Tx的方法，事务不会生效；private方法上挂Tx注解也完全无效。

解决：把需要事务的整段业务拆成一个独立的公有方法，标注@Before(Tx.class)，由Controller调用它。出现回滚不掉的诡异现象时，先在这个方法里主动抛一次异常验证，能回滚再继续排查业务逻辑。

6. 二次开发最值得先改的两处：会签支持与操作日志

这套系统能跑，但通用模板写的骨架在实际业务里大概率要动两处：审批流的会签扩展，以及操作日志的统一记录。这两件事都不大，但直接影响办公系统能不能在真实企业里用顺。

6.1 给审批流加上“多人会签”能力

默认的步骤表是每步一个审批人，遇到部门全员会签的场景就不够用。我试过最稳的方案是给步骤表拆出子表，把多个审批人同时处理同一节点独立成一张表。

-- 步骤会签人子表，替代原来步骤表里的单一审批人字段 CREATE TABLE oa_flow_step_user ( id INT PRIMARY KEY AUTO_INCREMENT, step_id INT NOT NULL COMMENT '对应oa_workflow_step的id', approve_user_id INT NOT NULL COMMENT '会签人员ID', status TINYINT DEFAULT 0 COMMENT '0未审批 1同意 2拒绝', approve_time DATETIME );

原有步骤表的approve_user_id字段可以保留，但判断当前节点是否通过时，改成统计oa_flow_step_user里status=1的数量，达到该节点总人数才推进到下一步。这个改动只影响流程服务里审批通过那一小段逻辑，不会动整个状态机结构，风险很可控。

6.2 用全局拦截器统一记录操作日志

审计需求几乎每个企业都会提。与其在每个Controller里写日志代码，不如复用一个拦截器，在方法调用前后统一处理。

// 文件：interceptor/LogInterceptor.java（示意） public class LogInterceptor implements Interceptor { @Override public void intercept(Invocation inv) { Controller c = inv.getController(); long start = System.currentTimeMillis(); try { inv.invoke(); // 执行真正的业务方法 writeLog(c, inv.getActionKey(), "SUCCESS", System.currentTimeMillis() - start); } catch (Exception e) { writeLog(c, inv.getActionKey(), "ERROR", System.currentTimeMillis() - start); throw e; } } }

这个拦截器可以只注册写操作，也可以全局注册后在方法内部过滤掉GET请求。日志落库时把userId、actionKey、关键参数、耗时一起写入一张日志表，基本就是一份能应对审计的操作记录。

说实话，早几年我看这种轻框架办公系统源码时，总想着先把框架换成自己最熟的那套，结果换一次路由和ORM就要重写一遍，项目进度反而被拖住。现在我的习惯是尊重原框架设计，先让它在本地完整跑通，再沿着表结构和拦截器去理解模块边界，最后只改业务里真正要改的扩展点。这样既稳又快，希望帮到你。

本文还有配套的精品资源，点击获取