在 《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 和微信，一個正常的聊天界面是大致上是長這個樣子的：