0. 背景

之前在這篇文章里說過做了個 SSR 《論如何像素級直出具有 14W 行代碼量的前端頁面》，本以為今天順順利利，高高興興。

沒想到項目放到線上后，隨著請求量的增多，卻感覺到首屏速度越來越慢，并且是在持續性地變慢。而且在發布完后（也就是容器重建了），耗時又陡然降下來了。

0. 前言

騰訊文檔列表頁在不久前經歷了一次完全重構后，首屏速度其實已經是不錯。但是我們仍然可以引入 SSR 來進一步加快速度。這篇文章就是用來記錄和整理我最近實現 SSR 遇到的一些問題和思考。雖然其中有一些基礎設施可能和騰訊或文檔強相關，但是作為一篇涉及 Node、React 組件、性能、網絡、docker 鏡像 、云上部署、灰度和發布等內容的文章，仍然可以小小地作為參考或者相似需求的 Checklist。

在推行代碼規范的時候，絕大多數情況下都會遭到不小的阻力，一來每個人的代碼習慣不一致，要人輕易改變習慣確實也不是一朝一夕的事情，二來一般都會帶來額外的開發成本和其它困擾。我們不禁在想，推行代碼規范的困難點在哪里，以及如何解決這些痛點，讓各個角色更容易接受呢？

歸納起來，推行規范的過程中，最常聽到的幾點擔憂有：

1. 是否帶來額外的開發成本
2. 規范的執行力度有強制性嗎
3. 已經開發的分支，合入的時候遇到大量沖突誰來解決
4. 存量代碼如何解決
5. 被修復的代碼，后面一看最后修改人全部都是運行 eslint --fix 的那個人怎么辦