不用 ai ，盲猜是色彩通道或者说颜色模式的问题？看看保存时是否可以设置

其实挺好的，以前写代码总感觉束手束脚，现在加了泛型灵活多了

pixi 配合相应的平滑迁移库可以试试，基于 webgl 渲染的

@yhvictor 确实，你说的对，如果提前拷贝了 ssh 公钥，这种情况无法进行中间攻击。但是这又回到了最早的情形-既然都可以通过某种方式将公钥可信的传递到服务器，那么有没有密钥交换都无所谓，端端通信跟 dh 没关系了。这个我是针对 nomagick 的回复说的。

我也是做区块开发的，至于区块链我跟你看法也一样，区块链本身协议无法提供可信保障，现有的区块链其实都存在这个漏洞的，只不过区块链中间人攻击几乎没有什么收益，而且节点多攻击成本也高-有那能力还不如 51 攻击。
公钥加密-解决不可信网络的可信通信(如 https)
私钥加密-解决不可信网络的身份认证(如区块链)

@rekulas 补充一句，其实普通的 ssh 证书登录也是用了 ca 的，只不过 ca 是自己并不被系统信任，所以开始的时候会询问你是否信任。

完全不依赖 ca 呢？也是可以通信的，但是如上仍然是不可信通信

@nomagick ca 并不是信任服务器名单，它只是一个授信机构，也就是初始化的时候可能没有任何证书，唯一的共识就是-所有人都信任 ca ，然后进入通信环节，ca 通过各种认证向客户端办法证书，大家都信任，通信才能继续。

ca+密钥交换，可以实现在不可信网络中的可信通信，这正好是 op 的需求，也是 https 的基础原理
回到你的疑问-ssh 就没 CA ，照这么说没法用了
可以用，但是你的通信时在不可信网络中的不可信通信，通信中的任何一个中间设备都可以对你发起攻击

要说主要的漏洞，可能就是 ca 认证环节了，如果认证不够严格可能会被伪造证书，但鉴于其超低概率和高难度基本可以认为是足够安全的，毕竟我们的互联网就运行在这套理论上而且稳定几十年了

@nomagick 那你仔细想一想，要求你确认的目的是什么？就是为了让你自己负责对方是否可信啊，那么问题来了

如果你没有第三方认证机构，你确认的时候怎么知道对方是否可信呢？如果是假冒的你也无法分别
如果你说你本地存储了一份信任服务器名单，那又有个新问题，信任名单是从哪里来的呢？如果你通过网络传输，那又陷入了中间人攻击的怪圈。如果你是直接提前协商写死的，那么既然都可以提前协商了还用 dh 干什么，直接写死每个服务器通信对应的加密 key 不就完了？所以说光是 dh 是无法解决端端通信的

@nomagick 密钥交换只是其中一个逻辑啊，光有交换算法也没法通信，都说远了最简单的 https 通信就是一个非常安全的端端通信，在不自黑的情况下目前没办法破解

“亦或借助 server 进行转发，server 俨然就是一个中间人的角色，在协商阶段把 A 、B 的密钥全都替换成 server 的。”

这个中间人的定义就不太准确，参考中间人攻击方式，server 要换密钥，那 client 就要信赖 server 才行，既然你都信任 server 了，那就相当于自己 hack 自己了。只要你只认可合法 client 的证书，server 没法攻击

淘宝的体验真的是一言难尽，前段时间购物经常收不到卖家消息，后来才知道因为之前我开过卖家店铺，别人看到我有 2 个头像一个是卖家千牛的一个是买家的，所以能不能收到消息完全是随机，搞得我淘宝购物还必须安个手机千牛，还找不到关闭入口，如果能不用淘宝，那自然尽量远离 🤣

我也有同感，更新倒是一直很频繁，可能还不够稳定

@dzdh wrk 没用过 你可以用 ab 压测下对比下结果里的 Keep-Alive 数量

可能还有个原因，检查下 go 端是不是默认开启了 keep alive

事出反常必有妖，go 开 cache nginx 不开是不是不公平

@dlsflh 那是电位变化吧又不是真的通断，要是机器每秒通断上亿次谁扛得住

@leloext op 怀疑非休眠问题才这样说的，众所周知再简单的电路频繁通断都会极大影响寿命-哪怕一个灯珠电路，如果是电压或其他硬件问题导致的，那按常理肯定会折寿

直觉不一定准确 以前互联网也被认为是泡沫
发现很多 IT 科技都是要经历一波泡沫崩盘，才能过滤掉投机者迎来真正的落地发展，现在元宇宙还没到泡沫的顶点呢
而且就算是泡沫，但是如果能带动多个行业的发展，也不见得是坏事

早就可以了
https://github.com/bianglibeyond/spotMicro-Chinese