@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 功能强得多

以前流行过 geohash ，如果 MySQL 自己的地理信息功能挑不起来大梁，可以尝试附加一个 geohash

@CorgiDuu 是的，m3u8 和 ts 分片都是普通的文件，按文件分发处理就行，所以它才方便

此外给视频切片是个很重的工作

一般都是切好的，这样也利于缓存

我倒觉得还行，键盘用时间久了，我打字也不用摸 F J 上的凸起

@Nazz 确实，立刻还给了时间上的含有，也不合适…要不，“同步地返回”…得，循环了

@Nazz 同步/异步的区分不是阻塞当前[线协]程与否，而是是否能立刻取回结果

@seven777 不过密码套件确实应该把解耦做好，软件在架构上就应该能兼容数据不同的加解密方式