@MrUser #4 也想过啊，实在没办法就只能这样了。。。

@chendy #2 我擦 终于放开了，春天来了。。。。 那就先按订阅消息的方式做吧，谢谢哈，

但是支付功能 个人账户的化有没有办法实现支付啊？

慢慢来咯，国外主流消费方式不还一直都是刷信用卡嘛。。

这事我也很纠结，正常来说，从代码的可读性来说，放到循环体内生命更合适，但是很多人又说处于性能考虑应该放到循环体外。
我一般考虑可读性。 但是也是希望能得到一个更明确点的答案。
至于内存泄漏问题，在 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，还是看场景吧，融会贯通嘛