@zhaomeicheng #8 打字打漏了，em 在 font-size 的时候自然是父元素的字体大小

em 当然是根据父元素来的，不然自己 font-size: 2em 不就死循环了

@joetao123 #3 https://docusaurus.io/

如果 Trending 能去除 MD 项目我还比较认可它的价值

我司本来就是自我调侃的说法，贵司也是在比较轻松的氛围里调侃用

最好是猝死，舒服些

代码写得尽善尽美难道不是属于自己的快乐吗

@encro #117 我们可以依靠缓存 7 秒启动一个不包含 node_modules 有 10W 行源码规模的 webpack

@encro Vite 启动快依赖很多前提，我们大规模系统+文件拆得很细（我们有规定 js 不超过 140 行）+因为需要代理接口所以没有 HTTP2 ，就惨不忍睹，带缓存的 webpack 都能比它快

那你这么有志气，觉得甲方太爱装，你就不赚这钱呗，背挺直点

vite 一定不会是趋势

1. dev 和 build 不同，在严肃场合是非常要命的
2. vite 的 build 并不快，与 webpack 没有形成断层
3. vite dev 的初次启动并不快
4. vite/rollup 的插件机制有天生缺陷，例如 virtual module 的 watch 至今没有实现、插件非常难准确选择某一规则的模块，和 webpack 的 loader 相比可用性不够

未来要么是真正的 no bundle ，dev 和 build 都一样，全 esm 化（但 skypack 自己快死了），要么是 rust 化的 webpack 模式，vite 的折中反而很可能拖它的后腿

当然 vite 可以在某一个版本变成上面的某种形态，但这时已经不是现在语境下的 vite 了

1. 你把 new Map 和 map.set 的逻辑放到外面来只初始化一次，每次查找的性能只是 map.get
2. 因为你的测试用例的设计问题，相当于每一次 Map 的测试也包含了一个 str 的遍历，那显然比“只有一次遍历”的 indexOf 慢，明摆着的嘛
3. str.split('')理论上是有特殊优化的，因为 string 本质是 char[]，.split('')只要把 char[]返回回来就行，不用真正的做 split 的逻辑
4. 这个测试慢的应该就是 new Map + map.set VS 优化过的 str.split('')，而不是 map.get VS array.indexOf

完全不等价的 2 个东西怎么比，你倒是拿个测试用例出来，数据量大不大。长度 10 的字符串找一个字段、长度 100 的字符串找一个子串、长度 10000 的字符串找子串，性能天差地别

抽一个 C ，然后 A 和 B 的 Service （不是 Controller ）都注入 C （不要直接 import ，走 NestJS 的 Injectable ），就像你 Service 会用 HttpService 一样搞

金额加逗号显然是渲染的事，你作为前端就算只做交互和渲染，也应该把这事做了

不介意肖战的买石头，介意的买米家

上一代的那个薄是视觉假象，因为它 2 端厚度是不一样的

如果是新机器，那么是正常的

这玩意得坚持。本来 6:30 配速跑 10KM 跟玩一样，结果被上海关了 3 个月，现在 7:30 配速跑 5KM 要死要活的了