清水还有救，奶茶的话基本上就是寄了

单纯跑一圈的话不用设导航，死活不下来就行了，内环还挺锻炼开车意识的
但问题是，外环和中环我记得都是有断区的，不能不下来……

那么这 30 年公司会用怎么样的方式压榨你呢？

既然换水不难，那谁要水的时候空了就换，也不难吧，为什么对别人提要求

@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 的字符串找子串，性能天差地别