这个字看上去很怪异的原因是，你的字体 (Ubuntu 默认的是 Noto Sans ) 没有正确的 region 。Ubuntu 默认的字体配置下，Noto Sans Japanese 排名比 Noto Sans SC 高很多(SC 指的是 Simplified Chinese 简体中文)，所以中文优先以日文方式渲染。简体中文汉字，台湾汉字，日文共用了很多 Unicode ，但是细节有很多差别。
[Imgur]( https://imgur.com/v8EosaU)
如果你的字体没有被正确地配置，系统就不知道应该依照哪种语言渲染简体中文汉字对应的 Unicode 。正确的解决办法是修改 Linux 的字体配置 font-config ，将 sans ，sans-serif 默认指向简体中文字体 (我用的是 Source Han Sans SC 思源黑体)。
but, font-config 配置起来并不简单。

照理说 jsonp 这个东西也是不应该存在的，都是历史包袱

等离职了去劳动仲裁就行了，收集好证据，一告一个准。

正常情况下前端应该部署到 cdn

乱黑什么 npm 的依赖管理呢？有 lock 文件，喜欢操作一下排除出版本控制系统，赖 npm 太垃圾还行。

@3dwelcome 那你可能要失望了，大多数后端语言比 JS 糟糕很多。Java 程序员不知道 Java 8 以外的 JDK ，也不知道什么是 async, await, generator ，C++ 程序员不知道什么是依赖，JS 以外的流行编程语言不曾出现过 transpiler 这样的究极元编程。

状态数的增长也会导致你手算最优状态转移的难度暴增。三个状态互相转换你只需要写 3!=6 个 DOM 状态转移函数(K3 完全图)。7 个状态互相转换需要写 7!=5040 个 DOM 状态转移函数(K7 完全图)。

页面上元素少的时候，直接用 DOM 确实有性能优势。比如说写自己博客，直接用 DOM 没什么问题，可以很细粒度的控制状态转移。
页面上有成百上千个元素的时候，你手算最优状态转移是不可能的。所以你直接操作 DOM 完成的不是最优状态转移，但是 vDOM 算出来的是最优状态转移，而 js 计算的开销比 DOM 操作小很多，这时候 vDOM 就有性能优势。

再说个有意思的事，OP 提到的这个回答我找了下原地址

为什么 nio 效率会比 bio 高？ - 锭阳的回答 - 知乎
https://www.zhihu.com/question/59356897/answer/165104063

也就 15 个人点赞，排名也很靠后。并没有很多小白点赞嘛。

[Imgur]( https://imgur.com/sGShzm3)

@makelove 真的很烦，程序员社区不知道为什么也是这个风气，Linux 出问题不查日志，不会定位问题，Windows 出问题不查核心转储，动不动就让你买 Mac ，让你用 winnat 天天出问题的 WSL2

都是程序员了，自己查 syslog 看有无异常吧。

1. 你用 NIO 的时候如果开了 100 个线程，说明要么你的程序是 CPU-bound ，要么是 HTTP 连接处理以外的 IO 全都在用同步网络库（如 JDBC ）。后者属于错误用法了。模范用法见 techempower jooby-pgclient 。
2. 建议搞清楚 tomcat 碰到超过 maxThreads 个阻塞 syscall 怎么处理的
3 不解释了，建议写点 libevent 代码搞清楚什么是异步网络编程

你签字了就没意义了，要存在重大误解才能上法庭

Serverless 的唯一优点是云厂商可以无限塞私货让商业客户无法离开云平台，无法迁移到其他平台。让客户的一切数据、代码对云厂商透明，方便云厂商高效收割。

这说实话是个初中数学问题，
证明不存在单射 f:X↦Y ，其中 X 和 Y 是有限集且 Y 的元素个数小于 X 的元素个数。

楼主应该是还没学会 Vue 的状态管理库吧，不会跨组件控制

可以买分层内胆