emmm，请问你提出这个问题的依据是什么？哪里的统计数据说了 centos 下面很少了？

draw.io 自己部署

不允许同时登录的话，多个设备的用户体验太差，换设备要频繁重新登录，但是当账号被盗的时候，可以及时知道。
允许同时登录的话，账号被盗了自己也不知道，但是方便是当然的了。
如果在一台设备上登录使用的过程中，另一个设备突然上线，可以不被踢下线，而是给出一个提示信息，这样即便是发生了盗号现象也就能及时知道了，并且也不会影响使用体验，不过目前貌似没发现有这样做的……

win 和 mac 都是系统自带
手机我用 鸡脖的

@sneezry 小杠一下举个例外：import xxx from 'https://xxxxx'

编程语言本就是向计算机下达指令，而计算机却不认识“高级编程语言”，所以必须要编译才行。
自然语言灵活多变，就算是现在 AI 已经比较发达了，要准确处理自然语言也是及其困难的，特别是像中文这种极其灵活的语言……
要编写自然语言的编译器，首先就要解析处理自然语言的语法语义，而这带来的成本和收益并不平衡。

而现有的这些“类自然语言”的编程语言，实际上本质上它们的语法也都是固定的，比如上面提到的 wenyan-lang，要定义函数，就必须以固定的格式去写，你要想换一种写法是不行的。

所以，最多只能是以近似自然语言的语法去设计编程语言的语法，但是就算是这样，你在尝试编写代码的时候也会感觉很别扭，因为你平时不会这么说话……

@pmispig 根据 h2 的协议升级方式，只有客户端主动告知服务器客户端支持 h2 的时候，服务端才会采用 h2 与客户端进行通信，否则将自动降级使用 HTTP/1.1。

也就是说，如果客户端使用的是旧版本类库，不支持 h2，那么在请求服务器的时候就不会带有任何 h2 相关信息，服务端也就知道客户端不支持 h2，理应使用 HTTP/1.1 进行响应，以兼容旧设备。
而如果客户端支持 h2，按照标准，在进行 TLS 握手的时候，客户端会主动在 TLS 扩展中自动添加 h2 关键字，告诉服务器这个客户端支持 h2，服务器在响应的时候就可以同意使用 h2 进行响应了。

所以，根据 h2 的协商原理，如果客户端不支持的话，那么对客户端是完全无感知，直接兼容使用 HTTP/1.1 的，除非是做了某些错误的配置（比如在服务端禁用了 HTTP/1.1 ）。

当然，如果你遇到问题的解决方案就是逃避问题的话，那当我没说……

@unicloud HTTP 下不支持 h2 是因为浏览器强制要求的，主流浏览器都拒绝实现 HTTP 协议下的 h2c，只实现了 HTTPS 下的 h2。
所以你用 HTTP 访问的时候就只能是 HTTP/1.1

@puilu 免费证书 let's encrypt 已经普及多久了，几乎所有浏览器都信任……

@pmispig 高版本 HTTP 都是向下兼容的，就算是你部署了 HTTP/3，不支持的用户仍旧可以使用 HTTP/2 或是 HTTP/1.1 （只要你不主动禁用低版本就行）。
不能因为部分用户使用旧库不支持新技术，你就拉着大批使用新设备的用户也体验不到新技术啊……

@weiruanniubi QUIC 是 h3 的试验品，就类似于 SPDY 和 h2 的关系差不多，现在 h3 标准出了，QUIC 之前的实验版本就都过时了

你这个是触发了 fsevents 的重新编译安装，windows 下是需要安装 python 和 visual studio build tools 的，并且你依赖的这个 fsevents 版本有点太低，新版环境（ node、python、vs build tools ）不一定能编译通过……

了解一下数据库的发展史，你就知道了，你这个做法是很久以前没有数据库管理系统的年代的做法了

@qq450255457 是的，你 8 楼的解决方案就是我说的第二种，遵从同源策略，放到同一个域名下。
你 9 楼的问题，加了 OPTIONS 请求时间翻倍，说明 OPTIONS 请求进入了业务逻辑，也就是没有区分 OPTIONS 请求和 GET 请求，导致业务处理了两遍。就是我说的第一种方案，网关层直接拦截 OPTIONS 请求返回跨域许可，这样服务端耗时就几乎为 0 了，只剩下一次请求来回的耗时。（当然，也有可能是其他原因）

@RicardoY 预计是在版本 20H1 也就是 2004 版本中提供，具体推送时间还没正式公布，但是根据版本号和历史春季更新的时间推测也就是 4、5 月份。

WSL 2 功能尚未稳定，还在开发测试中，要到明年的大版本更新了。
跟你是不是专业版没关系……
想提前体验就进预览通道

我一般是找一个当地寄宿式大学的地址

@lihongming emmmmm，我这里不考虑兼容性的做法是直接写最终执行的代码，也就是 ES6 （目前是 ES2019，稍微超前一点的部分 ES2020 也用，比如 BigInt 啥的），而不经过 Webpack babel 之类“编译”，直接用就好……
因为，我这里目标用户基本都是 Chrome Firefox 这些了……所以不需要考虑向下兼容……

直接写最终代码，在调试断点的时候，是真的爽……毕竟代码没有被转换为 ES3 ES5 这些的等效代码，而是浏览器解释器直接内部实现，速度更快，调试的时候非常爽！
babel 转码过之后大部分都是 ES3 ES5 的代码，载入 Source Map 又卡又慢，断点还时不时打不到正确的位置上……

1，网关层拦截所有 OPTIONS 请求，直接返回跨域授权信息，不要让 OPTIONS 请求进到业务代码里。
2，遵从同源策略部署代码，当然这得看实际情况。
3，将请求变为简单请求，不要使用特殊的 header 头，参数完全可以放在 query 参数或是 path 中。