无意间想起来翻一翻旧贴，哈哈哈总算看到结局了。

主要就是速度问题，尤其是 release 的下载链接，aws 的 s3 经常性连不上。 其他都不无所谓。

本地化：可有可无， 一般的操作能比 if else for 能多需要记几个单词？ issue 里英语 你有办法汉化吗？

稿费不应该是出版社给作者的钱吗？

游戏里，items 翻译成 道具。

里面有 比如 回复剂、 凤凰之羽、手雷 之类的东西，每种都是一个 item。

空格给删了... 那句应该是 不可逆 写错了

上一句漏了一个字
这东西理论上是 可逆
^
不

@yestodayHadRain http 被中间人的概率不小，基本上就是裸奔状态，整个链路上任何一级想看就看的到。

前端如果是传密码之类的，可以直接用摘要算法，如 sha256 之类的或者更高级的。
这东西理论上是可逆的，知道怎么算的也没法逆运算，
但 md5 和 sha1 现在不推荐了，因为这两个几乎是被人完全暴力算出所有的解了。

像之前那个帖子里也有人提到了 非对称加密， 前端暴露的公钥和加密方法也不怕，因为知道它也只能加密一个伪造信息，而不能解密前端发出去的加密后的信息。

之前有个类似的话题，下面一群人对于前端要不要加密、钥加密的话如何加密都没达成一致意见。

我是后端，我倾向于前端不加密。

https 已经实现了传输的加密。
前端加密是为了防后端开发偷数据吗？那前端也可以 xss 偷用户数据啊，是不是也得想办法防一防？

再来实话实说，中国网站这么多，有几个后台数据加密强度高的? 现在有多少还在用 md5 ？
比起推前端加密还是后端得多升级升级密码安全。
不过如果不是个人项目的话，有能力推前端加密了那想必团队比较大了，后端也应该密码安全程度比较高了吧。

有没有可能是启用了 hyper-v 了?

@whileFalse 所以采用 sha256 或者更高级的摘要算法不就好了。
后端既然能知道盐，那自然也可以找加盐的彩虹表啊。


而且后端向前端发盐值，那这个盐和没加一样。
后端推荐加密 带 盐值，同时也建议不要使用统一盐，为的就是不让别人知道具体的盐值是什么，你盐都发给前端了，那加盐的更没意义。

你不用加盐， 直接用复杂一点的摘要算法(比如 sha256) 后端就还原不出来密码明文了。

前端加盐 存在哪？
cookie ？ 用户换个浏览器得重新找回密码一次？
js 里写死？ 那找到你这个盐值也不难，而且加密用同一个盐值和不加盐差距不大...

之前是专门和本地一致的用 oracle 的，明年估计我个人开始会全部替换到其他版本的 jdk。

@DEEPPANDA 所以只要是辛苦弄得都是对得？

那你们喷之前那几个给 event-stream 加挖矿代码得人干什么？
人家从原作者那接手之后幸幸苦苦维护了一年多，最后加个挖矿代码怎么了?

从逻辑学的角度讲，changelog 里写出来了还能叫做彩蛋么...

不过作为一个给开发者提供的工具，里面加这种东西与其叫菜单不如叫下毒。