一、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 搞混了吧。

@liuhan907 @lmshl 异步跟单线程不冲突，用线程池处理异步是 Java 的专用方式，其他语言处理异步不是用的线程池。

@lmshl 客户端应用读取一个文件准备编辑，说直白点就是记事本，这你也要用 NIO 去读取文件吗。虽然 Java 桌面应用很拉跨，但你也不能假定 Java 就只是搞 Web 服务器或者大型计算的，有些场景就是简简单单的线性同步处理，这时候你用 NIO 那就是杀鸡用牛刀。

@jeesk 同步异步这里我草率了，NIO 是确实是同步非阻塞的。NIO 跟 BIO 区别的是任务切换的效率，跟同步异步没多大关系，BIO 也能做异步。他俩用哪个，主要还得看并发。