这事我也很纠结，正常来说，从代码的可读性来说，放到循环体内生命更合适，但是很多人又说处于性能考虑应该放到循环体外。
我一般考虑可读性。 但是也是希望能得到一个更明确点的答案。
至于内存泄漏问题，在 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 站大佬太多，其实怕大家笑话，有些不太敢发帖的，唉～～