系统架构图先理一下。程序和数据库，即计算和存储合起来，才构成一个业务。你这和数据库分离的业务端是个什么鬼。如果你的业务端，指的就是可横向扩展多节点，并脱离数据库的程序，那就只是个单纯的计算节点，那就别说 inner join 了，它连任何跟数据存储有关的业务都做不了。

我们通常所说的能让程序干的活就不让数据库干，那基本针对的是单个实体（表上的一行记录），而不是针对整个存储（表）。可以针对一两个甚至上万个记录，让程序分批查询出来之后再内部做 join ，这本质上是计算而非存储。但要针对动辄百万记录的整个存储，让程序做 join ，那是不行的。后者要交给专门的存储处理去做，如果关系数据库不行，KV 数据库、内存数据库、Nosql 数据库，或者更好更贵的关系数据库能顶上去，普通程序肯定顶不上去。

小众浏览器只能是好，不能是最好，它要么发展不到大众，要么在发展到大众的过程中就要变坏。Opera 系列一路走来都脱不了这个宿命。最适合的替代浏览器，永远还是 Firefox ，不是因为它好，而是因为它能托底，IE 能倒，Chrome 能倒，但直到浏览器终结之前，Netscape - Firefox 体系都是可用的浏览器。

只要不是白名单，就算是真实名制的情况下，骚扰电话也没法解决，这是黑名单模式的天然缺陷。此外，骚扰电话是运营商的主要收入来源，10016 更是运营商自身的，银行的电话又是必须白名单的，所以就算黑名单模式没缺陷，这些你也必须听。

自己弄个客户端的黑名单吧，不要靠运营商。如果没有社交需求，直接通讯录白名单模式更友好。

微服务下，商品信息挂了就是商品信息挂了，支付挂了就是支付挂了。非微服务下，哪里挂了都是商城挂了。当你的目标是解决问题——首先找出那里出了问题（进而解决问题），而不是没有问题——首先保证不出问题（为此将锅甩给全员，甚至掩盖问题），的时候，微服务就是有意义的。反之自然无意义。

技术不是脱离于生活的，微服务、敏捷开发、Scrum 、看板、Issue 方式的任务 /缺陷跟踪方式，等等老外传过来的东西，你得结合老外的办事风格，才更容易理解。一个比较经典的就是 ISO9001 质量体系当中的 BUG 数量，你如果不知道老外更看重发现和解决 BUG 的能力，而不是零 BUG 的能力，就很难理解老外为啥会把 BUG 数量当作质量体系的正向指标。

OLED 成本比 LCD 高，非高端机器上，这个高出来的成本还提供不了溢价，厂商是脑袋被驴踢了才会爱用 OLED 。能说出来厂商爱用 OLED 的，往往是特定领域的博主，真没想到能在普通论坛听到这话。

并不是各种 Pay 要锁区，而是 Pay 绑定的银行卡、公交卡锁区。你要用国内公交卡，就只能是国内手机国内官方 ROM 的 Pay （如果不是那就是误操作，发现就会被修复）。Google 不在大陆运营，Google Pay 你能装上应用，但大概率是只能装个白应用，啥卡都绑定不了。

U3 或者 V30 的标准就是写入 30M/s 。这个 30M/s 是速度等级，不是最小，通常来说，都是实验室能达到，日常使用达不到。U3/V30 的下一级是 U1/V10 ，所以日常 20Mb/s ，是正好在 U3/V30 的范围内。

SD 卡的读写标准，是双向读写速度标准，但通常 SD 读速度都大于写速度，也可以简单的认为是写入速度标准。所以你读速度 20M/s 也在标准范围内。

至于商家通常额外提到的 90+ 或者 100+的读速度，这个都会说是最大读速度，仅供参考。不在 SD 卡标准范围内，且说成最大也不算虚假宣传。三星这个还算好的，点名了是顺序读取速度最大 130 。顺序读取，是实验室场景，要专业软件才能操作出来，日常使用都是随机读取，速度要降低一大截的。

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 ，无一例外都是有些地方没有判断，导致查了一张表的所有数据”：低级错误还能犯，这特么能算技术中上？这要么是长时间原地踏步的初级工程师，要么就是破罐子破摔的老油条，看后面的描述，差不多是前者。