@GeekGao

不好意思，我理解错了，你的意思是说，完全自己实现的交换模式，ecdsa 传输的所有信息都泄露，用户可以完全拿到包括签名结果，要签名的内容之类的东西是吧。就你的情况而言，确实。

我理解的是，就 tls1.3 而言，本身的报文加密，攻击者不会拿到明文的通信内容，所以不可能泄露。

命题本身就不是很清楚，你要做的是分布式环境下的保密还是认证？
如果只是加密分布式的环境用 secure scuttbutt 啥的协议通信。就可以了

现代通信网络，做认证必然引入第三方。
本地的安全存储看你的需要的程度，可以拆分为内存可信，系统可信，等级别。这个不说清楚细节没法给回复的，即使是使用 kms 也有认证的问题。当时做协议和 kms 的时候都有非常实际的问题

而且怎么回复里面还有胡说八道的？恢复私钥？？

因为注意力本身是一种宝贵的资源，任何行为（包括提问，电报群的消息）啥的都是对注意力的消费，更别提很多提问都是非常没意义的提问，这种浪费精力的事情自然会令人不爽。
如果你希望对这种初级 comment 不理会，要么就从源头剔除，直接不看。要么就是建立分级机制。

怎么说呢，你可以试试在一家中等规模，我是说 300->1000 人的公司，做基础架构 CICD 研发，同时兼任 Oncall 。你就会发现这种浪费精力的事情真的是非常的烦人，无论建立怎样的制度，都无法彻底避免

这里面忘了说一点了，新用户就直接手机号或者微信号登陆？让用户重新注册手机号或者微信号的代价比较麻烦即可。彻底的防备很难

禁止支付太靠后了，放在前面，订单确定用户直接干掉

中间人不能获取服务器的返回数据吧？

@danhahaha 程序员是应该接受 BUG 的存在，而不是说 BUG 是合理的。所以出了 BUG 不丢人，而是出了 BUG 不知道复盘和改进很丢人。

@mercury233
热知识，大量低级 bug 的产生的原因因为程序员自己本身 UT 或者 Integration Test 不足，没发现最终提交到了线上。只有少量的 BUG 是设计缺陷，或者未考虑量级引起的。
作为曾经一个研发体系的末端集成和检测的主 O ，发现过大量的弱智问题。。。
正常的程序员（懂得复盘），基本都会问问自己为啥出现这个问题，但是依然有大量的程序员做不到这一点，工程素养不是每个人都有的。

@freelancher devops 没有什么入门不入门的，抛开实际代码和环境根本谈不了 devops ，网上搜索下一些 ci/cd 的软件和 context 看看哪些能用，怎么落地就成
国内一堆写的书都是废话，都是那种放屁的结论。方向确实很重要，但国内一堆书都是广写理论，不来干货，看看 google sre 的思想就差不多了

知易行难，还是得结合实践？

我建议重点看
要素，连接，功能

挺好

我感觉你说的需求和回调或者轮训没直接关系，问题是抢锁，你们关注的是怎么触发。
这种应该是任务提交，服务端控制并发一个，任务结束了通知到前面继续吧。

@Reficul
你们用的是 remote cache 还是 buildfarm 那一套？如果需要频繁的 integration test ，很多 bazel 的 layer 不用缓存的？
我追求效率没使用 gateway cache ，用的还是 buildfarm 本地存储之类

@Reficul @aljun
bazel rules docker 的好处是确定性。但是目前 bazel 对内存的消耗和时间效率啥的还是不如 docker 好。。。。此外要有效处理缓存机制，避免 bazel 层面 cache layer 。

这种如果不是整体做 bazel 的平台相关的话还是不推荐用

如果整体用 bazel 体系做的话会比较爽

额。。。。这种研究的唯一意义可能只是满足好奇心，因为从虚拟机到物理机变化的东西太多了。。。IO 层面，上下文层面都不一样。。。

安全渗透是只招有经验的是吧，在考虑加点到 devsecops 上是不是加错了。

现在这个环境，写啥都白扯，这两年做工程，逐渐发现了水货多的一批，你写的很深入他不懂。然后除了八股文之外，很多基本的工程素养都没有。。。。所以还是多背诵八股文吧

这种会不会有人投了，最后发现是自己家的尴尬情况