最近看到了一些谈延迟加载的文章，有的是直接完全复制粘贴别人的，一看复制的讲法还很浅。因此我将一些我对延迟加载的个人理解记录在这里。本文不涉及太多延迟加载的具体用法，具体用法可以参考文献1[1]。
先谈一下延迟加载的应用场景，这里借用MyBatis 延迟加载（懒加载）一篇入门[2]的说法：
前面一篇文章，介绍了多表查询，在实际使用中，我们会经常性的涉及到多表联合查询，但是有时候，并不会立即用到所有的查询结果，我来举两个例子：
例如，查询一批笔记本电脑的进货明细，而不直接展示每列明细对应电脑配置或者价格等的详细信息，等到用户需要取出某笔记本相关的详细信息的时候，再进行单表查询
再例如 ，银行中，某个用户拥有50个账户（打比方），再我们查询这个而用户的信息，这个用户下所有账户的详细信息很显然，在使用的时候再查询才是比较合理的
针对这样一种情况，延迟加载这一种机制就出现了，延迟加载（懒加载）顾名思义，就是对某种信息推迟加载，这样的技术也就帮助我们实现了 “按需查询” 的机制，在一对多，或者多对多的情况下[2]
从上面的应用场景可以看出，延迟加载的使用场景为 不管是查询list还是查询list中每个entity的详情，都调用同一接口，也就是我们的延迟加载的接口。这个接口的xml可以通过Mybatis的延迟加载的特性，在查询list的时候避免多表联查提升性能，又可以在查询详情的时候多表联查查询具体详情。
重点在于，查询list和查询详情的时候必须使用同一个接口，这样才需要用到延迟加载，才有后面的避免多表联查。如果你一开始就将查询list和查询详情分成两个接口，各查各的单表，则根本不会出现这种多表联查的问题。在工作中我实际遇到的也基本上是这样的分成两个接口的情况。具体的讲就是repository这一层提供一些基础的能力，如MybatisPlus中的list()，list(Wrapper wrapper)等，具体的业务会在service层中完成，而不会在xml中完成耦合度如此高的延迟加载。因为这样会导致将来业务发生变动时，需要改xml，而xml可能被其他仅需要一种功能的接口调用，发生不必要的问题。在代码中进行业务的编写，业务变动的时候改起来方便，也方便debug。
因此，目前来说我暂时无法想象到延迟加载的具体应用场景，推荐还是分成多个接口好一些。
参考文献
[1]，你真的懂了mybatis延迟加载吗？
[2]，MyBatis 延迟加载（懒加载）一篇入门