这事我也很纠结，正常来说，从代码的可读性来说，放到循环体内生命更合适，但是很多人又说处于性能考虑应该放到循环体外。
我一般考虑可读性。 但是也是希望能得到一个更明确点的答案。
至于内存泄漏问题，在 java 里是不存在的，搞 C 的才有这个问题。

@guyeu #13 感谢纠正，嗯，这里说的确实不对，lambda 是语法糖，stream 不是。jdk8 同时引入了 lambda 和 stream 来满足函数式编程的需求

@zppass #38 pagehelper 插件的使用加上了，也加了一个按日期等方式做分表时的动态表名查询的解决方案

@zppass #38 现在案例中用的是 mybatis-plus 所以不需要和这个去分页，
不过我也会加上的，我会加一个手写 sql 的案例，通过 pageheleper 注入分页数据， 以及写一个和 pagehelper 同原理的动态表名工具

map 扁平化这东西我还真写过，我们业务里用到过。

https://github.com/othorizon/spring-best-practices/blob/master/common/src/main/java/top/rizon/springbestpractice/common/utils/MapUtils.java

@967182 #33 版本升级的场景倒是没有遇到过

@Sunyanzi #32
aop 缺少可控性，aop 是针对一个可以模糊匹配的 path 去做拦截的，但是 path 本身是没有意义的，也就是说只有写这个代码的你知道他的业务上的意义。我个人看来，这就是大忌。 如果误伤了咋办，你了解代码你不会误伤，但是不能避免后来人在缺少对代码的足够理解的情况下被误伤了。
而且后续的人维护这类代码还是很头疼的，不敢乱动。
但是拦截器就是针对某个业务场景去拦截，天然意义上就不会出现这种情况。

换言之，拦截器是低耦合的，代码侵入性低。

@chendy #28 因为是预编译的，会生成实现类在`target/generated-sources/annotations`文件夹，所以有时候是需要 clean 一下的

@BoomMan #26 感谢支持哈，我看了下 pr，您提的内容有些重了，这毕竟是个 demo 程序哈，
另外就是参数校验的代码我其实也在整理精简，所以冲突了哈，抱歉哈，嘿嘿😁。
现在已经 push 了，您也可以参考一下，基本都是一样的，但是我加了一个错误信息的国际化处理，也就是`ValidationMessages.properties`配置错误信息。
后面我还会提交一些自己写的参数校验注解，比如枚举校验等

再有就是您提到的 @ConfigurationProperties 在 yml 配置里没有提示的问题，
虽然采用编写 META-INF 可以解决，不过 idea 其实是有提示的，引入了`spring-boot-configuration-processor` 之后在 idea 的设置里 'Annotation Processors' 中勾选为 enable 就可以了，每次 build 的时候会更新提示，这和 lombok 一样都依赖这个 processor 的处理

@m1862897 #20
hutool 确实提供了很多好东西
mapstruct 也有他的优势，mapstruct 工作原理上完全不同，是预编译的方式，虽然缺少了动态执行的灵活性，但也确保了可靠性，而且效率上也是高于反射的。
我用 mapstruct 的原因就是它公开透明、可控。而且也提供了一些可以做复杂映射的配置。
不要因为代码写起来复杂不够简洁就放弃。

当然有些场景下我也会用 beanutils，还是看场景吧，融会贯通嘛

@FanError #11
@Allianzcortex #17

我在项目中一直用的是拦截器，在我整理的这个项目里也写了一个简单的 auth 实现，特点是解耦。
aop 是针对方法的，拦截器则是针对 http 请求的，我们的权限认证都是针对接口请求的。

我们的权限认证服务是单独开发的，采用 sdk 的方式从公司的私有 maven 仓库分发到各个组件的服务，使用方只要把 sdk 中的拦截器注册进来就可以了。
这样代码侵入最低，当然这种方式也有他的适用范围，各个项目的开发都有自己的不同处境，aop 也有它独有的优势。

@palmers #15 感谢支持，Spring 的 IOC 方面的东西 我会好好整理一下哈，
spring boot 用的是 2.1.X，本来想用的 2.2 的，不过考虑到之前项目一直用的 2.1，那时候 Spring cloud 的兼容 2.2 版本的 Hoxton 还没有出，所以还是继续用 2.1 吧

@Sunyanzi #6 java 写代码就是要把事情说清楚，说的有规矩有框子，虽然不够潇洒自由，但对于企业级的项目，可维护性、健壮性才是最重要的，避免技术负债。所以 aop 在可维护性上是低于拦截器的，而且因为 AOP 的手脚太长，容易被错误使用带来无法预期的和难以排查的问题

@Sunyanzi #6 嗯，还有 aop，把这个给忘了，回头补上 aop 的使用，
个人觉得拦截器是专门专事，aop 则就是更粗暴的去解决了问题，有失优雅
我只拿 aop 写过打印方法执行时间的日志，和自定义注解的处理。今天找个时间加上哈

v 站大佬太多，其实怕大家笑话，有些不太敢发帖的，唉～～

我想问下，这种形式集资的资金会不是应该被什么机构监管然后冻结不可作为流动资金使用吗？
如果是这样的话，他们搞预付款又不能拿来用能带来多大利益？

@Raymon111111 #15 有印象了，以前看过这个算法。。。不过现在都忘了

@rizon #14 我猜测是，在我没有授权用户信息给你的 app 的时候你仍然可以用，但是关联不到个人的信息了