@agagega #6
@xgfan #35
知足吧，Win8 刚弄在线账户的时候，他可是按照昵称给你建的用户文件夹，中文昵称的直接用都用不了。所以不论你是否打算使用在线账户，首次启动一定要用本地账户进去——Win11 家庭版首次激活的时候必须开黑魔法，其他版本则必须断网激活。

其实你没必要重装，因为你重启前登录过了，那么重启之后，断网即可用之前的密码登录。微软的网络，是在薛定谔的盒子里面的，有时候能直连，有时候不能。你现在的情况，大概率是 Windows 联网判断那个服务器能连上，但是 Windows 登录那个服务器被临时墙了。

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

如果你只是临时用用，这样用 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 体系都是可用的浏览器。