HR 的全称，是 Human Resources ，即人力资源（对事）或人力资源管理者（对人）。直白点说，就是人矿管理者。公司与员工之间的桥梁，本就不是 HR ，是工会或者第三方机构。

个人开发环境，你随便搞。但生产环境上，redis 一般都不在本机，而监听范围只能在 127.0.0.1 和 0.0.0.0 之间二选一。

如果你的后台有分布式会话跟踪的需要，已经把 Session 改造成了 sessionId-redis 存储的形式，那么前端把 sessionId 的携带方式改造一下就没有问题。否则，就不要干这种杀鸡用牛刀的事，防 CSRF 很简单，不需要修改通用规范这么大的成本。

单核 U ，512 内存，10G 存储（弄完操作系统就没剩多少了），这玩意就是搞个静态资源服务器都不行。再搭配上不限速 2TB 数据的带宽，这是精准的个人 VPN 服务器。

1 ，过时的注释 /文档，比没有注释 /文档更可怕。2 ，要想注释 /文档不过时，成本非常大。认不清上面这两点的程序员，要么不够老，要么是人来经验不来，要么是假技术实管理（尤其是没编码几年就混上总监的）

这个身份证应该是人行的龟腚，以前不查就不管，现在可能要欢迎领导莅临了，就把以前没上传身份证的给筛出来让去补了。这里面有个上船容易下船难的问题，造成这个问题监管跟微信都有问题。

前 3 个外加防鼠标手，逻辑 MX master 。最后一个需求，不存在，轻、顺手、防鼠标手，这三者最多同时存在两个。

如果能内网隔离或者指定 IP 白名单，那么能不鉴权就不鉴权——在基础设施做要比在上层应用做成本更低。如果是公网上裸奔，那还是老老实实做鉴权。以上是仅限安全控制，不涉及业务上鉴权的时候。如果系统架构设计或者业务上，龟腚就是不同服务之间需要认证授权才能调用，那么也得老老实实做鉴权。

虽然微信这方面没有钉钉抓得紧，但是还是不要搞，因为这玩意被抓一次的后果太严重了。

要论手机号泄露，继承老电信、老网通的运营商说第二，没人敢说第一。

“写的代码出现过好几次 oom ，无一例外都是有些地方没有判断，导致查了一张表的所有数据”：低级错误还能犯，这特么能算技术中上？这要么是长时间原地踏步的初级工程师，要么就是破罐子破摔的老油条，看后面的描述，差不多是前者。

老领导晋升了，补上的新领导，才是三把火。空降的领导，99.9999%的概率都是要整体换血的。把自己当成准备拿裁员补偿走人去应对就行了。

你说得这些缺失都是大企业的缺点，唯一的认知错误这不只是大企业的缺点，是所有企业的特点，小企业更甚。解决方案只有一个，一周最多实际工作 4 天并且闲下来的时间自己还有毅力去搞东西。

不可以，Spring 是要常驻容器的，非常重，不适合放在任何消费级的客户端上。

GFW 不是只运行在出口的守门员机制，而是运行在全国各地内部网关的监军机制。移动蜂窝网络跟宽带网络是不同的网关，即使是同一家运营商。我以往的经验是，移动蜂窝网络卡得比宽带网络更严格。

姓氏太书面化了。日常使用，要么姓名，要么姓、名，很少有姓氏、名的。“输入姓氏”，99%会被当成“输入姓名”。

另外姓氏这个组合词，可能本身就不对。姓、氏合一（或者说上古姓消失）之后，姓、氏两个字是当成同义字单字使用的，譬如：刘姓大族、荥阳郑氏、李氏朝鲜、秦刘氏（秦家的刘姓夫人）

防 API 共享比防账号共享容易多了，因为 API 的用户是第三方合作者，是可以强实名的，发现之后就不用防止，直接法务伺候。不过如何发现被共享就是一门大学问了，要看你们接口是如何开放的。然而这不重要，既然是 x 局派领导，领导再派小兵的任务，忽悠一下就行了。

“严格管控 API 接口共享”，这已经说得很明确了，是防止第三方合作者，把秘钥等认证方式共享出去。二次封装跟转发差不多，都是把你们原本是给第三方合作者（一包方）用的接口，第三方把接口包装了一下当成自己的接口再买给第三方的第三方（二包方甚至更多包方）。二次封装是把 key 套个壳就扔给二包方使用，二包方直接访问你们的接口。转发是 key 不外放，二包方也不能直接访问你们的接口，他们需要先访问一包方，再有一包方代为访问你们的接口。

类比到互联网服务可能更容易理解，就是账号共享。

我是做 java 的，语言不同，不过思想差不多。Task.Factory.StartNew(asycn ...)，这是提交了个异步的任务，那它里面的执行时机就不确定了。你的猜测没错，这外面循环就 2 次，所以超大的概率，是循环结束后 Task 才开始执行。如果你的循环是 100 次的话，那么就有可能外面循环到 50 次的时候，第 30 次提交的 Task 开始执行。

断点调试的时候，之所以你没看出来问题，是因为你打了断点把异步任务给强行变回了同步任务。你打了两个断点，for 循环那里给主任务打了断点，看变量值那一行给 Task 打了断点，这样 Task 的执行时机，被人为控制的跟主任务同步了。

你的期望是，Task 里面的 dsIndex ，应该是 Task 提交时候的 dsIndex ，这样它就不能用主任务的 dsIndex 变量，因为后者是会被主任务更改值的。解决方法很简单，Task 里面不要直接使用 dsIndex 变量。final int dsIndexFinal = dsIndex ，Task 里面使用 dsIndexFinal 代替 dsIndex 即可。

@Goooooos java final 并不能避免这种 bug 。你可以试试这段代码：
final AtomicInteger a = new AtomicInteger(1);
executorService.submit(()->{
Thread.sleep(5000);
System.out.println(a.get());
});
System.out.println(a.addAndGet(10));

像楼主这样的问题确实能避免，不过那是因为像 int dsIndex 这样的基本类型变量，压根就不能直接传递给匿名内部类，然后 IDE 会提醒你把它赋值给一个新的 final Integer 或 final AtomicInteger 变量后再传给匿名内部类去使用。