@TGl2aWQgZGUgZGll #3 以楼主两个链接的对应内容来看，问题是，本地文件系统残留原始内容，修改之后的文件是没有残留的，那就自然不严重。当然看 7 楼贴出英文原文后，问题是修改之后的文件当中，而非本地文件系统残留原始内容，那就是很严重的。这不但表示楼主的两个链接仍然是标题党，还表示特么的是机翻加农场。

标题党，撤了吧。两个问题都是图片修改后原图片还保留着，并不是修改后的图片还携带原始信息。

楼主和楼上都没说到正确信息。

谷歌周二在一份声明中表示，因发现拼多多未上架 Play Store 的外部版本包含恶意软件，为预防起见已将其下架 Play Store ，且 Play Protect 也将拦截其安装。受此影响，拼多多美股盘前跌超 2%。
谷歌在声明中并未提及拼多多的出海平台 Temu ，且该 APP 仍可在 Play Store 中正常下载安装。
https://www.bloomberg.com/news/articles/2023-03-21/google-suspends-pdd-s-main-app-after-finding-malware-in-versions

两个重点：1 ，商店下架的原因是商店内外两个版本，Play Protect 拦截的原因是包含恶意软件，总体上来说，谷歌对拼多多发起了不信任投票。2 ，股价跌了。

@ahhui #8 因为用了 Ctrl + Enter 来换行

我的朋友，通过人脸识别后，申请注销对方帐号；
> 这仅代表你的朋友，实名去申请注销，目前并不属于他的账号。

冒用者，在不通过人脸识别的情况下，可以停止这个注销流程。
> 对于第三方来说，在正式仲裁前，你所谓的冒用者，才是账户所有者，你的朋友是入侵方，这时候自然是账户所有者可以随意的终止入侵。

双方进入了拉锯战，冒用者可以一直停止注销，冒用身份问题无法解决。
> 这个并不会进入拉锯战，当你的朋友无法提供更多能证明账号所有权的证据后，申请几次之后，就会被判定为恶意攻击者，而被禁止再申请注销——那个人脸，就是并且只是用在这里的，压根不是用来证明账号所有权的。

我的朋友，通过人脸识别后，申请注销对方帐号；

冒用者，在不通过人脸识别的情况下，可以停止这个注销流程。

双方进入了拉锯战，冒用者可以一直停止注销，冒用身份问题无法解决。

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

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

当初实名认证过程可能有问题，但现在这个处理过程是没 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 业务上除了查询外都能符合那个前提，查询则有点无解，要靠读写分离、独立查询器等方式来支持后才能搞。