1.roles => roleCodes
2.roleSet => roles

1.Spring Boot 2.7.10 => 2.7.15
2.Sa-Token 1.34.0 => 1.35.0.RC
3.MyBatis Plus 3.5.3.1 => 3.5.3.2
4.Easy Excel 3.2.1 => 3.3.2
5.Hutool 5.8.16 => 5.8.20
6.Knife4j 4.1.0 => 4.3.0
7.Redisson 3.20.0 => 3.20.1
8.ip2region 2.7.6 => 2.7.15
9.spotless 2.28.0 => 2.30.0

1.优化 Spring Cache 配置
2.暂时移除 Jackson 针对数值类型：Long、BigInteger、BigDecimal 的 toString 处理（TreeUtil 疑似在字符串类型 parentId 时会出现转换异常）

Resolves #1

1.将 null 或常量值调整到符号左侧
2.将无特殊意义的方法判空写法改为表达式判断写法

1.使用 default-flat-param-object 全局设置对象型参数展示形式。此设置是在 springdoc-openapi v1.6.11 版本开始添加的新特性（详情请参阅：https://github.com/springdoc/springdoc-openapi/pull/1805），在此之前，只能在所有需要处理的对象型参数类上使用 @ParameterObject，工作量较大。
2.作者在使用上方这个配置时还遇到了一个 Bug，那就是只要在对象型参数前使用了注解，例如：@Validated PageQuery pageQuery，这个配置就不会生效了。此问题已在 GitHub 提交了相应 issue（详情请参阅：https://github.com/springdoc/springdoc-openapi/issues/2181），并且 springdoc-openapi 社区某个小伙伴儿已在当前最新发布的 v2.1.0 和 v1.7.0 中修复。
注意：由于当前使用的 Knife4j 版本其内部引入的 springdoc-openapi 相关依赖非最新版本，所以为了解决配置不生效问题，暂时将部分对象型参数移除了 @Validated 注解（除了 PageQuery，其他类当前也未实际添加校验，所以直接移除了）。当然如果不想移除的话，也可以从依赖上功夫，即移除 Knife4j 内引入的 springdoc-openapi 相关依赖，然后自行添加 springdoc-openapi 相关依赖并指定最新版本即可。

1.用户基本信息调整为实时获取
2.登录用户不再保存基本信息，降低维护成本
3.移除冗余的维护登录用户基本信息的代码

1.变更角色编码、功能权限或数据权限后，关联在线用户会自动下线
2.优化角色和菜单关联、角色和部门关联、用户和角色关联的业务代码（增加返回结果）
3.重构在线用户功能，抽取在线用户业务实现

1.在页面导航栏中通过[页面配置]>[菜单来源于后台]临时启用，刷新后配置失效
2.在前端项目 src/config/setting.json 中，可通过 menuFromServer 配置永久启用

1.基于 MyBatis Plus DataPermissionInterceptor 插件实现的数据权限功能
2.通过在指定 Mapper 接口层方法添加 @DataPermission 注解实现数据权限

1.MySQL数据库>建表规约>第9条：
【强制】表必备三字段：id，create_time，update_time。
说明：其中 id 必为主键，类型为 bigint unsigned、单表时自增、步长为 1。create_time，update_time 的类型均为datetime 类型，如果要记录时区信息，那么类型设置为 timestamp。
个人理解：简化列名的目的是为了后续能抽取更多公共能力
2.MySQL数据库>SQL语句>第10条：
【推荐】SQL 语句中表的别名前加 as，并且以 t1、t2、t3、...的顺序依次命名。
说明：
  1）别名可以是表的简称，或者是依照表在 SQL 语句中出现的顺序，以 t1、t2、t3 的方式命名。
  2）别名前加 as 使别名更容易识别。
正例：select t1.name from first_table as t1 , second_table as t2 where t1.id = t2.id;

1.编程规约>命名风格>第14条：
【推荐】在常量与变量命名时，表示类型的名词放在词尾，以提升辨识度。
正例：startTime / workQueue / nameList / TERMINATED_THREAD_COUNT
反例：startedAt / QueueOfWork / listName / COUNT_TERMINATED_THREAD
2.编程规约>命名风格>第19条：
【参考】各层命名规约：
  A）Service / DAO 层方法命名规约：
  1）获取单个对象的方法用 get 做前缀。
  2）获取多个对象的方法用 list 做前缀，复数结尾，如：listObjects
  3）获取统计值的方法用 count 做前缀。
  4）插入的方法用 save / insert 做前缀。
  5）删除的方法用 remove / delete 做前缀。
  6）修改的方法用 update 做前缀。
个人理解及应用 🔥：
  1)在变量命名方面：
    a)方法体内局部变量，命名时表示类型的名词放在词尾，以提升辨识度；
      正例：nameList、nameArr。
    b)方法声明上参数（局部变量），命名时尽量采用复数形式，以和方法名保持一致；
      正例：List<String> listNameByIds(List<Long> ids);
    c)成员变量，命名时尽量采用复数形式。
  2)在方法命名方面：
    a)CRUD 类方法可以简化命名；
      正例：UserService：page、list、add、update、delete...;
      说明：UserService 是围绕 User 为核心的业务接口，简化命名的方法也很容易理解操作的是什么。
    b)其他方法，查询信息名词采用单数（与其纠结单数、复数，那就用单数，简单粗暴一点），以上述第2条要求为命名前缀。
      正例：RoleService：listNameByIds（根据 ID 查询名称列表）
           RoleService：listRoleCodeByUserId（根据用户 ID 查询角色编码列表）
           UserRoleService：listRoleIdByUserId（根据用户 ID 查询角色 ID 列表）
           UserService：getByUsername（根据用户名查询用户）

1.编程规约>OOP规约>第20条：
【推荐】当一个类有多个构造方法，或者多个同名方法，这些方法应该按顺序放置在一起，便于阅读，
此条规则优先于下一条。
2.编程规约>OOP规约>第21条：
【推荐】类内方法定义的顺序依次是：公有方法或保护方法 > 私有方法 > getter / setter 方法。
说明：公有方法是类的调用者和维护者最关心的方法，首屏展示最好；保护方法虽然只是子类关心，也可能是“模板设
计模式”下的核心方法；而私有方法外部一般不需要特别关心，是一个黑盒实现；因为承载的信息价值较低，所有
Service 和 DAO 的 getter / setter 方法放在类体最后。
3.编程规约>OOP规约>第26条：
【推荐】类成员与方法访问控制从严：
  1）如果不允许外部直接通过 new 来创建对象，那么构造方法必须是 private。
  2）工具类不允许有 public 或 default 构造方法。
  3）类非 static 成员变量并且与子类共享，必须是 protected。
  4）类非 static 成员变量并且仅在本类使用，必须是 private。
  5）类 static 成员变量如果仅在本类使用，必须是 private。
  6）若是 static 成员变量，考虑是否为 final。
  7）类成员方法只供类内部调用，必须是 private。
  8）类成员方法只对继承类公开，那么限制为 protected。
  说明：任何类、方法、参数、变量，严控访问范围。过于宽泛的访问范围，不利于模块解耦。思考：如果是一个
  private 的方法，想删除就删除，可是一个 public 的 service 成员方法或成员变量，删除一下，不得手心冒点汗吗？
  变量像自己的小孩，尽量在自己的视线内，变量作用域太大，无限制的到处跑，那么你会担心的。

1.编程规约>常量定义>第4条：
【推荐】不要使用一个常量类维护所有常量，要按常量功能进行归类，分开维护。
说明：大而全的常量类，杂乱无章，使用查找功能才能定位到要修改的常量，不利于理解，也不利于维护。
正例：缓存相关常量放在类 CacheConsts 下；系统配置相关常量放在类 SystemConfigConsts 下。
2.编程规约>常量定义>第5条：
【推荐】常量的复用层次有五层：跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常
量、类内共享常量。
  1）跨应用共享常量：放置在二方库中，通常是 client.jar 中的 constant 目录下。
  2）应用内共享常量：放置在一方库中，通常是子模块中的 constant 目录下。
  反例：易懂常量也要统一定义成应用内共享常量，两个程序员在两个类中分别定义了表示“是”的常量：
  类 A 中：public static final String YES = "yes";
  类 B 中：public static final String YES = "y";
  A.YES.equals(B.YES)，预期是 true，但实际返回为 false，导致线上问题。
  3）子工程内部共享常量：即在当前子工程的 constant 目录下。
  4）包内共享常量：即在当前包下单独的 constant 目录下。
  5）类内共享常量：直接在类内部 private static final 定义。

1.后端 API 注解鉴权使用方式：@SaCheckPermission("system:user:add")
2.前端全局指令函数使用方式：v-permission="['system:user:add']"
3.前端权限判断函数使用方式：checkPermission(['system:user:add'])