很多基于 jfinal 自动扫描路由的扩展可用

建议先试用两天 jfinal 默认的方式，少了注解代码其实更干净

@JFinal 建议波总还是基础功能中加上基础的Get 、Post之类的路由注解吧。 感觉比单独的用Route类管理要方便一些。

@JFinal 自动扫描路由是啥？我等会了解一下。能给个案例教程或者链接吗？

@JFinal 你想，你设计jfinal的 ActiveRecord 时候，初衷有没包含了一个念头？尽量减少关注配置的时间？那现在路由变成了配置，让我觉得我得关注的编码的文件就多了起来。感觉又回到了xml配置的时代。

@itdoer jfinal 发布 7 年多以来，不断有人问起这个问题，在不同渠道回复这个问题起码重复过 100 次以上

既然这么关心这个问题，在此仅简要回答一下。自动扫描很多缺点：
1：安全性大大降低。第三方 jar 包中可以放点注解让你扫描成路由，然后就可以很轻松接管你的系统了。回看一下 springboot 项目动不动就上百个 jar 包，你敢确定上百个 jar 包中没给你来点路由注解让你扫描？

2：拖慢启动速度。路由扫描在大概率上慢 100 倍不止，启动速度在生产环境下不算大问题，但是开发环境就不同了，开发阶段启动花 2 秒与启动花 8 秒，这个开发体验是有很大差别的。要知道开发的时候改点东西重启项目是很频繁的，累积下来的时间是很可观的

3：代码量与学习成本双双增加。spring 那种在 action 上添加注解的方式，每个方法上都要来那么一下注解，而 jfinal 非注解方式每个 controller 仅一行代码即可配置一系列的路由。 此外，引入的注解的用法，你也是要花时间学习的，多多少少会有学习成本

4：无法为某个 controller 指定 viewPath

5：不支持 Routes 级别的 AOP，也即无法为某一批 controller 指定拦截器，如果你加入俱乐部得到 jfinal club 项目的话，就会体会到 Routes AOP 的妙处，节省代码无数

6：路由分散不利于统一管理。例如哪天你要重新规范路由，jfinal 在一处统一管理路由，要改下类似于一组 Controller 的 controllerKey 是极为方便的。即便是你只想改个别路由，你也得去找到具体的 controller 去翻找路由，这个时间相对要长。

7：路由分散也不便于统一查看。统一在一处的路由很方便去查看，浏览一下即可对全局路由心中有数，散落在各处的路由你得所有 Controller 全浏览一遍

8：统一的路由便于引导 restful 设计风格，统一路由将一个 controller 引导抽象成一个资源，所以就拥有了统一的资源名称，例如 AccountController 的资源名被引导为一个 "/account"，这样避免了使用注解时的随意行为

简要说一下 jfinal 的路由配置有独有的优点：
1：支持 Routes 级别的 AOP
2：支持 Routes 级别的 baseViewPath
3：支持 Controller 级别的 viewPath
4：极速启动，在启动时一次性初始化，极有可能是目前最快的路由匹配方式

此外，你还谈到了 xml 配置，jfinal 的路由配置与 XML 有关本质的不同，前者是 java 代码，后者是外部文本配置，前者代码量极少，后者代码多且十分繁琐且易于出错

最后，这个问题本质是一个习惯问题，当然习惯确实难以改变，关键要看使用者是不是有一颗开放的乐意尝试新事务的心