@iseki 从认证这个业务逻辑上当然不需要获取原始口令，也不该这么做

@lesismal 按这种讲法就没什么可讨论的了。一切当然是可以改的，就算是碰到必须获取原始口令的设施你也可以说改造旧设施，那还有什么可说的呢。

不是，举个例子 LDAP 登录，这是很常见的需求。业务逻辑是尝试使用搜索到的 DN 和用户提供的口令 Bind ，Bind 成功即为认证成功，这就必须把用户输入的原始口令发送过去。

@lesismal 明文向后端传输虽然不好，但有时这是工程上成本刚好可以接受的方式。一来我刚才说了，很难设计一个有足够收益的非明文传输方案，二来就是有时候后端的某些设施只能接受明文。

@lesismal 工程上多一行代码也是有成本的，不能做不划算的事。我可以接受口令在妥善的哈希后传递给后端，但我不能接受把口令 base64 之后传给后端，base64 在这里就是一个收益近乎为 0 的操作（即使它的成本很低），总结下来就是一句话，不做不必要的事。
避免向后端传递原始口令是有必要的（中间设施，日志系统，甚至后端服务本身都可以有缺陷和风险），但必须弄清该怎么做，而不是简单变换一下弄得一眼看不出来就完了。

@lesismal 这文本复制的可真有意思，也怪我，下次用 Kotlin 风格的方式表达。
这个接口的风格是工程要求，你也可以看一下我在这条文本之后的跟帖，大概有这么个现实问题是不太好解决的，你可以给出你的解决方案讨论一下。

也许可以在前端对口令完成一次困难哈希，但难度和风险在于这个哈希的算法和参数从此固定不能更改，也意味着日后所有的「客户端」都要能自主完成这套逻辑。

此外再提及一点，许多密码基础设施提供的验证接口形如 verify(password, stored_credential) -> ok?，这里虽然没有明说（实际上也不可能要求） password 必须是用户的原始主口令，但一般确实可能影响到实践。

单从避免用户主口令泄露这件事上来说，要做一个可靠的方案成本比较高，前后端可能会有超过一个 RTT 的挑战响应机制。比如后端存储用用户主口令加密过的私钥，然后在用户代理（浏览器）中完成挑战响应，这样可以保证用户主口令不离开用户代理。
如果前端简单哈希一下，暂且不论能否提高安全性（加盐会很难做，固定的盐没有意义），哈希后的结果会不会缩减值空间，反过来降低安全性，可能也有待评估。

命令行用 jq ，其他场景用浏览器开发者工具，本地已有文件用 vscode 。无它，我的 json 很大，不用 jq 会卡；我需要灵活的操作和处理，浏览器 F12 正合适~

话说，你的序列化反序列化 API 不支持按流处理吗？比如说我经常处理大体积的 JSON ，大一点一个对象可能 1G+，数据会在反序列化过程中被处理，比如说可能有去重之类的逻辑。 @dsvshx

arena ，把 payload 弄到堆外面去，手动管理。但是这么一来…protobuf 自己解析想想就很麻烦。
长期来看这只能是个权宜之计，以后不能这么设计 API ，搞出大量大体积的 bytes

为什么公司要划分区域总部，划分这么多级是用来干什么的呢

@keakon
Go 竟然连这么基本的优化都没做😫，循环里面是空的，都不用往别处看就可以知道这个条件绝对不会被破坏啊😐 Go 真是有点···

有辩大经的功夫，不如多去给这位 CEO 做做个人影响力宣传，吃瓜群众看见没用，得让正确的人看见。

这种事公司肯定都是合法的，想不通的不妨自己翻翻签下的劳动合同去，所以这种事不要在法律上为自己找什么出路，法律不向着你你干啥呢。
还是那句话，批判的武器…武器的批判

@poltao 实际就是这样的，什么叫全职义务啊😋，劳动合同本质上就是卖身契啊

其实真要算的话八小时之外的产出搞不好也是公司的（

注意了啊，这家的产品是 api7 ，依托 api6 搞的东西，赶紧排查下自己有没有用吧😋