这个已经过时了，除非你是在改当前项目，不建议再去深究了。

现在，不管是 Hibernate 还是 Mybatis plus ，不管是 DDD 还是非 DDD ，Entity 都是一个特殊的对象类型，这个很好区分，他是跟数据库的表映射或者绑定的（如果是 DDD ，它还有行为方法）。

DTO 在是一个重对象，它还会一直用下去，但是很少会使用。它的区分也很简单，它是一个重对象，自带数据转换逻辑，并且通常跟工厂一起使用。只有 Getter/Setter 的轻对象，不会是 DTO 的，国内有些人把上下层之间传输的参数一律叫做 DTO ，这是很大的误区。

然后剩下的，VO 、PO 、DO 什么的，它们原本的定义是跟层绑定的，一个层使用一种 O ，禁止跨层使用（层与层要额外通过 DTO 来隔离，比如 VO 经 DTO 转换成 DO ）或者只允许上层使用下层的。这些已经死翘翘了。前面已经说了，DTO 很重，没有人会采用“禁止跨层使用”的方式，都是采用“只允许上层使用下层”方式。然后，既然允许上层调用下层了，那为什么不直接调用 Entity 呢，所以最后全部都用 Entity 了。

简单来说，除了 Entity 、DTO ，剩下的本质上都是 Data ，为了层解耦才定义了那么多 O 。随着垂直分层模式的崩溃，这些 O 也崩溃了。

至于楼主的其他问题。2 ，如果你要负责任的话，那就必须手动转换，再痛苦也要转，业务太多变了，这玩意工具的作用很有限，当然有缓解的手段，对于一些纯内部使用的类，你可以考虑 lombok 的 chain 或 fluent 模式。3 ，是，专项专用，但是你可以通过合理规划查询 SQL ，使得多个 SQL 公用一个参数类。4.如果你要负责任的话，那必须给 Swagger ，或者说 Web 这一层，定义专门的数据对象（ Swagger 叫做 model ，内部可定义为 value object VO ，也可以就叫做 Data ）。

能跑 HTTP 负载均衡的网关，通常经过配置后就能支持长连接的负载均衡，至少 ngnix 和 caddy 是可以的，负载均衡这里不是问题。但是你这个想要的不是负责均衡而是 AB 升级，这对于长连接来说，光靠服务器就不行了。

简单来说，你可以设计个重新连接协议：服务器下发切换服务器指令，指令里面带上新服务的 IP ，客户端收到这个指令后，断开当前连接去连接那个新 IP 。更新的时候：首先开启 B 服务器，同时 A 服务阻止新的连接；然后 A 服务器给所有当前连接下发切换服务器指令；当 A 服务器的所有连接都断开，或者超过指定时间后，A 服务器搞停、更、启这一套；之后你想切回 A 服务器就重走上面的流程，不想切就结束了（因为 B 服务器应该已经更新过了）。

不建议客户端在感知到连接断开后自动重新启动。除非你能保证常规客户端连接成功（连接加注册加鉴权等）的几率接近 100%，否则当连接失败的客户端多了之后，会形同与向服务器发动拒绝服务攻击。

一、Socks5 绝对能够隐藏源 IP 。
二、源 IP 屁用没有，你是否隐藏都没区别。

这个 clientIP ，是最后路由的 IP ，不止过 Socks5 会变，过个路由器就会变，很古早以前还会有人用它来防止同 IP 多用户，因为容易被篡改，以及最主要的，误杀（杀整个网吧、教育网能杀一个学校、长宽这种二级运营商能杀一个省），稍微有点技术的网站都不会再用它了。

只能能连上，端对端加密是很好实现的，公钥加密私钥解密即可，“连接上”这个阶段，技术上也是没难度的，但是监管上的难度比上天都难。

没有 DBA 工作只是测试程序的时候用的话，可以用 heidisql 代替 Navicat 。DBA 的话，还是老老实实 Navicat 吧。

git 操作早就是时断时续了，这玩意 Git 内置的代理和令牌还没法同时用，烦的很。SSH 协议比 HTTPS 协议更好识别，没可能 HTTPS 不能用的时候 SSH 协议能用。

reset --hard 的意图就是丢弃当前工作回到以前的某个状态，所以在执行之前一定要确认还没提交 /stash 的内容，确实是要丢弃的，如果不是那就先 stash 或提交。

上面说得被吊销不对，没法吊销，而是其他所有域名服务器全部不信任国内那个服务器了。如果美国要是在原始中央镜像服务器上投毒，那么也能这样被隔离，谁都没特权（军队开过去搞物理特权，那就另说了）。

别说单休，就是大小周，碰上法定假期调休都是累。从你入职接受非双休那一刻，你就跟法定假期有仇了。

@whileFalse #49 不止跟证书以前有，顶级域名镜像（全球就十来个点）也是有的，后来因为 DNS 投毒一不小心从国内变成国籍，被吊销了。域名、证书这些传统互联网领域，并不是中心化的，美国作为中心领导者可以影响，但要制裁是不可能的（或者说制裁还没完成，下面就切线把美国隔离了）。

线程阻塞状态，与同步任务的阻塞性，是两个概念。二者在某些情况下是相似的，但更可能是对立的。无线循环，是自己主动阻塞并让出资源，以便于整体上的不阻塞。

再详细点我不想说，反正楼主也不是来问问题的。

至今（我）遇见过不兼容 Firfox 的网站，还是个位数。现在前端搞框架，框架要么直接遵守 ES 标准要么通过 TypeScript/HTML5+间接遵守，常规 Web 应用想弄个不兼容 Firefox 的挺难。当然，总有沙雕会想用浏览器当客户端，这样就会用到一些非通用标准，这方面正好跟已经事实垄断的 Chrome ，狗碰上屎。

git 修改同一个文件，不一定总是冲突，但大概率冲突，这要看 git 能否自动将两个人的修改合并成一个。所以尽量避免修改同一个文件。

如果不能避免，那也不是啥大问题。pull 之后用新提交解决冲突，或者先 rebase 解决冲突再 push ，都可以，但是以上的前提是：**********先提交*********。

pull 失败跟冲突是两码事，本地工作空间没内容时，pull 只会产生冲突不会失败。本地工作空间有内容，并且预期还会产生冲突（实际上是 Git 无法自动解决冲突），才会 pull 失败。

使用 Git 时切记，先提交后 pull （如果暂时还不想提交就 stash ），不要像 SVN 那样先更新后提交。如果是想获取线性提交历史，那么使用 pull --rebase 即可，但本地还是要先提交。

@qiany 说个简单的场景，就用户名、密码、JWT 、自动登录这几个元素。
1.1 、第一次登录，客户端发送用户名、密码；
1.2 、服务器根据存储的用户名，密码做比对来验证（密码是散列码或者密文保存，这个不在这里讨论）；
1.3 、验证通过后，服务器生成 JWT 令牌，返回给客户端；
1.4 、客户端保存这个 JWT 令牌；

到此，登录认证阶段结束。

2.1 、所有必须需要先登录的接口，在请求时都要带上这个 JWT 令牌；
2.2 、服务器尝试解码这个 JWT 令牌，如果能解码，就算认证通过，否则返回认证失败；
2.3 、（可选的授权认证，这玩意后台管理系统用得多，普通系统一般不用） JWT 令牌通常都会包含用户主键，服务器那这个主键，去查找这个用户的授权，跟当前的操作需要的授权，做对比，验证当前用户是否允许这个操作；

到此，后续认证及授权阶段结束。因为除了登录、注册以及其他不需要登录就能访问的接口，都要做后续认证，这样自动登录就没必要做了，或者说上面的后续认证，就是自动登录。

上面的过程中，生成和解析 JWT 令牌，需要一个密钥，这个要服务器保存下来。通常（不是超高安全级别要求），整个系统就使用一个密钥，这个密钥直接放配置文件就行，不需要放数据库。服务器不会保存 JWT 令牌，这个客户端自己保存就够了。用户名密码这种验证是一种验证方式，令牌使用的是另外的验证方式，不一样（具体的我也不太清除，有兴趣的话你可以再查查）。


至于额外的控制，还拿上面的场景说。令牌是明文的，如果只是上面的处理，攻击者只要能够截取到这个令牌（或者攻击客户端读取到这个令牌），它就可以用这个令牌模仿对应用户的访问。所以当认证要求高的时候，就不能只认令牌，需要其他信息来辅助认证。对于敏感操作，应当直接不认这个令牌，要让用户重新登录，然后回到传统的 Session 认证。普通访问，也可以检测当前客户端的 IP 所在地，如果不在用户经常登录所在地（这个信息要保存到缓存）当中，就也不认这个令牌，让客户端重新登录。如果客户端是手机 APP ，还可以在令牌中保存 APP 的唯一识别信息，然后每次认证时都对比令牌中的唯一识别信息跟实际的信息是否相符来做辅助认证（不过这个只防君子不防小人，因为能伪造令牌就能伪造唯一识别信息）。

你把登录认证跟后续认证当成一会事看才会产生那么多问题，但这俩有区别。在技术上它俩确实是一回事，都是做身份认证的，但是使用场景上不一样。

登录认证，是用于用户 /客户端接入系统的第一道认证，它面向的是完全未知的用户 /客户端，所以要做高级别的校验——用户名+密码、两部认证、动态令牌，直到最高级别的物理令牌。

静态令牌认证，即你现在说的这种令牌，这是后续认证。后续认证是不能单独存在的，它必然要依附于登录认证，所以它可以做低级别的验证——比如只要有用户 ID 就放行。因为验证级别很低，服务器甚至都不用保存它，单靠实时算法就可以验证它的真假。（静态令牌认证里面可能会带昵称、日期等杂七杂八的信息，这些是为了使用方便，不是做认证用的）

比如说卧铺检票，只有上车的时候才会检查车票，这时候它会收走你的车票把它换成卧铺专票——随便打印一下没啥防伪措施的票，后面就只查这个专票，不查车票了。

有了上面的区别就好解释了，静态令牌因为是后续认证，它只需要一个用户主键就能完整验证，不需要密码等敏感信息，也不需要存储。同时，你不能完全相信静态令牌，不管是短期还是长期的，你都要在服务器端做额外的控制。

你的方法一，不存在。那就是用户名密码，token 是画蛇添足。你应该再看看 JWT 的用法，JWT 场景下服务器是不存令牌的，它只配置一个全局使用的密钥。JWT 的安全级别也不高，就相当于一个不能伪造的用户主键，当然这是为了自动登录方便的后续认证，这样用没问题。JWT 有不少安全问题，但那本来就不是 JWT 该解决的问题。

你的方法二，它怎么存储的并不重要，因为这个 token 跟 JWT 一样，就是代表用户主键，服务器从这个 TOKEN 解析出来用户主键之后，再拿用户主键去做后面的授权认证（这里你把认证跟授权也搞成一回事了，这也是两码事）。至于安全性吗，你这里举例得场景是 git push ，这玩意真得没啥安全要求，PR/MR 外加保护主分支，普通分支阿猫阿狗随便 push 都没事，哪怕 push -force 覆盖了以前的内容，git 的分布式外加 Github 的备份措施，也能给恢复过来。说直白点，Github 的用户令牌丢了，最多就是丢脸，没啥卵影响。

开源还是私有，有 devops 还是没有 devops ，有运维还是没有运维，这些会影响你的选择。

下面是我的经验，具体还要靠你们的运维或 devops 管理去做评估。

开源的话，至少要 Github ，最好是以 Github 为主，码云为镜像。
私有的话，如果只是仓库、Issue 库、Wiki 库，没有 devops ，那么首选自建（你们人少，Gitea/Gogs 就足够，人多就要上 Gitlab 了）。
如果是私有并且还要 Devops ，钱多就上 Github 企业版、Gitlab 企业版，或者微软那个开发平台（个人想法，建议 Gitlab 企业版，Github 有些规则，比如没有变基合并 /准线性历史，很反人类），钱少但是有运维的话开源让运维搞 Gitea+Jenkins （这个懂 Docker 就能搞）

@lmshl 你把响应式处理 /流式处理，跟 NIO 搞混了吧。