ak1ak

@wanghaoxu 你这种方式我没有试过，不过理论上提供一个额外的 PropertySource 似乎和直接在 application.properties 中指定没有区别 （逃。我看了下 jasypt-spring-boot GitHub 上的文档中处理自身配置的说明，是根据一个 EncryptablePropertyFilter 实例来过滤掉特定配置避免循环依赖的问题的。所以我仿照它的写法，提供一个同名的 Bean ，然后用 `@Lazy` + 构造器注入的方式引入 AppConfig 类，问题解决。感谢各位的建议！（ Peace~

@258 @running17 从这个代码的确看不出为什么会有循环依赖，所以可能就是 #11 分析的问题。

通过 `@Resource` field 注入提示的错误：


通过构造函数或者 `@Resource` + `@Lazy` 注入提示的错误：


@cppc #10 demo 代码在 https://pastebin.ubuntu.com/p/bcS3Kkq797/。使用的第三方库是 jasypt-spring-boot 。这个库的作用是读取一个 encryptablePropertyResolver 的 Bean 实例之后，通过判断配置的前缀是否是指定前缀，如果是，根据 EncryptablePropertyResolver#resolvePropertyValue 进行解析。（我感觉是这个依赖的问题，EncryptablePropertyResolver 依赖一个 AppConfig 的 Bean ，但是先要初始化一个 EncryptablePropertyResolver 的 Bean 来判断是否需要对 AppConfig 配置进行解密，因此出现了循环依赖。隐约感觉是这个问题，不知道怎么解决。

@retanoj #6 不行的。这个 AppAutoConfiguration 这个类要作为一个自动装配模块提供给其他系统调用，如果通过 `@Component` 进行标记，其他系统要通过 componentScan 扫描这个类路径，和自动装配的初衷不符。理想情况下是在其他系统通过配置文件，条件化地加载 AppAutoConfiguration 中的各个组件。

@zoharSoul #3 你的意思是将 AppBiz 改成一个 `@Component`，然后通过 `@Autowired` 的方式注入 AppConfig 吗。这个应该行不通，我这边想做的是通过在 AppAutoConfiguration 控制是否加载 AppBiz 。也就是 buildAppBiz 方法上会有 `@Conditional` 条件

@BBCCBB #1 加上 `@Lazy` 才显示具体的循环依赖信息；不加 `@Lazy` 会提示「创建 AppAutoConfiguration Bean 失败，这个 Bean 中依赖的其他 Bean 正在创建，可能有没有解决的循环依赖 」:-(

@tairan2006 这个业务的场景是处理一些历史数据，接口是提供给内部人员调用的。希望尽可能一次性处理比较多的数据，调用者不乐意传分页参数，只希望分页逻辑在后台做掉。

在主键为 id 的情况下，每次查询记录 min(id)，并针对 min(id) 分页只处理部份数据，如 10000 条。SQL 这样写:

```sql
select * from tb_biz where id > (select min(id) from tb_biz where 查询条件) and 查询条件 limit 10000
```

这样的话，就需要多请求几次接口。

感谢各位的回答，总结一下，本质上就两点容易纠结的地方：

@nothingistrue 说的模板，就是在使用定义的方法时，能够让编译器能够推导出具体的类型（ type reference ），`? super A3` 确实无法推导出一个具体的类型，因此我之前的方法定义是无意义的，现实中也不会有这种需求。

@GuuJiang 说的意思应该是：定义通用泛型方法时，需要考虑到 PECS 原则，结合 RednaxelaFX
在知乎上的回答「 PECS 原则背后的原理，通俗来说就是八字箴言：宽于律人，严于律己。」以 Java Stream<T> 接口为例：map(Function<? super T, ? extends R> mapper) 方法里，目标是完成 T-> R 的转换。因为 T 在消费方（ in/consumer ），允许传入所有的 T 以及 T 的父类型的元素，R 在生产方（ out/producer ），允许返回所有 R 以及 R 子类型的元素。