爆款云主机2核4G限时秒杀,88元/年起!
查看详情

活动

天翼云最新优惠活动,涵盖免费试用,产品折扣等,助您降本增效!
热门活动
  • 618智算钜惠季 爆款云主机2核4G限时秒杀,88元/年起!
  • 免费体验DeepSeek,上天翼云息壤 NEW 新老用户均可免费体验2500万Tokens,限时两周
  • 云上钜惠 HOT 爆款云主机全场特惠,更有万元锦鲤券等你来领!
  • 算力套餐 HOT 让算力触手可及
  • 天翼云脑AOne NEW 连接、保护、办公,All-in-One!
  • 中小企业应用上云专场 产品组合下单即享折上9折起,助力企业快速上云
  • 息壤高校钜惠活动 NEW 天翼云息壤杯高校AI大赛,数款产品享受线上订购超值特惠
  • 天翼云电脑专场 HOT 移动办公新选择,爆款4核8G畅享1年3.5折起,快来抢购!
  • 天翼云奖励推广计划 加入成为云推官,推荐新用户注册下单得现金奖励
免费活动
  • 免费试用中心 HOT 多款云产品免费试用,快来开启云上之旅
  • 天翼云用户体验官 NEW 您的洞察,重塑科技边界

智算服务

打造统一的产品能力,实现算网调度、训练推理、技术架构、资源管理一体化智算服务
智算云(DeepSeek专区)
科研助手
  • 算力商城
  • 应用商城
  • 开发机
  • 并行计算
算力互联调度平台
  • 应用市场
  • 算力市场
  • 算力调度推荐
一站式智算服务平台
  • 模型广场
  • 体验中心
  • 服务接入
智算一体机
  • 智算一体机
大模型
  • DeepSeek-R1-昇腾版(671B)
  • DeepSeek-R1-英伟达版(671B)
  • DeepSeek-V3-昇腾版(671B)
  • DeepSeek-R1-Distill-Llama-70B
  • DeepSeek-R1-Distill-Qwen-32B
  • Qwen2-72B-Instruct
  • StableDiffusion-V2.1
  • TeleChat-12B

应用商城

天翼云精选行业优秀合作伙伴及千余款商品,提供一站式云上应用服务
进入甄选商城进入云市场创新解决方案
办公协同
  • WPS云文档
  • 安全邮箱
  • EMM手机管家
  • 智能商业平台
财务管理
  • 工资条
  • 税务风控云
企业应用
  • 翼信息化运维服务
  • 翼视频云归档解决方案
工业能源
  • 智慧工厂_生产流程管理解决方案
  • 智慧工地
建站工具
  • SSL证书
  • 新域名服务
网络工具
  • 翼云加速
灾备迁移
  • 云管家2.0
  • 翼备份
资源管理
  • 全栈混合云敏捷版(软件)
  • 全栈混合云敏捷版(一体机)
行业应用
  • 翼电子教室
  • 翼智慧显示一体化解决方案

合作伙伴

天翼云携手合作伙伴,共创云上生态,合作共赢
天翼云生态合作中心
  • 天翼云生态合作中心
天翼云渠道合作伙伴
  • 天翼云代理渠道合作伙伴
天翼云服务合作伙伴
  • 天翼云集成商交付能力认证
天翼云应用合作伙伴
  • 天翼云云市场合作伙伴
  • 天翼云甄选商城合作伙伴
天翼云技术合作伙伴
  • 天翼云OpenAPI中心
  • 天翼云EasyCoding平台
天翼云培训认证
  • 天翼云学堂
  • 天翼云市场商学院
天翼云合作计划
  • 云汇计划
天翼云东升计划
  • 适配中心
  • 东升计划
  • 适配互认证

开发者

开发者相关功能入口汇聚
技术社区
  • 专栏文章
  • 互动问答
  • 技术视频
资源与工具
  • OpenAPI中心
开放能力
  • EasyCoding敏捷开发平台
培训与认证
  • 天翼云学堂
  • 天翼云认证
魔乐社区
  • 魔乐社区

支持与服务

为您提供全方位支持与服务,全流程技术保障,助您轻松上云,安全无忧
文档与工具
  • 文档中心
  • 新手上云
  • 自助服务
  • OpenAPI中心
定价
  • 价格计算器
  • 定价策略
基础服务
  • 售前咨询
  • 在线支持
  • 在线支持
  • 工单服务
  • 建议与反馈
  • 用户体验官
  • 服务保障
  • 客户公告
  • 会员中心
增值服务
  • 红心服务
  • 首保服务
  • 客户支持计划
  • 专家技术服务
  • 备案管家

了解天翼云

天翼云秉承央企使命,致力于成为数字经济主力军,投身科技强国伟大事业,为用户提供安全、普惠云服务
品牌介绍
  • 关于天翼云
  • 智算云
  • 天翼云4.0
  • 新闻资讯
  • 天翼云APP
基础设施
  • 全球基础设施
  • 信任中心
最佳实践
  • 精选案例
  • 超级探访
  • 云杂志
  • 分析师和白皮书
  • 天翼云·创新直播间
市场活动
  • 2025智能云生态大会
  • 2024智算云生态大会
  • 2023云生态大会
  • 2022云生态大会
  • 天翼云中国行
天翼云
  • 活动
  • 智算服务
  • 产品
  • 解决方案
  • 应用商城
  • 合作伙伴
  • 开发者
  • 支持与服务
  • 了解天翼云
      • 文档
      • 控制中心
      • 备案
      • 管理中心

      Executor 拦截器高级教程 - QueryInterceptor 规范

      首页 知识中心 其他 文章详情页

      Executor 拦截器高级教程 - QueryInterceptor 规范

      2024-03-18 08:30:36 阅读次数:53

      Executor,mybatis,拦截器

      Executor 拦截器高级教程 - QueryInterceptor 规范

      这篇文档涉及下面几个方面
      1. Executor query 方法介绍
      2. 拦截器配置和调用顺序
      3. 拦截 query 方法的技巧
      4. 拦截 query 方法的规范
      5. 如何配置不同的 Executor 插件

      1. Executor query 方法介绍

      在 MyBatis 的拦截器的文档部分,我们知道 Executor 中的 query 方法可以被拦截,如果你真正写过这个方法的拦截器,你可能会知道在 Executor 中的 query 方法有两个:

      <E> List<E> query(
      MappedStatement ms,
      Object parameter,
      RowBounds rowBounds,
      ResultHandler resultHandler,
      CacheKey cacheKey,
      BoundSql boundSql) throws SQLException;

      <E> List<E> query(
      MappedStatement ms,
      Object parameter,
      RowBounds rowBounds,
      ResultHandler resultHandler) throws

      这两个方法的区别是第一个方法多两个参数 CacheKey 和 BoundSql,在多数情况下,我们用拦截器的目的就是针对 SQL 做处理,如果能够拦截第一个方法,可以直接得到 BoundSql 对象,就会很容易的得到执行的 SQL,也可以对 SQL 做处理。

      虽然想的很好,但是 MyBatis 提供的 Exctutor 实现中,参数多的这个 query 方法都是被少的这个 query 方法在内部进行调用的。

      在 ​​CachingExecutor​​ 中:

      public <E> List<E> query(
      MappedStatement ms,
      Object parameter,
      RowBounds rowBounds,
      ResultHandler resultHandler) throws SQLException {
      BoundSql boundSql = ms.getBoundSql(parameterObject);
      CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);
      return

      在 ​​BaseExecutor​​ 中:

      public <E> List<E> query(
      MappedStatement ms,
      Object parameter,
      RowBounds rowBounds,
      ResultHandler resultHandler) throws SQLException {
      BoundSql boundSql = ms.getBoundSql(parameter);
      CacheKey key = createCacheKey(ms, parameter, rowBounds, boundSql);
      return

      上面这两个方法一样。由于第一个 query 方法在这里是内部调用,并且我们所有的拦截器都是层层代理的 ​​CachingExecutor​​​ 或基于 ​​BaseExecutor​​ 的实现类,所以我们能拦截的就是参数少的这个方法。

      分页插件开始从 Executor 拦截开始就一直是拦截的参数少的这个方法。但是从 5.0 版本开始,query 的这两个方法都可以被拦截了。在讲这个原理之前,我们先了解一下拦截器的执行顺序。

      2. 拦截器配置和调用顺序

      拦截器的调用顺序分为两大种,第一种是拦截的不同对象,例如拦截 Executor 和 拦截 StatementHandler 就属于不同的拦截对象,这两类的拦截器在整体执行的逻辑上是不同的,在 Executor 中的 query 方法执行过程中,会调用下面的代码:

      public <E> List<E> doQuery(
      MappedStatement ms,
      Object parameter,
      RowBounds rowBounds,
      ResultHandler resultHandler,
      BoundSql boundSql) throws SQLException {
      Statement stmt = null;
      try {
      Configuration configuration = ms.getConfiguration();
      StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, resultHandler, boundSql);
      stmt = prepareStatement(handler, ms.getStatementLog());
      return handler.<E>query(stmt, resultHandler);
      } finally

      在这段代码中,才会轮到 StatementHandler 去执行,StatementHandler 属于 Executor 执行过程中的一个子过程。所以这两种不同类别的插件在配置时,一定是先执行 Executor 的拦截器,然后才会轮到 StatementHandler。所以这种情况下配置拦截器的顺序就不重要了,在 MyBatis 逻辑上就已经控制了先后顺序。

      第二种拦截器的顺序就是指拦截同一种对象的同一个方法,例如都拦截 Executor 的 query 方法,这时你配置拦截器的顺序就会对这里有影响了。假设有如下几个拦截器,都是拦截的 Executor 的 query 方法。

      <plugins>
      <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor1"/>
      <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor2"/>
      <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor3"/>
      </plugins>

      在​​org.apache.ibatis.session.Configuration​​ 中有如下方法:

      public void addInterceptor(Interceptor interceptor) {
      interceptorChain.addInterceptor(interceptor);
      }

      MyBatis 会按照拦截器配置的顺序依次添加到 interceptorChain 中,其内部就是 ​​List<Interceptor> interceptors​​​。再看 ​​Configuration​​ 中创建 Executor 的代码:

      public Executor newExecutor(Transaction transaction, ExecutorType executorType) {
      executorType = executorType == null ? defaultExecutorType : executorType;
      executorType = executorType == null ? ExecutorType.SIMPLE : executorType;
      Executor executor;
      if (ExecutorType.BATCH == executorType) {
      executor = new BatchExecutor(this, transaction);
      } else if (ExecutorType.REUSE == executorType) {
      executor = new ReuseExecutor(this, transaction);
      } else {
      executor = new SimpleExecutor(this, transaction);
      }
      if (cacheEnabled) {
      executor = new CachingExecutor(executor);
      }
      executor = (Executor) interceptorChain.pluginAll(executor);
      return

      在调用 interceptorChain.pluginAll 之前,executor 就是前一节中的 ​​CachingExecutor​​​ 或基于 ​​BaseExecutor​​ 的实现类。然后看 interceptorChain.pluginAll 方法:

      public Object pluginAll(Object target) {
      for (Interceptor interceptor : interceptors) {
      target = interceptor.plugin(target);
      }
      return

      前面我们配置拦截器的顺序是1,2,3。在这里也会按照 1,2,3 的顺序被层层代理,代理后的结构如下:

      Interceptor3:{
      Interceptor2: {
      Interceptor1: {
      target: Executor
      }
      }
      }

      从这个结构应该就很容易能看出来,将来执行的时候肯定是按照 3>2>1>Executor>1>2>3 的顺序去执行的。可能有些人不知道为什么3>2>1>Executor之后会有1>2>3,这是因为使用代理时,调用完代理方法后,还能继续进行其他处理。处理结束后,将代理方法的返回值继续往外返回即可。例如:

      Interceptor3 前置处理      
      Object result = Interceptor2..query(4个参数方法);
      Interceptor3 后续处理
      return result;

      对于 Interceptor2.invoke 方法也是相同的逻辑:

      Interceptor2 前置处理      
      Object result = Interceptor1..query(4个参数方法);
      Interceptor2 后续处理
      return result;

      同理 Interceptor1.invoke :

      Interceptor1 前置处理      
      Object result = executor.query(4个参数方法);
      Interceptor1 后续处理
      return result;

      叠加到一起后,如下:

      Interceptor3 前置处理
      Interceptor2 前置处理
      Interceptor1 前置处理
      Object result = executor.query(4个参数方法);
      Interceptor1 后续处理
      Interceptor2 后续处理
      Interceptor3 后续处理
      return result;

      所以这个顺序就是 3>2>1>Executor>1>2>3。

      在你弄清楚这个逻辑后,再继续往下看,因为后面的技巧会颠覆这个逻辑,所以才会有后面的规范以及如何配置不同的插件。

      3. 拦截 query 方法的技巧

      上一节的内容中,对拦截器的用法是最常见的一种用法,所以才会出现这种都能理解的执行顺序。但是分页插件 5.0 不是这样,这个插件颠覆了这种顺序,这种颠覆其实也很普通,这也是本节要说的技巧。

      在我写作 MyBatis 技术书籍的过程中(还没写完,已经因为分页插件占用了几周的写作时间),我就在考虑为什么不能拦截第一个 query(6个参数的)方法,如果能拦截这个方法,就可以直接拿到 BoundSql,然后处理 SQL 就很容易实现其他的操作。

      在第 1 节介绍为什么第一个 query 方法不能被拦截时,是因为下面这段代码:

      public <E> List<E> query(
      MappedStatement ms,
      Object parameter,
      RowBounds rowBounds,
      ResultHandler resultHandler) throws SQLException {
      BoundSql boundSql = ms.getBoundSql(parameter);
      CacheKey key = createCacheKey(ms, parameter, rowBounds, boundSql);
      return

      既然 ​​CachingExecutor​​​ 或基于 ​​BaseExecutor​​ 的实现类只是这么简单的调用两个方法得到了 BoundSql 和 Cachekey,我们为什么不直接替代他们呢?

      所以我们可以有类似下面的拦截器用法:

      @Intercepts(@Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}))
      public class QueryInterceptor implements Interceptor

      @Override
      public Object intercept(Invocation invocation) throws Throwable {
      Object[] args = invocation.getArgs();
      MappedStatement ms = (MappedStatement) args[0];
      Object parameterObject = args[1];
      RowBounds rowBounds = (RowBounds) args[2];
      ResultHandler resultHandler = (ResultHandler) args[3];
      Executor executor = (Executor) invocation.getTarget();
      BoundSql boundSql = ms.getBoundSql(parameterObject);
      //可以对参数做各种处理
      CacheKey cacheKey = executor.createCacheKey(ms, parameterObject, rowBounds, boundSql);
      return executor.query(ms, parameterObject, rowBounds, resultHandler, cacheKey, boundSql);
      }

      @Override
      public Object plugin(Object target) {
      return Plugin.wrap(target, this);
      }

      @Override
      public void setProperties(Properties properties) {
      }

      }

      这个拦截器直接替代了原有 Executor 的部分逻辑,直接去调用了 6 个参数的方法,因而导致 4 个参数的后续方法被跳过了。但是由于这里的 executor 是代理对象,所以 6 个参数的 query 方法可以被代理了,这就扰乱了上一节中的执行顺序。

      在上一节拦截器的例子中,做简单修改,将 ExecutorQueryInterceptor2 换成上面的 QueryInterceptor,配置如下:

      <plugins>
      <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor1"/>
      <plugin interceptor="com.github.pagehelper.QueryInterceptor"/>
      <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor3"/>
      </plugins>

      代理后的结构如下:

      Interceptor3:{
      QueryInterceptor: {
      Interceptor1: {
      target: Executor
      }
      }
      }

      这时,调用顺序就变了,Interceptor3 执行顺序如下:

      Interceptor3 前置处理      
      Object result = QueryInterceptor.query(4个参数方法);
      Interceptor3 后续处理
      return result;

      QueryInterceptor.invoke 执行逻辑如下:

      Interceptor2 前置处理      
      Object result = executor.query(6个参数方法);
      Interceptor2 后续处理
      return result;

      在 QueryInterceptor 中,没有继续执行 4个参数方法,而是执行了 6 个参数方法。但是 Interceptor1 拦截的 4 个参数的方法,所以 Interceptor1 就被跳过去了,整体的执行逻辑就变成下面这样了:

      Interceptor3 前置处理
      Interceptor2 前置处理
      Object result = executor.query(6个参数方法);
      Interceptor2 后续处理
      Interceptor3 后续处理
      return result;

      如果 Interceptor1 拦截的是 6 个参数的方法,因为 QueryInterceptor 获取的是 Interceptor1 代理的 executor 对象,那么 Interceptor1 就会被 QueryInterceptor 继续执行下去。

      分页插件就是类似 QueryInterceptor 的执行逻辑,所以当你使用 5.0 版本之后的插件时,如果你还需要配置其他 Executor 的 query 插件,你就会遇到一些问题(可以解决,继续往下看)。

      如果你是自己开发的插件,那么你按照下一节的规范去开发也不会遇到问题。如果你使用的其他人提供的插件,按照第 5 节的配置顺序也能解决问题。

      4. 拦截 query 方法的规范

      QueryInterceptor 的逻辑就是进去的是 4 个参数的方法,出去的是 6 个参数的方法。这种处理方法不仅仅不方便和一般的 Excutor 拦截器搭配使用,当出现两个以上类似 QueryInterceptor 的插件时,由于接口变了,类似 QueryInterceptor 插件也无法连贯的执行下去。因而有必要解决这个问题。解决的办法就是使用统一的规范。经过规范后 QueryInterceptor 如下:

      @Intercepts(
      {
      @Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}),
      @Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class, CacheKey.class, BoundSql.class}),
      }
      )
      public class QueryInterceptor implements Interceptor

      @Override
      public Object intercept(Invocation invocation) throws Throwable {
      Object[] args = invocation.getArgs();
      MappedStatement ms = (MappedStatement) args[0];
      Object parameterObject = args[1];
      RowBounds rowBounds = (RowBounds) args[2];
      ResultHandler resultHandler = (ResultHandler) args[3];
      Executor executor = (Executor) invocation.getTarget();
      CacheKey cacheKey;
      BoundSql boundSql;
      //由于逻辑关系,只会进入一次
      if(args.length == 4){
      //4 个参数时
      boundSql = ms.getBoundSql(parameterObject);
      cacheKey = executor.createCacheKey(ms, parameterObject, rowBounds, boundSql);
      } else {
      //6 个参数时
      cacheKey = (CacheKey) args[4];
      boundSql = (BoundSql) args[5];
      }
      //TODO 自己要进行的各种处理
      //注:下面的方法可以根据自己的逻辑调用多次,在分页插件中,count 和 page 各调用了一次
      return executor.query(ms, parameterObject, rowBounds, resultHandler, cacheKey, boundSql);
      }

      @Override
      public Object plugin(Object target) {
      return Plugin.wrap(target, this);
      }

      @Override
      public void setProperties(Properties properties) {
      }

      }

      注意两个变化,第一个就是拦截器签名同时拦截了 4 个 和 6 个参数的方法,这样不管那个插件在前在后都会被执行。

      第二个变化就是这段代码:

      CacheKey cacheKey;
      BoundSql boundSql;
      //由于逻辑关系,只会进入一次
      if(args.length == 4){
      //4 个参数时
      boundSql = ms.getBoundSql(parameterObject);
      cacheKey = executor.createCacheKey(ms, parameterObject, rowBounds, boundSql);
      } else {
      //6 个参数时
      cacheKey = (CacheKey) args[4];
      boundSql = (BoundSql) args[5];
      }

      如果这个插件配置的靠后,是通过 4 个参数方法进来的,我们就获取这两个对象。如果这个插件配置的靠前,已经被别的拦截器处理成 6 个参数的方法了,那么我们直接从 args 中取出这两个参数直接使用即可。取出这两个参数就保证了当其他拦截器对这两个参数做过处理时,这两个参数在这里会继续生效。

      假设有个排序插件和分页插件,排序插件将 BoundSql 修改为带排序的 SQL 后,SQL 会继续交给分页插件使用。分页插件的分页 SQL 执行时,会保留排序去执行,这样的规范就保证了两个插件都能正常的执行下去。

      所以如果大家想要使用这种方式去实现拦截器,建议大家遵守这个规范。

      这个规范对于已经存在的插件来说就没法控制了,但是仍然可以通过配置顺序来解决。

      5. 如何配置不同的 Executor 插件

      当引入类似 QueryInterceptor 插件时,由于扰乱了原有的插件执行方式,当配置 Executor 顺序不对时会导致插件无法生效。

      第 4 节中的例子:

      <plugins>
      <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor1"/>
      <plugin interceptor="com.github.pagehelper.QueryInterceptor"/>
      <plugin interceptor="com.github.pagehelper.ExecutorQueryInterceptor3"/>
      </plugins>

      首先执行顺序为 3>Query>1>Executor,由于 Query 是 4 或 6 个参数进来,6 个参数出去。所以在 Query 前面执行的拦截器必须是 4 个的(Query 规范拦截器先后都能执行,需要根据逻辑配置先后)参数的,在 Query 后面执行的拦截器必须是 6 个参数的。

      这个顺序对应到配置顺序时,也就是 4 个参数的配置在 QueryInterceptor 拦截器的下面,6 个参数的配置在 QueryInterceptor 拦截器的上面。按照这个顺序进行配置时,就能保证拦截器都执行。

      如果你想获得如分页插件(QueryInterceptor 规范)执行的 SQL,你就得按照 QueryInterceptor 规范去实现,否则只能配置在分页插件的下面,也就只能获得分页处理前的 SQL。

      版权声明:本文内容来自第三方投稿或授权转载,原文地址:https://blog.51cto.com/isea533/5594552,作者:isea533,版权归原作者所有。本网站转在其作品的目的在于传递更多信息,不拥有版权,亦不承担相应法律责任。如因作品内容、版权等问题需要同本网站联系,请发邮件至ctyunbbs@chinatelecom.cn沟通。

      上一篇:POI3.5_HSSF_和XSSF_Excel操作快速入门

      下一篇:WebStrom如何设置字体?

      相关文章

      2025-05-19 09:04:30

      token以及axios响应拦截器请求拦截器

      token以及axios响应拦截器请求拦截器

      2025-05-19 09:04:30
      axios , token , 拦截器 , 登录 , 跳转
      2025-05-07 09:07:56

      SpringMVC 拦截器开发详解

      SpringMVC 拦截器开发详解

      2025-05-07 09:07:56
      处理器 , 执行 , 拦截器 , 方法 , 请求
      2025-04-18 07:09:19

      SpringMVC 执行流程详解

      SpringMVC 是 Java Web 开发中广泛应用的 MVC 框架,它以其高效、灵活的设计受到了开发者的青睐。

      2025-04-18 07:09:19
      SpringMVC , 处理器 , 执行 , 拦截器 , 方法 , 视图 , 请求
      2025-03-28 07:41:43

      使用 Axios 拦截器优化 HTTP 请求与响应的实践

      使用 Axios 拦截器优化 HTTP 请求与响应的实践

      2025-03-28 07:41:43
      Axios , HTTP , 代码 , 响应 , 拦截器 , 请求
      2025-03-26 09:05:38

      Mybatis遇到No constructor found in ....的解决方法

      在使用mybatis时,偶尔遇到了“No constructor found in .....”的问题,根据问题的提示可以看出,应该是构造方法引起的异常,经测试,当引用的实体重构了构造方法之后就会出现这个问题,因为mybatis需要用到默认构造方法,明确一个默认构造方法即可解决。

      2025-03-26 09:05:38
      mybatis , 构造方法 , 默认
      2025-03-25 08:08:18

      ssm(Spring+Spring mvc+mybatis)Service层接口——IDeptService

      ssm(Spring+Spring mvc+mybatis)Service层接口——IDeptService

      2025-03-25 08:08:18
      mvc , mybatis , Service , Spring
      2025-03-12 09:34:29

      【问题已解决】Caused by: java.lang.IllegalStateException

      【问题已解决】Caused by: java.lang.IllegalStateException

      2025-03-12 09:34:29
      application , config , mybatis , xml
      2025-03-06 09:41:26

      【SpringBoot】深度解析 Spring Boot 拦截器:实现统一功能处理的关键路径

      【SpringBoot】深度解析 Spring Boot 拦截器:实现统一功能处理的关键路径

      2025-03-06 09:41:26
      定义 , 拦截 , 拦截器 , 登录 , 请求
      2025-03-04 09:13:56

      springboot整合mybatis-plus超快速

      springboot整合mybatis-plus超快速

      2025-03-04 09:13:56
      Mapper , mybatis , springboot
      2025-02-25 08:57:34

      Java注解

      Java注解

      2025-02-25 08:57:34
      Java , 拦截器 , 注解 , 登录 , 自定义 , 访问
      查看更多
      推荐标签

      作者介绍

      天翼云小翼
      天翼云用户

      文章

      33561

      阅读量

      5244169

      查看更多

      最新文章

      token以及axios响应拦截器请求拦截器

      2025-05-19 09:04:30

      Mybatis遇到No constructor found in ....的解决方法

      2025-03-26 09:05:38

      【问题已解决】Caused by: java.lang.IllegalStateException

      2025-03-12 09:34:29

      springboot整合mybatis-plus超快速

      2025-03-04 09:13:56

      spring+mybatis启动NoClassDefFoundError异常分析三部曲之二:定位错误

      2024-11-20 09:46:57

      mybatis中使用where in查询时的注意事项

      2024-11-05 08:39:50

      查看更多

      热门文章

      not known to the MapperRegistry

      2024-09-25 10:14:48

      nested exception is org.apache.ibatis.type.TypeException: Could not set parameters for mapping错误的决方法

      2024-09-25 10:14:21

      Mybatis系列之分页问题

      2023-05-04 09:17:10

      struts、hibernate、spring、 mybatis、 spring boot 等面试题汇总

      2023-06-19 06:56:28

      关于mybatis 注释

      2023-05-19 05:50:50

      Cause: org.apache.ibatis.type.TypeException: Error setting non null for xxx with JdbcType错误的详细解决方法

      2024-09-25 10:14:21

      查看更多

      热门标签

      linux java python javascript 数组 前端 docker Linux vue 函数 shell git 节点 容器 示例
      查看更多

      相关产品

      弹性云主机

      随时自助获取、弹性伸缩的云服务器资源

      天翼云电脑(公众版)

      便捷、安全、高效的云电脑服务

      对象存储

      高品质、低成本的云上存储服务

      云硬盘

      为云上计算资源提供持久性块存储

      查看更多

      随机文章

      Mybatis 示例之 Association (2)

      mybatis 拦截器

      mybatis中使用where in查询时的注意事项

      使用mybatis自动生成指定规则的编号

      MyBatis 3.3.1 版本新功能示例

      Mybatis中IN语句查询、Mybatis中的foreach用法

      • 7*24小时售后
      • 无忧退款
      • 免费备案
      • 专家服务
      售前咨询热线
      400-810-9889转1
      关注天翼云
      • 旗舰店
      • 天翼云APP
      • 天翼云微信公众号
      服务与支持
      • 备案中心
      • 售前咨询
      • 智能客服
      • 自助服务
      • 工单管理
      • 客户公告
      • 涉诈举报
      账户管理
      • 管理中心
      • 订单管理
      • 余额管理
      • 发票管理
      • 充值汇款
      • 续费管理
      快速入口
      • 天翼云旗舰店
      • 文档中心
      • 最新活动
      • 免费试用
      • 信任中心
      • 天翼云学堂
      云网生态
      • 甄选商城
      • 渠道合作
      • 云市场合作
      了解天翼云
      • 关于天翼云
      • 天翼云APP
      • 服务案例
      • 新闻资讯
      • 联系我们
      热门产品
      • 云电脑
      • 弹性云主机
      • 云电脑政企版
      • 天翼云手机
      • 云数据库
      • 对象存储
      • 云硬盘
      • Web应用防火墙
      • 服务器安全卫士
      • CDN加速
      热门推荐
      • 云服务备份
      • 边缘安全加速平台
      • 全站加速
      • 安全加速
      • 云服务器
      • 云主机
      • 智能边缘云
      • 应用编排服务
      • 微服务引擎
      • 共享流量包
      更多推荐
      • web应用防火墙
      • 密钥管理
      • 等保咨询
      • 安全专区
      • 应用运维管理
      • 云日志服务
      • 文档数据库服务
      • 云搜索服务
      • 数据湖探索
      • 数据仓库服务
      友情链接
      • 中国电信集团
      • 189邮箱
      • 天翼企业云盘
      • 天翼云盘
      ©2025 天翼云科技有限公司版权所有 增值电信业务经营许可证A2.B1.B2-20090001
      公司地址:北京市东城区青龙胡同甲1号、3号2幢2层205-32室
      • 用户协议
      • 隐私政策
      • 个人信息保护
      • 法律声明
      备案 京公网安备11010802043424号 京ICP备 2021034386号