JFinal 深度评测：轻量级 Java Web 框架的实战与选型思考

1. 为什么我又把 JFinal 翻出来认真评测了一遍

做后端开发十来年，Java 生态里的 Web 框架我基本都摸过一遍。Spring 全家桶不用多说，项目里用得最多；Vert.x、Javalin、Spark Java 这些轻量级的也试过；甚至有一阵子还折腾过纯 Servlet 加手写路由。但 JFinal 这个框架，说实话，我之前的印象一直停留在“国内某位前辈做的小巧框架”这个层面，知道它快、知道它简单，但从没认真在真实项目里跑过一轮完整流程。

这次之所以决定认真评测，起因是帮一个朋友看他的小团队项目。他们做的是一个内部管理系统，日活不高，但迭代频率很快，团队里只有一个后端。他跟我吐槽说 Spring Boot 启动慢、配置多、改一个接口要动好几个文件，我就随口提了一句“你可以看看 JFinal”。结果他真去看了，两天后跟我说“这东西有点意思”。我当时心里就有点不服气——一个框架能在两天内让一个习惯了 Spring 的人觉得“有意思”，要么是他太菜，要么是这框架确实有东西。

于是我决定自己动手，从零搭一个完整的项目，把 JFinal 的核心链路全部走一遍：路由、控制器、ORM、模板、拦截器、插件、打包部署。这篇文章就是这次评测的完整记录，不是官方文档的复述，也不是“Hello World”级别的演示，而是一个真实后端开发者在使用过程中踩到的坑、发现的亮点、以及最终形成的判断。

如果你是一个正在选型的小团队后端，或者你手头有那种“不需要微服务、不需要复杂生态、就想快速把业务逻辑写出来”的项目，那这篇评测应该对你有参考价值。如果你是大厂里深度绑定 Spring 体系的开发者，也可以看看另一种思路——一个把“少写代码”作为核心哲学的框架，到底能做到什么程度。

2. JFinal 的核心设计思路拆解

2.1 零配置与约定优于配置的取舍

JFinal 最核心的设计哲学就四个字：少写代码。这不是一句口号，而是贯穿整个框架的设计准则。我先把它的几个关键设计决策拆开讲，你就能理解为什么它用起来会让人觉得“快”。

第一个决策是零 XML 配置。JFinal 从设计之初就完全抛弃了 XML，所有配置都通过 Java 代码完成。你可能会说 Spring Boot 也做到了零 XML，但区别在于：Spring Boot 的零 XML 是建立在大量注解和自动配置类之上的，而 JFinal 的配置集中在一个继承自JFinalConfig的类里，通常不超过 50 行。路由、插件、拦截器、数据库连接，全部在这一个文件里搞定。

第二个决策是路由即配置。在 JFinal 里，你不需要在控制器上写@RequestMapping，而是在配置类里用routes.add("/user", UserController.class)这样的方式集中注册。这个设计看起来像是“倒退”，因为 Spring 早就用注解把路由分散到各个控制器了。但实际用下来，集中式路由有一个被低估的好处：你可以在一个文件里看到整个应用的所有入口。对于一个中小型项目来说，这比在几十个控制器里翻注解要高效得多。

第三个决策是ActiveRecord 模式的 ORM。JFinal 的 ORM 不是 JPA 那种完全面向对象的映射，而是更接近 ActiveRecord 模式——模型类直接继承Model，然后通过User.dao.findById(1)这样的方式操作数据库。没有 Repository 接口，没有 EntityManager，没有复杂的关联映射配置。这种设计在复杂业务场景下确实不如 JPA 灵活，但在 CRUD 为主的业务系统里，开发效率极高。

这里要说明一点：JFinal 的 ORM 并不是要替代 JPA 或 MyBatis，它解决的是“80% 的简单查询和写入”这个场景。如果你有极其复杂的多表关联查询，JFinal 也支持手写 SQL 和Db工具类，不会把你锁死。

2.2 与主流框架的对比：为什么它敢说自己快

JFinal 官方一直强调“开发速度快、运行速度快”，我一开始觉得这是营销话术，但实际测下来，这两个“快”都有具体支撑。

开发速度快体现在几个方面。第一，代码量确实少。我同样的一个用户管理模块，用 Spring Boot + MyBatis 写了大概 8 个文件（Controller、Service、ServiceImpl、Mapper、Mapper XML、Entity、DTO、Config），用 JFinal 只写了 3 个文件（Controller、Model、Config）。第二，没有分层强迫症。JFinal 不强制你写 Service 层，Controller 里可以直接调 Model 做数据库操作。对于简单业务来说，这省掉了大量“为了分层而分层”的模板代码。第三，热加载体验好。JFinal 的JFinalFilter配合开发模式下的devMode配置，改完 Java 代码后不需要重启整个应用，刷新页面就能看到效果，这个体验比 Spring Boot DevTools 还要顺滑。

运行速度快则主要得益于它的架构设计。JFinal 没有使用反射来做路由映射，而是在启动时就把路由表构建成一个ActionMapping的哈希表，请求进来后直接查表定位到Action，然后执行。整个请求处理链路非常短，没有复杂的过滤器链和 AOP 代理嵌套。我用 JMeter 做了一个简单的压测对比：同样的一个返回 JSON 的接口，JFinal 在 100 并发下的平均响应时间是 3ms 左右，Spring Boot 是 8ms 左右。当然这个数据受很多因素影响，但趋势是明显的——JFinal 的请求处理开销确实更小。

不过这里要客观说一句：运行速度的差异在绝大多数业务场景下并不关键。你的瓶颈大概率在数据库查询、网络 IO 或者业务逻辑本身，而不是框架的请求分发。所以“快”这个优势，更多是体现在开发效率和部署体验上，而不是压测数字上。

2.3 适合什么场景，不适合什么场景

用了这一轮之后，我对 JFinal 的适用边界有了比较清晰的认识。

适合的场景：中小型 Web 应用、内部管理系统、API 网关层、快速原型开发、个人项目、教学演示。这些场景的共同特点是业务逻辑相对直接，不需要复杂的依赖注入和 AOP 切面，团队规模小，迭代速度快。

不太适合的场景：大型企业级应用（需要复杂的模块化和依赖管理）、需要深度集成 Spring 生态的项目（比如 Spring Cloud、Spring Security 的复杂配置）、团队已经深度绑定 Spring 技术栈且没有切换动力的情况。

这不是说 JFinal 做不了大项目，而是说在大项目里，Spring 生态的成熟度和工具链优势会更明显。选型这件事，从来不是“哪个框架更好”，而是“哪个框架更适合当前这个项目”。

3. 从零搭建一个 JFinal 项目的完整实操

3.1 环境准备与项目骨架搭建

我这次用的是 Maven 来管理依赖，JDK 版本是 17，JFinal 版本是 5.1.0。虽然 JFinal 对 JDK 版本要求不高（JDK 8 就能跑），但我建议至少用 JDK 11 以上，因为很多现代工具链已经不再支持 JDK 8 了。

先看 Maven 依赖，核心就两个：

<dependency> <groupId>com.jfinal</groupId> <artifactId>jfinal</artifactId> <version>5.1.0</version> </dependency> <dependency> <groupId>com.jfinal</groupId> <artifactId>jfinal-undertow</artifactId> <version>3.5</version> </dependency>

第一个是 JFinal 核心包，第二个是 Undertow 服务器插件。JFinal 默认不绑定 Servlet 容器，你可以选择 Tomcat、Jetty 或者 Undertow。我选 Undertow 是因为它启动快、内存占用小，而且 JFinal 官方对它的支持最好。

项目结构我建议这样组织：

src/main/java/ config/ AppConfig.java controller/ UserController.java model/ User.java interceptor/ AuthInterceptor.java src/main/webapp/ WEB-INF/ view/ user/ list.html

这个结构比 Spring Boot 的“约定结构”要自由得多，你可以按自己的习惯调整。但有一点要注意：JFinal 的模板文件默认放在src/main/webapp/WEB-INF/view下，如果你用 Maven 的标准目录结构，需要确保这个路径被正确打包。

3.2 核心配置类的编写与参数解读

配置类是 JFinal 的入口，所有东西都在这里组装。我先把完整的配置代码贴出来，然后逐段解释。

public class AppConfig extends JFinalConfig { @Override public void configConstant(Constants me) { me.setDevMode(true); me.setEncoding("UTF-8"); me.setJsonFactory(new FastJsonFactory()); } @Override public void configRoute(Routes me) { me.add("/user", UserController.class); me.add("/api/blog", BlogController.class, "/api"); } @Override public void configPlugin(Plugins me) { DruidPlugin druidPlugin = new DruidPlugin( "jdbc:mysql://localhost:3306/demo", "root", "password"); me.add(druidPlugin); ActiveRecordPlugin arp = new ActiveRecordPlugin(druidPlugin); arp.addMapping("user", User.class); arp.setShowSql(true); me.add(arp); } @Override public void configInterceptor(Interceptors me) { me.add(new AuthInterceptor()); } @Override public void configHandler(Handlers me) { // 可以添加全局处理器 } }

configConstant里我设置了三个东西。setDevMode(true)开启开发模式，这个模式下 JFinal 会输出详细的请求日志，并且支持热加载。setEncoding("UTF-8")设置默认编码，避免中文乱码。setJsonFactory(new FastJsonFactory())是替换默认的 JSON 实现，JFinal 默认用的是 Jackson，我换成 FastJson 是因为它在序列化复杂对象时性能更好，而且对循环引用的处理更友好。

configRoute是路由注册。me.add("/user", UserController.class)表示所有/user开头的请求都交给UserController处理。第二个参数"/api"是视图路径的前缀，意思是这个控制器返回的视图会去/api目录下找。这个设计很实用，可以让不同模块的视图文件分开存放。

configPlugin里配置了数据库连接池和 ActiveRecord。我用的是 Druid 连接池，这是国内项目里很常见的选择，监控功能强。arp.addMapping("user", User.class)把数据库的user表和User模型类关联起来。setShowSql(true)会在控制台打印执行的 SQL，开发阶段很有用，上线时记得关掉。

configInterceptor注册了全局拦截器。JFinal 的拦截器是方法级别的，可以精确控制到某个 Controller 的某个方法。这个后面会详细讲。

3.3 控制器与路由的实战写法

JFinal 的 Controller 写法跟 Spring MVC 差别很大，我先把代码贴出来：

public class UserController extends Controller { public void index() { renderText("Hello JFinal"); } public void list() { List<User> users = User.dao.find("select * from user"); setAttr("users", users); render("user/list.html"); } public void detail() { int id = getInt("id", 0); User user = User.dao.findById(id); if (user == null) { renderJson(Ret.fail("msg", "用户不存在")); return; } renderJson(Ret.ok("data", user)); } public void save() { User user = getModel(User.class, "user"); user.save(); renderJson(Ret.ok()); } }

几个关键点。第一，Controller 里的方法名直接对应 URL 路径。比如list()方法对应的访问路径是/user/list，不需要任何注解。第二，renderText、renderJson、render是渲染方法，分别对应返回纯文本、JSON 和模板视图。第三，getInt、getModel是参数获取方法，JFinal 会自动把请求参数绑定到模型对象上。

这里有一个我踩过的坑：getModel的参数名必须和前端表单的字段名前缀一致。比如getModel(User.class, "user")要求前端传的参数是user.name、user.age这种格式。如果前端直接传name、age，需要用getModel(User.class, "")或者手动getPara逐个获取。这个设计是为了支持一个表单提交多个模型的情况，但在简单场景下反而有点绕。

3.4 ORM 与数据库操作的细节

JFinal 的 ORM 是我这次评测的重点之一。先看模型类的定义：

public class User extends Model<User> { public static final User dao = new User().dao(); }

就这两行。没有 getter/setter，没有字段声明，没有注解。所有字段都是动态的，通过user.get("name")或者user.getStr("name")获取。这种设计的好处是极简，坏处是失去了编译期检查，字段名写错了要到运行时才发现。

查询操作我常用的几种写法：

// 根据主键查询 User user = User.dao.findById(1); // 条件查询 List<User> users = User.dao.find("select * from user where age > ?", 18); // 分页查询 Page<User> page = User.dao.paginate(1, 10, "select *", "from user where status = ?", 1); // 保存 User user = new User(); user.set("name", "张三").set("age", 25); user.save(); // 更新 user.set("age", 26).update(); // 删除 User.dao.deleteById(1);

paginate方法是 JFinal 的一个亮点，它自动处理了分页查询的 count 语句和 limit 语句，你只需要传页码、每页条数和查询条件就行。这个在写后台列表页的时候非常省事。

注意：JFinal 的find方法返回的是List<Model>，如果你需要返回自定义的 DTO，可以用Db.find配合BeanKit或者手动转换。另外，paginate的 count 语句是自动生成的，如果查询条件很复杂，建议手动写 count 语句，避免性能问题。

3.5 模板引擎与前端渲染

JFinal 自带一个叫 Enjoy 的模板引擎，语法跟 Velocity 和 FreeMarker 类似，但更简洁。我一开始想用 Thymeleaf，但发现 JFinal 对 Enjoy 的集成最顺滑，就干脆用 Enjoy 了。

一个典型的列表页模板：

#for(user : users) <tr> <td>#(user.id)</td> <td>#(user.name)</td> <td>#(user.age)</td> </tr> #end

#for是循环指令，#(表达式)是输出指令。Enjoy 的语法设计原则是“尽量少写字符”，所以没有${}这种冗长的写法。条件判断用#if、#elseif、#else，跟 Java 的语法很接近。

Enjoy 还支持模板布局和模板函数，可以做一些简单的复用。但说实话，如果你习惯了前后端分离的开发模式，JFinal 的模板引擎可能用得不多。我这次评测的项目是传统的服务端渲染，所以模板用得比较多。如果是前后端分离的项目，Controller 里直接renderJson就行，模板引擎基本不碰。

4. 拦截器、插件与扩展机制

4.1 拦截器的实现与执行顺序

JFinal 的拦截器机制是我觉得设计得比较优雅的一块。它不像 Spring 的 HandlerInterceptor 那样有 preHandle、postHandle、afterCompletion 三个方法，而是只有一个intercept方法，通过inv.invoke()来控制是否继续执行。

public class AuthInterceptor implements Interceptor { @Override public void intercept(Invocation inv) { Controller controller = inv.getController(); String token = controller.getHeader("Authorization"); if (token == null || !validateToken(token)) { controller.renderJson(Ret.fail("msg", "未登录")); return; } inv.invoke(); } }

inv.invoke()之前的代码相当于 preHandle，之后的代码相当于 postHandle。如果不调用inv.invoke()，请求就被拦截了，不会进入 Controller 方法。

拦截器的注册有三个级别：全局拦截器（在configInterceptor里注册）、Controller 级别（在 Controller 类上加@Before注解）、方法级别（在方法上加@Before）。执行顺序是全局 -> Controller -> 方法，形成一个拦截器链。

实操心得：拦截器里不要做太重的操作，比如查数据库。我一开始在 AuthInterceptor 里每次都查用户表验证 token，后来发现 QPS 一高数据库压力很大。后来改成用本地缓存存 token 和用户信息的映射，性能好了很多。拦截器适合做轻量的前置检查，重操作应该放到 Service 层或者用缓存解决。

4.2 常用插件的选型与配置

JFinal 的插件生态不算丰富，但常用的都有。我这次用了三个插件：Druid 连接池、ActiveRecord（ORM）、EhCache（缓存）。

Druid 的配置前面已经展示了，这里补充几个关键参数：

DruidPlugin druidPlugin = new DruidPlugin(url, user, password); druidPlugin.setInitialSize(5); druidPlugin.setMinIdle(5); druidPlugin.setMaxActive(20); druidPlugin.setMaxWait(60000); druidPlugin.setValidationQuery("select 1");

initialSize是初始连接数，minIdle是最小空闲连接数，maxActive是最大连接数。这三个参数的设置要根据实际并发量来定。我的经验是：maxActive不要超过数据库的最大连接数除以应用实例数，否则会出现连接等待。maxWait是获取连接的超时时间，单位毫秒，设成 60000 表示最多等 60 秒。

EhCache 插件的配置也很简单：

EhCachePlugin ehCachePlugin = new EhCachePlugin(); me.add(ehCachePlugin);

然后在需要缓存的方法上加@Cacheable注解就行。但要注意，JFinal 的缓存注解是方法级别的，而且默认的 key 生成策略比较简单，复杂场景下建议手动用CacheKit操作缓存。

4.3 自定义插件的开发思路

JFinal 的插件机制基于IPlugin接口，只有start()和stop()两个方法。如果你有一些需要在应用启动时初始化的资源，比如定时任务、消息队列消费者、自定义线程池，都可以封装成插件。

public class SchedulerPlugin implements IPlugin { private ScheduledExecutorService scheduler; @Override public boolean start() { scheduler = Executors.newScheduledThreadPool(2); scheduler.scheduleAtFixedRate(() -> { // 执行定时任务 }, 0, 1, TimeUnit.HOURS); return true; } @Override public boolean stop() { if (scheduler != null) { scheduler.shutdown(); } return true; } }

这个插件在应用启动时创建一个定时任务线程池，每小时执行一次任务。start()返回 true 表示启动成功，返回 false 会导致应用启动失败。stop()在应用关闭时调用，用来释放资源。

注意：插件的start()方法是在应用启动时同步调用的，如果里面有耗时操作（比如建立网络连接），会拖慢启动速度。建议把耗时操作放到异步线程里执行，或者用懒加载的方式。

5. 实际开发中遇到的问题与排查记录

5.1 常见异常与解决思路

这一轮评测下来，我遇到了几个比较典型的问题，整理成表格方便查阅：

其中我踩得最久的一个坑是表名映射。JFinal 默认会把模型类的类名转成下划线格式作为表名，比如UserProfile会映射到user_profile。但如果你的表名不符合这个规则，就必须在addMapping里显式指定。我一开始没注意，查了半天才发现是表名不对。

5.2 性能调优的实操经验

JFinal 本身的性能开销很小，所以调优的重点不在框架本身，而在数据库和缓存。

第一个优化点是连接池参数。我一开始用默认配置，压测时发现 QPS 上不去，后来把maxActive从 10 调到 20，QPS 提升了将近一倍。但也不是越大越好，连接数太多会导致数据库端的上下文切换开销增加。我的经验值是：maxActive设置为CPU 核数 * 2 + 磁盘数左右比较合适。

第二个优化点是SQL 日志。开发阶段setShowSql(true)很方便，但上线后一定要关掉，否则每条 SQL 都打印日志，IO 开销很大。我是在配置类里根据环境变量来判断是否开启：

arp.setShowSql("dev".equals(System.getProperty("env")));

第三个优化点是分页查询的 count 语句。JFinal 的paginate方法会自动生成 count 语句，但它的生成逻辑是简单地把select *替换成select count(*)。如果原查询有order by或者group by，生成的 count 语句可能不正确或者性能很差。这种情况下建议手动传 count 语句：

String select = "select * from user where status = ?"; String count = "select count(*) from user where status = ?"; Page<User> page = User.dao.paginate(1, 10, select, count, 1);

5.3 那些官方文档没写的坑

有几个问题我在官方文档里没找到明确说明，是靠自己试出来的。

第一个坑：getModel和getBean的区别。getModel返回的是Model对象，字段是动态的；getBean返回的是普通的 Java Bean，需要有无参构造器和 setter 方法。如果你用的是普通的 POJO 而不是继承Model，就必须用getBean。我一开始混用了，导致字段绑定不上，排查了很久。

第二个坑：事务的写法。JFinal 的事务不是通过注解实现的，而是通过Db.tx()或者Tx拦截器。我一开始想找@Transactional注解，发现根本没有。正确的写法是：

Db.tx(() -> { user.set("balance", 100).update(); order.set("status", 1).update(); return true; });

Db.tx()接受一个Atomic接口的实现，返回 true 表示提交，返回 false 或者抛异常表示回滚。这个设计比注解更灵活，但也更容易写错——如果你忘了返回 true，事务就不会提交。

第三个坑：静态方法的线程安全。JFinal 的User.dao是一个静态字段，但它是线程安全的，因为dao()方法返回的是一个无状态的代理对象。不过如果你在 Model 里加了自定义的实例字段，就要注意线程安全问题。我的建议是：Model 类里只放静态的 dao 字段，不要加任何实例字段。

6. 打包部署与生产环境注意事项

6.1 打包方式的选型

JFinal 支持两种打包方式：打 WAR 包部署到外部 Servlet 容器，或者打成可执行 JAR 包内嵌 Undertow 启动。我两种都试了，最终推荐可执行 JAR的方式。

WAR 包的好处是可以部署到已有的 Tomcat 里，适合那些已经有运维体系的公司。但缺点是启动慢、配置繁琐，而且需要额外管理 Tomcat 的版本和配置。

可执行 JAR 的好处是启动快、部署简单，一个java -jar命令就搞定。配合 Maven 的maven-assembly-plugin或者maven-shade-plugin，可以把所有依赖打成一个 JAR 包。我用的配置是：

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <version>3.4.1</version> <executions> <execution> <phase>package</phase> <goals><goal>shade</goal></goals> <configuration> <transformers> <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> <mainClass>com.demo.Main</mainClass> </transformer> </transformers> </configuration> </execution> </executions> </plugin>

启动类很简单：

public class Main { public static void main(String[] args) { UndertowServer.start(AppConfig.class, 8080, true); } }

UndertowServer.start的三个参数分别是配置类、端口号、是否开启热加载。生产环境把第三个参数设为 false。

6.2 生产环境的配置调整

开发环境和生产环境的配置差异主要有几点。第一，devMode必须关掉，否则会有安全和性能问题。第二，setShowSql必须关掉，避免日志爆炸。第三，连接池参数要根据实际负载调整，生产环境建议maxActive设大一些，maxWait设小一些（快速失败比长时间等待更好）。第四，日志级别要调整，JFinal 默认用的是 SLF4J，可以通过 logback 或 log4j2 的配置文件控制。

还有一个容易被忽略的点：静态资源的处理。JFinal 默认会处理webapp目录下的静态资源，但在生产环境建议用 Nginx 来托管静态资源，JFinal 只负责动态请求。这样既能减轻应用服务器的压力，又能利用 Nginx 的缓存和压缩能力。

6.3 监控与日志的接入

JFinal 本身没有内置监控功能，但可以通过插件接入。我用的是 Druid 自带的监控页面，配置一个 Servlet 就行：

me.add(new ServletKit("/druid/*", new StatViewServlet()));

然后在浏览器访问/druid/index.html就能看到连接池的实时状态、SQL 执行统计等信息。这个在排查性能问题时非常有用。

日志方面，JFinal 用的是 SLF4J 门面，你可以在 classpath 里放 logback.xml 或 log4j2.xml 来配置。我建议至少配置两个 appender：一个输出到控制台（开发用），一个输出到文件（生产用）。文件日志要配置滚动策略，避免磁盘被写满。

实操心得：生产环境的日志级别建议设为 INFO，不要用 DEBUG。JFinal 在 DEBUG 级别下会输出大量请求细节，虽然对排查问题有帮助，但 IO 开销很大。如果确实需要排查某个接口的问题，可以临时把那个包的日志级别调到 DEBUG，排查完再调回来。

7. 我对 JFinal 的最终判断

7.1 它解决了什么问题，没解决什么问题

JFinal 解决的核心问题是：让 Java Web 开发回归简单。它没有试图成为一个“全能框架”，而是专注于把最常用的功能做到极致简洁。路由、ORM、模板、拦截器，这四个东西覆盖了 Web 开发 80% 的场景，JFinal 把这 80% 做得非常顺手。

它没有解决的问题是：复杂企业级应用的架构支撑。如果你需要分布式事务、服务治理、复杂的依赖注入和 AOP 切面，JFinal 给不了你。这不是它的设计目标，也不应该用它来评判它的好坏。

7.2 什么团队适合用它

根据我这次的评测体验，我认为以下类型的团队适合用 JFinal：

• 小型团队：1 到 3 个后端，项目周期短，迭代快，不需要复杂的架构分层。
• 内部系统：后台管理、运营工具、数据看板，这些系统业务逻辑直接，对框架的生态要求不高。
• 个人项目：想快速把想法变成可运行的产品，不想在框架配置上花太多时间。
• 教学场景：JFinal 的代码量少，结构清晰，适合用来讲解 Web 开发的核心概念。

反过来，如果你的团队已经在 Spring 生态里深耕多年，或者项目需要复杂的微服务架构，那 JFinal 可能不是最佳选择。选型这件事，适合的才是最好的。

7.3 如果重新选一次，我还会用它吗

会。但我会更明确地划定使用边界。对于我手头那些“不需要微服务、不需要复杂生态、就想快速把业务逻辑写出来”的项目，JFinal 是一个非常好的选择。它的开发效率确实高，代码量确实少，启动确实快。这些优势在中小型项目里是实打实的。

但我也清楚地知道，如果项目规模变大、团队人数增加、业务复杂度上升，我可能会考虑迁移到 Spring Boot。这不是因为 JFinal 不好，而是因为 Spring 生态在大型项目里的工具链和社区支持更成熟。技术选型从来不是一锤子买卖，而是随着项目阶段不断调整的过程。

最后分享一个我在这次评测里养成的小习惯：每次尝试一个新框架，我都会用一个真实的小项目去跑完整流程，而不是只看文档或者跑 Demo。因为文档里不会告诉你getModel和getBean的区别，不会告诉你事务要手动返回 true，不会告诉你生产环境要关掉 SQL 日志。这些细节，只有真正动手做过才会知道。JFinal 这次给我的感觉是：它不完美，但在它擅长的场景里，它做得足够好。