@zhangxh1023 老哥，杭州哪个医院。

用 JSON 的 tree model 试试

Java Security Standard Algorithm Names
中对加密的填充模式只有以下几种:
NoPadding
ISO10126Padding
OAEPPadding, OAEPWith<digest>And<mgf>Padding
PKCS1Padding
PKCS5Padding
SSL3Padding

和业务场景深度绑定。
1. 批量下载文件，比如传个 List 参数。一个线程 for 循环那多慢啊。
2. 批量入库，给你一批数据，不能 batchinsert 的时候，for 循环明显不行啊，多线程走起。
3. 一些后台线程等

年纪轻轻的想这些破事干啥，先找点事情做做，实在没事就看书。

我一个月了还时不时咳嗽

按 IDEA 的来，IDEA 有提示就改，没提示就算。

你这是把阿里的<Java 开发手册>又复制了一份吗.

你应该学点密码学的知识

这就是个坑，快跑吧，这玩意快不起来。

对后端来说:
1. 单节点
可以试试 LRUCache ，key 为 hash （ RequestData ），value 为 systemtime 。
对 LRUCache 指定大小
对 systemtime 进行判断，比如重复提交的最小间隔为 3S 。

业务处理上：
先查数据库，没有就放在 LRUCache 中。
2. 多节点
redis 锁吧。

一样，之前折腾 IDE ，笔记，TODO ，app ，软件等等，后面有一天发现，他们只是在某个很小的需求上有用，有点得不偿失，舍本逐末了。日常使用还是最好以简单为主，遂放弃。

意思你们加了新功能，客户不升级客户端，但还想用新功能？有这好事?

羡慕能升 8.0 的，万年 5.7 。

刚半年就别看 DDD 了，也看不懂，反而能把你绕迷糊。DDD 目前华而不实，没有落地的项目。

他对国内不上心，那我也不上心。
毛子不是啥好鸟，他们的软件不买。

有时需要进行签名，签名与验签需要保持 key 的顺序不变。而某些 JSON 解析框架（对，就是你 Fastjson ）会自动排序你的 key ，导致不一致。整成个字符串好一些，也就这个场景下有点好处。