@HappyFox 我觉得这是最合理的，但是不够健壮，如果是较靠前的业务接口出问题了，后续接口都没法玩了

老月经贴了，继承->接口实现->容器->注解，当你能清晰弄清楚它们的依赖程度并能在项目中选择合适的时候你就不会有困惑了。当然这是对于需要精细打磨的项目而言，而大多数的项目本身就是对业务，本身就是一种快消品罢了

因为现实中流量是极其不均匀的，消息队列不是为了技术出现的，是为业务出现的

@retanoj 那就纯粹需求描述，现在代码里有很多 BeanUtils.copyproperties （或其他的）属性 copy 操作，但对于这种 copy 点击 idea 中的 field，是无法展示该字段的 usages 的，在查看代码时变量的修改就非常难以追踪，现在我想完成一个插件点击 field 就展示 BeanUtils.copyproperties 的地方，之前的实现思路是按照 java 反射那套思路来的（获取 field 所在 Class，找到该 class 的对象， 当这个对象被 BeanUtils.copyproperties 时，假设是 source，就获取 target 的 class，在那个 class 中按照 field 的 name 和 type 寻找，找到了就说明匹配上了，这个 BeanUtils.copyproperties 就被展现出来）

问题的原因就是你把 DO 和 DTO 变成一个了，这种做法本身是有点问题，但非要这么做也没事，client 包依赖 JPA 然后 JPA 的依赖变成 provided，实际 run 的应用中也有要 JPA 的依赖，两个依赖版本要尽量保持一致

@different 差不多是这样子。。。但是阿里的内网只听说道哥进去过。

这个主要是为了应付安全扫描，避免数据库用户密码明文裸奔，实际上用加密串半分钟就能解出来用户密码，设置这么简单是因为这种场景下加密太复杂反而会影响启动速度，真正保护数据库其实还是靠的网络层内网隔离

一般无非就还是插件, idea 官方能出个功能是最好的，虽然构造器更好但如果没有其他配合还是用 field 注入吧，至少不用在新加服务后还要改构造器

@majiaxin110 呵呵，lombok 你还能和项目管理扯上关系，先把燃尽图、版本管理、commit 规范弄清楚再来说项目管理和团队管理，我名义上手下的人可能比你整个部门都多。关于插件，且不论我是不是升级，一个加进来还需要考虑 ide 兼容性的插件你也敢向向里面加，合着不兼容就让剩下所有人回退版本？

@majiaxin110 呵呵，就是你这种人，我特么因为你用了 lombok 合着我 idea 还要回退到老版本？顺便睁大你的眼睛看看这个 issue 是什么时候的，是说的哪个版本

有一说一，我不针对作者，我觉得他开发这么个东西初衷是好的，结果也差强人意，但我就是要喷那些无脑使用的人，
其他人就要被强奸下插件，一声不吭乱加东西的人见一次喷一下

@majiaxin110 https://github.com/mplushnikov/lombok-intellij-plugin/issues/927
https://github.com/mplushnikov/lombok-intellij-plugin/issues/919
https://github.com/mplushnikov/lombok-intellij-plugin/issues/907
是傻还是怎么的，issues 还要自己找？作者自己都说 Please verify you are using IntelliJ 2020.2.1 version, because 2020.2 version contains a bug and doesn't work well with lombok plugin. 还要不要我给你翻译啊

@mosesyou 这个不吹不黑，最新版是可以追踪的

@majiaxin110
@SSQQ
@wangyanrui ide 可以做的事情强奸用户装插件，呵呵。 而且你们是再用 2019 版的盗版 idea，看看新版 2020.02 提的 issues，真的是不明白是有多蠢才会执着于用这中东西

打包麻烦完全可以不打 fat jar （默认），使用 spring-boot-thin-maven-plugin 把三方包打出去，自己代码打包分分钟

配置文件的话直接 vim 修改, class 的使用 jar 命令先解压再压缩回去

@JasonLaw 默认是 dynamic 的，不要照本宣科

对于 innodb 来说 varchar 会和其他列存在一起, 而 text 存的是指针, 实际数据是在别的地方的，至于独立一张表影响索引效率的说法应该是历史问题，新版本里面是没有必要的，且不独立出去也不会影响索引的效率

前者计算是放在数据库进程，后者计算是放在应用进程，后者会浪费很多内存，前者会对数据库产生威胁，你要保大还是保小？