在 《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 的文件出现异常，又该如何更好的定位错误位置呢？

先从一个需求说起

之前在做界面组件的时候，有很多地方都用到了边框，我都是顺手就打上了 1px 的宽度。但是 MR 上去以后，组里的大佬问我有没有听说过一个极细边框的技术，我就赶紧去 google 了一下，发现这个概念原来很早就有了。早在 2014 的 WWDC 上面 Ted O’Connor 就讨论过有关 “retina hairlines” 的技术，可以实现比 1px 还细的边框。

在传统的 web 优化中，我们可以采取压缩、拆包、动态加载等方法减少首屏资源大小，也能通过离线包、页面直出等方案加速 html 返回，之前一篇 h5 秒开大全有部分简析。在大部分场景中，这些方案都足够用，也能得到出色的效果。但仍有两种无法尽善尽美的地方：其一是短暂的白屏现象不可避免，其二是对于超大型 web 应用难以做到秒开。结合客户端特性，我们有没有办法，进一步做到极致，打开 web 页面和打开客户端页面无差异的体验呢？

2015 年 HTTP/2 标准发表后，大多数主流浏览器也于当年年底支持该标准。此后，凭借着多路复用、头部压缩、服务器推送等优势，HTTP/2 得到了越来越多开发者的青睐。不知不觉的 HTTP 已经发展到了第三代，鹅厂也紧跟技术潮流，很多项目也在逐渐使用 HTTP/3。本文基于 QQ 兴趣部落接入 HTTP/3 的实践，聊一聊 HTTP/3 的原理以及业务接入的方式。

在最近的开发工作中，遇到了一个聊天场景的应用（Web 和小程序），类似于我们再熟悉不过的 QQ 和微信，一个正常的聊天界面是大致上是长这个样子的：