Aresxue

1.一般是对外的接口层（ http 、rpc 、mq ）是需要一定避免 Map 的，内部方法合理即可不需要一定避免；
2.针对你这个 case 非要搞可以搞个 List<xxxCount>对象，意义聊胜于无，从性能来说 Map 还更好些。

属于滥用拦截器了，这个场景写个 Adapter 就解决了，addToken 方法里面肯定还有 json 序列化和反序列化的开销，Adapter 设计合理点还能把这部分开销优化掉。

你这个就适合 go ，确实不适合 java ，但和 java 也确实没啥关系了

这还告诉我们写代码的不要无脑 copy ，应该要按需引入相应的功能。“若无必要，勿增实体”，做到这一点会少踩很多坑。

@liubsyy 我的意思是你的发布物是什么样的，原先不依赖的新三方库我理解就是导出一个新的 jar 包就叫它 newbiz.jar 好了，把这个 jar 包在容器里面替换掉原有的 biz.jar 然后重启 java 进程就生效了，新依赖三方包的话新的三方包你是会直接打到 newbiz.jar 中还是说是分开的，除了替换原有的 biz.jar 以外还需要再上传一个 third.jar ，值得注意的是这个 third.jar 可能以前已经有低版本的了这里再引入一个会面临业务里面会遇到的钻石依赖问题。

蛮不错的插件，就是编译可以再扩充一些，一个是可以指定电脑本地的其它 jdk ，甚至一些三方的反编译和编译库像 cfr 、Procyon;另一个是我没看到对三方库的处理，指原不在我当前应用中的三方包但我本次修改需要使用的三方库，这块处理也确实会比较麻烦但在这个魔改 jar 的场景里面出现的概率却并不低。

好好坏坏总归是自己的选择，但妈妈要更可怜一些，如果就这一个孩子以后只能一个人孤零零地走向生命的终点。

1.xml 可读性主要是不够简洁，版本管理和子模块管理这俩本来就没有分开的必要，gav 一共就三个维度；
2.使用姿势有问题，把 revision 和 relativePath 玩明白就好了；
3.还是姿势问题；
4.了解下阿里的 amaven 还有开源的 maven daemon ；

@Dongxiaohao 代码不多的话加个注解也是个蛮简单的方式，要是想作为一个可以面向几十个应用的功能就可以像我说的做个二方包在里面写一些路由逻辑，这个东西的好处就是对 sql 语法没有任何要求，需要注意的是潜在的事务问题（跨数据源），你使用时注意点。