重学 HashTable

HashTable，又称散列表，一说到这个，可能很多人第一反应就是时间复杂度 O(1)！那是不是时间复杂度永远都是 O(1) 呢？别人说所得 hash 碰撞又是什么呢？
其实 HashTable 还是有很多细节的，这片文章就带大家梳理一下 HashTable 的细节，最后一起拜读一下 v8 和 redis 的 HashTable 相关源码。

0. 背景

之前在这篇文章里说过做了个 SSR 《论如何像素级直出具有 14W 行代码量的前端页面》，本以为今天顺顺利利，高高兴兴。

没想到项目放到线上后，随着请求量的增多，却感觉到首屏速度越来越慢，并且是在持续性地变慢。而且在发布完后（也就是容器重建了），耗时又陡然降下来了。

0. 前言

腾讯文档列表页在不久前经历了一次完全重构后，首屏速度其实已经是不错。但是我们仍然可以引入 SSR 来进一步加快速度。这篇文章就是用来记录和整理我最近实现 SSR 遇到的一些问题和思考。虽然其中有一些基础设施可能和腾讯或文档强相关，但是作为一篇涉及 Node、React 组件、性能、网络、docker 镜像 、云上部署、灰度和发布等内容的文章，仍然可以小小地作为参考或者相似需求的 Checklist。

编译的速度与激情：从 10mins 到 1s

导语：对于大型前端项目而言，构建的稳定性和易用性至关重要，腾讯文档在迭代过程中，复杂的项目结构和编译带来的问题日益增多，极大的增加了新人上手与日常搬砖的开销。恰逢 Webpack5 上线，不如来一次彻底的魔改～

在 《XSS 终结者-CSP 理论与实践》 中，讲述了 CSP 基础语法组成与使用方式。通过一步步的方案制定，最终我们利用 CSP 提供的域名白名单机制，有效地将异常的外联脚本拦在门外。然而在线上环境千千万万，虽然我们限制了外联脚本，但却仍被内联脚本钻了空子。

前言

前段时间看了下开源组件 stryker 的源码，对 Typescript 的解析器产生了兴趣。这个开源组件是用来检查单测质量的，通过识别源码自动更改某些代码内容，然后看单测能否检测出来。Typescript 解析器做的，就是识别源码这一关键步骤。

于是花了些时间学了下 Typescript 解析器，感觉像打开一个新的大门，可以玩很多有趣的事情。

附：stryke (https://github.com/stryker-mutator/stryker/tree/master)

最基础，生成 AST

翻了下 Stryker 的源码，发现应用 Typescript 解析器的关键语句如下：

Web Worker 文献综述

Web Worker 作为浏览器多线程技术, 在页面内容不断丰富, 功能日趋复杂的当下, 成为缓解页面卡顿, 提升应用性能的可选方案.

但她的容颜, 隐藏在边缘试探的科普文章和不知深浅的兼容性背后; 对 JS 单线程面试题倒背如流的前端工程师, 对多线程开发有着天然的陌生感.

导语

最近团队进行了一些线程的讨论，这里抽空水了一篇关于线程的文章，希望给没接触过线程相关知识的同学入个门。

线程是什么

进程

既然要说线程，那就不得不提它的两个好兄弟，进程、协程。
进程大家应该是最了解的，平时用的 ps 命令就是查看计算机中的进程情况，进程的特点：

Web Worker 介绍

众所周知，JavaScript 这门语言的一大特点就是单线程，即同一时间只能同步处理一件事情，这也是这门语言衍生出的 nodeJS 被各后端大佬诟病的很重要的一点。

脚本错误量极致优化-定位压缩且无 SourceMap 文件的脚本错误

”JS 代码压缩后，定位具体出错代码困难！“ 的问题，我们可以通过 SourceMap 快速定位，处理得到源文件的具体错误信息。具体方式可以查看 《脚本错误量极致优化-让脚本错误一目了然》

然而当项目外链第三方资源或公共库时，这种压缩且无提供 SourceMap 的文件出现异常，又该如何更好的定位错误位置呢？