如果你真的希望服务器远离用户口令明文，那不得不采用更复杂的方案，比如说采用某种公钥算法，以用户的口令加密私钥，私钥不离开用户的电脑，服务器只用过挑战响应来实现对用户的认证。

首先，口令应使用专用的哈希算法，bcrypt argon 这种，而不是随便 md5 一下，至少也应该按照有关 RFC 的要求迭代+padding+hash 。
考虑 md5 这种简单的 hash 是否潜在地缩小了用户口令的值域。此外如果你无法在前端完成正确的口令哈希过程，该 hash 的泄漏和用户口令泄漏没什么实质性区别。

不需要在什么地方用 Java 什么地方用 Kotlin 制定繁琐的细则，如果你的团队能够把 Kotlin 用好，成员自己一定清楚该怎么做。

Kotlin 现在最大的问题一个是语法和标准库特性不够激进，Java 也在更新迭代，另一个是工具链质量比较差，生成的字节码相对糟糕一点。
不过后者好在有 JVM 的 JIT 加持，除了一些边边角角（比如 vararg 展开）并不会产生多少实际影响。
综合考虑 Java 和 Kotlin 现状，我建议可以将大部分业务代码用 Kotlin 编写，在一些明显用 Kotlin 写起来更繁琐的地方，不要犹豫，直接用 Java 写。
会 Kotlin 的开发者熟悉 Java 几乎是必须的。

随便发起私聊了？

@felixlong apple 这个只是一个很 corner case 的场景，到不好说会不会改回去，也许就让大家吃了。

@Rorysky 如果利用捕获 sigsegv 去做某些事是错误的，那设计这个信号量又是为了什么？如果你说有些事可以做有些事不能做，那就得讲明白哪些事不能做，有什么合理的理由。

@Rorysky
> Null checks are cheap. They usually fold straight into a related memory access instruction, and use the CPU bus logic to catch nulls. (Deoptimization follows, with regenerated code containing an explicit check.)

@Rorysky 信号量怎么就不是一个特性了？这都是写在文档上的，就因为它预期中不常见，所以就不是个特性从而可以随便更改了？既然承诺了它所产生的效果和副作用，怎么就不能用于优化了？实际上因为这个动作的延迟相对较高，JVM 的 JIT 也是用来做非预期分支去优化判定的。
一个东西既然承诺了效果，那就不该去干涉使用者怎么用，除非你有合理的理由，提前注明。

注意下 unexpected 不等于 undefined 也不等于 unspecified

@Rorysky 一大票设施利用这个段错误和总线错误信号来做兜底呢，这要是可以随便改大家程序都不要写了。好在这次水果只是改了一个特例而已。
预期外的行为，它也是良定义的，看看你引用的这句话的下一句。

不过这种破环兼容性的做法真是一言难尽

@codehz 还行，看了下只要他们切换下保护就没事了

> We discovered that if we switch the jit protection mode to EXEC rather than WRITE, then these page faults again raise the expected SIGBUS not a SIGKILL. Note the faulting accesses are predominantly reads and have nothing at all to do with accessing a MAP_JIT memory region.
> We have been working on a patch that switches the jit protection mode to EXEC around these potential faulting memory accesses. It has been a bit of an exercise in whack-a-mole finding them all, and testing is still in progress.

@codehz Go 写的程序可能也受影响，它的空指针访问也是可以在程序内部捕获的，而且好像也是通过段错误信号兜住的（只观察过 Linux/Windows 平台）

@rainbowmolly 触发段错误信号的行为是良定义+可保证的，如果能用来提升性能为啥不能用。你说的直接退出只是因为没有好好处理段错误信号吧。

这有点坑啊，这种重大变更怎么能无预警直接推呢，至少也应该保留一个逃生门。

这个问题要程序自己处理干净，尽量不假设自己一定在根，不然只能采用古老的重写页面内链的办法了（但很遗憾，这在现代复杂 Web 应用场景下不工作）。
现实中很多应用是不支持把自己配置到非根位置的…这就没太好的办法了。

远离 curd ，你看人家用 c cpp rust 写啥，你也写啥。现代 Java 基本都能做到，就是稍微麻烦点

另外如果可行，还是推荐使用现成可靠的地理信息设施，比如 PostGIS ，应该比 MySQL 自己的 GIS 功能强得多