当初实名认证过程可能有问题，但现在这个处理过程是没 BUG 的，对于已经实名认证过的用户，控制权理所当然是当前用户的，他可以不需要任何附加措施就终止第三方用户的注销过程。

不要太看重人脸，这玩意泄露了会引起很大的问题，但当它用作账户认证的时候，就没屁大作用了。目前它能正常发挥作用的，就两个地方，一个是当作客户端 PIN （ Windows Hello ，Apple Face ID 等），这种是纯客户端认证，登记和认证过程都不与服务器沟通（这里仅认证 PIN ，至于使用 PIN 的服务自己的账户认证，那根人脸识别无关，有服务自行认证）。另一个是当作难以伪造的数字签名，典型的就是支付宝，不管你账户情况是啥，一遇到敏感操作就要人脸留底。至于把人脸当作普通账户登录认证的情况，例如支付宝刷脸支付，这是一种沙雕使用行为，与客户端 PIN 不同的是，这是直接拿人脸当动态密码去做联网认证了，超级不安全。

你大概首先要搞明白利息是哪里出来的。

如果你只是临时用用，这样用 win10 以上自带的 openssh 客户端和 SFTP 命令就足够了。如果经常使用，那么换 Mobaxterm + WinSCP 吧。

xshell 弄了个一年期限的证书，让旧版本到期就不能继续用。这证书是偷偷加的，发现的时候，因为过去了一年，之前没加证书的旧版本已经几乎没人保存了。所以你现在很难能找到还能继续用的 xshell 的旧版本。

听起来像是微信要做一个对比 Microsoft Authenticator 或 Google Authenticator 的东西，但是技术水平不够，做不了既能脱离服务器做 MFA 应用又能连上服务器做同步密钥的东西，就简简单单弄一个云端虚拟 MFA 应用。这样糊弄出来的玩意，当然是没人愿意用得，当然就只能苦一苦内宾了。

Firefox 保底，没有特别定制化需求的话用这一个就够了，但是需要额外至少留一个临时用的 Webkit/Blink 引擎的浏览器来应对一小部分恶意做兼容劣化的网站。

恭喜你又发明了一种汉字表音的分支方法。然并卵。1 、2 、3 、4 跟声调不具备所见即所得的关系，读的时候需要人脑多加一部翻译处理，所以你这个读起来，可能还没 jing_sha jingSha 这种无声调但分割更明显的方式更快。

都是 2021 年 11 约 14 日的文件，你是不是那时候，在公司有文件加密防护的情况下，上传的文件。

印象中，国内云的可用区，是与一个出口网关对照的，即跨可用区的交流只能走公网不能走内网。这样当然不可能后台给你自动迁移了。

Save 之后，实体类的 id 被更新为数据库中实际添加的自增 ID ，这其实是一种维持实体类跟数据库中的记录同步的措施。完整的措施，是要对实体类做会话跟踪的，这样才能保证，最起码当前会话中，实体类对象根数据库表中的记录，是完全同步的。

远程调用，也能做会话跟踪，不过跟踪的设计难度和实施成本，太高了。如果只是要获取数据库实际添加的自增 ID ，相比于跟踪实体类并从 save 后的实体类获取，从 save 方法的返回值获取，更具备可取性。也就是 3 楼的方法。

@Richard14 #37 你这不就是通用规则的数据库顶不住，就自己定制一个专用数据库吗。处理还都只是存储节点 /数据层，没到计算节点 /业务程序上。楼主说得业务端，虽然没给出架构图，但看描述八九不离十是个计算节点，不是一回事。

@ljrdxs #30
@realpg #31
这个是把少部分数据，首先镜像到程序的数据结构（内存）上，然后在程序中再做后期处理。这样做的前提是，每次业务操作，只需加载少量的数据。当你在业务上（重点是业务，不是后台技术）周密的拆分数据结构之后（微服务、DDD 都是干这事的），CRUD 业务上除了查询外都能符合那个前提，查询则有点无解，要靠读写分离、独立查询器等方式来支持后才能搞。

@ljrdxs #30
@realpg #31

系统架构图先理一下。程序和数据库，即计算和存储合起来，才构成一个业务。你这和数据库分离的业务端是个什么鬼。如果你的业务端，指的就是可横向扩展多节点，并脱离数据库的程序，那就只是个单纯的计算节点，那就别说 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 你能装上应用，但大概率是只能装个白应用，啥卡都绑定不了。