自主研發一款瀏覽器內核的難度到底有多大？
目前主流瀏覽器的內核：微軟 IE 瀏覽器內核 Trident、谷歌 Chrome 瀏覽器內核 Blink、蘋果 Safari 內核 Webkit 和火狐瀏覽器內核 Gecko 都是國外廠商開發的。
在保證兼容性的情況下，自主研發一款瀏覽器內核的難度到底有多大？
為什麼國內的這些互聯網公司都沒有從較底層開發瀏覽器，而是基於 Chromium 進行二次開發？
來來來， 讓寫過內核的人給你們聊一聊 ^^
其實內核分類啥的，真的沒有那麼複雜。 要了解難度啥的， 看看瀏覽器本身發展的歷史會清楚很多。
瀏覽器的內核從頭開看的話， 其實並沒有那麼多。 Google 的 Blink 來源於 蘋果開源的 Webkit，而蘋果的開源的 Webkit 來源於 KTHML, 屬於 KDE 的一部分, 而 KDE 基於的 QT, 是 Trolltech 開發的， 很多 KHTML 的貢獻者其實是來自於 Trolltech.
因此，Google Chrome 和 Safari 這個分支其實是來自於 Trolltech .
很多人不知道的是， Trolltech 也是一家挪威公司, 而且就在 Opera 的樓下。 他們是四樓， 我們是五樓。 我剛加入 Opera 的時候， 他們還和我們共享食堂。很多員工彼此都是好朋友，連代碼都是部分共享的. 因此 KTHML 和 Opera 的自有引擎 Presto 架構非常類似。
現在你看到了吧， 內核架構其實就三個分支
- KTHML, Opera -&> Webkit -&> Blink (Chome, Opera, Safari)
- Netscape -&> Firefox
- Trident or whatever -&> IE
兩個系列是美國的，一個系列是挪威的。
然後有人就要問， 美國做這些東西很正常， 畢竟 IT 起步早，發展快。為啥挪威這種莫名其妙的國家也做瀏覽器， 還做得風生水起的。。
很大程度上和這個兄弟有關係。這個兄弟叫 Haakon Wium Lie, 也是個挪威人, 發明瞭 CSS. 然後做了 Opera 的 CTO.
H?kon Wium Lie - Wikipedia?en.wikipedia.org
Haakon 在 W3C 的影響力非常大， 畢竟 CSS 之父。 於是帶了一大票挪威人在 W3C 裡面制定標準。 當年我旁邊辦公室裡面隨便拎一個出來，都是 W3C 某個討論組的主席啥的. 然後事情就比較有意思了。 CSS 規範裡面其實非常多的地方定得非常的繞。 如果你去看 Opera 裡面的一些 CSS 實現方法， 你會發現實現的非常優雅。而其他瀏覽器就更像七拼八湊出來的。這讓我非常懷疑，其中這些規範是 Opera 實現好了， 再提出來的 ...
現在看清楚了吧。從歷史原因來說，美國有資本優勢，畢竟互聯網泡沫還在, 而挪威有標準影響力。其他任何一個國家研發瀏覽器在那個時候來說， 都是費力不討好的事情。
從技術上來說，瀏覽器研發的難度更多的像是一個系統工程。瀏覽器的各個組件研發難度其實都不大。
包括很多人認為的 Javascript engine。 其實除非像 V8 那樣子往死裡面優化，單純的 javascript engine 其實相當獨立且並不複雜
Opera 裡面很長一段時間做 javascript engine 就一個人。javascript engine 和瀏覽器之間的耦合非常標準， 所以做 javascript engine 和 瀏覽器其他部分的人幾乎沒有交集。於是這個哥們長達數年時間， 自己跟自己開會，自己跟自己彙報，自己定計劃。 最後離職的理由是和其他部門交流太少，實在是太孤獨。。
做為系統工程，瀏覽器最大的挑戰的是瀏覽器承載的網頁是不確定的，雖然標準還在， 但是扛不住無限種可能。
比如你並不知道在明天在世界某個角落的人會不會發精神病在頁面裡面寫上一萬個 canvas. Opera 當年為了追求小巧， 解析器用的是簡單的遞歸下降。 於是你也不知道是不是有一個精神病會寫上一萬層標籤嵌套搞掛你的棧。
而無限可能帶來的另外一個問題是： 你在解決一個新的可能時。你怎麼知道沒有搞掛另外一個已經解決過的可能呢？
如果是非主流瀏覽器， 解決這問題事情都需要靠暴力的， Opera 因為做得早，積累了非常多的回歸測試。我記得放棄掉 presto 的時候， 大概 14 萬個測試用例， 有一個伺服器集羣每天晚上都跑。 新的提交要是出現了回歸，集羣馬上把報告用郵件自動發給提交者。
如果是主流瀏覽器，那就好辦多了，只需要保證滿足標準就行（比如 chrome)， 或者不要自己砸自己老版本的瀏覽器（比如 IE). 因為網頁反過來， 會來適配你，
於是如果你要研發一個瀏覽器內核，那你肯定是從 「非主流瀏覽器」 瀏覽器開始，要不然你像 Google 一樣，找一個 「主流瀏覽器」 的內核二次開發，然後強行推廣成為一個主流瀏覽器。
要不然就像 Opera 一樣暴力解決。。
而技術本身，相對於系統工程本身，並不是很大問題。從某種意義上面，這和操作系統蠻類似的，不同的僅僅在於，瀏覽器需要適應無限可能的頁面，而操作系統需要適應無限可能的硬體。
而我非常懷疑國內有任何廠商有耐心來做這個事情 。。。
[1] WebKit - Wikipedia
[2]The Qt Company - Wikipedia
瀉藥
第一個，補充點內容
blink 基於 webkit，講道理，兩者大體一致，無非前者把 webkit 中相關類換成 chromium 與 v8 相關的，並在此之上擴充。
trident 太老了，現在是 edge 了，甚至微軟當年還有個 tasman 呢。
這是渲染引擎，還得配上腳本引擎，瀏覽器上用的，現在大致上是 v8、jsc 、spider monkey（各種猴子就是）、chakra 這幾個。
其實腳本引擎實現也不少，比如古老的 rhino，adobe 給 AS 用的 tamarin 什麼的。
之前 Opera 自主研發內核時候，還有 presto 配 futhark carakan 啥的。
可見，這麼多種，絕對不是蠍子拉屎獨一份的，最起碼不是難上天兒的。
但，關鍵就是在你詞兒上 「在保證兼容性的情況下」，為它付出的代價可能就比較大了。
甚至大到不僅現在亂七八糟的不斷變更推進的規範得爛熟，還得歷史情況葉門清兒。
相當於接手了一堆不斷變更的開發需求不說，還得把幾乎在沒文檔、沒源碼的情況下，把祖傳20年功能連帶 Bug (還是叫特性得了)全都開發出來。
著玩意是個巨大門檻啊。
連 Chrome Firefox 當年都沒完全這麼幹，他們是扯著規範的虎皮，幾乎不管 IE 祖傳的那點玩意，把 IE 給弄殘了才起來的。相當於另起爐竈了，等佔有率差不多了，再慢慢的搞兼容 IE 常見的那點祖傳玩意。
反觀當時的 Opera，跟著規範，跟著 IE 的祖傳走，最後是在弄不動了，市場佔有率也不行，終於扛不住切成 chromium 核了。
所以內，第二個問題就看這個好了 國內三大巨頭BAT為何不開發一個瀏覽器內核？
IE/Edge 在源碼層依賴 Word，contentEditable 就是開啟「Word」的編輯模式。感受一下。
主要是費力不討好，
事實上瀏覽器的內核的各個模塊都有開源或者替代項目。
粗略來講，一個瀏覽器內核可以由以下模塊組成：
1、HTML和CSS解析器和DOM
2、排版引擎
3、JavaScript腳本引擎
4、HTTP協議引擎
其中1、3、4的個人開源項目一大把，所以說，給一個團隊足夠的資源做出來不存在難度，當然性能什麼的那就另說了，尤其是現在對JavaScript這門坑語言各種黑科技的優化策略。
排版引擎涉及的坑略多，但非要說，金山就有一個排版引擎，改改也不存在難度。
但是做這個東西的好處則幾乎沒有，如果現在還是2G時代，移動端有帶寬硬限制需要定製瀏覽器，還有UC之類的東西的市場。
更何況，這東西不是做完了就完了的，還要養一個可觀的團隊持續不斷地改進和升級維護。如果不這麼幹，想想IE當年95%的市場份額是怎麼崩潰的？
現在瀏覽器內核只有三家，Trident/Edge，Mozilla/Gecko，WebKit/Blink，原因也很簡單，微軟和蘋果是因為自己做GUI操作系統，排版引擎不在話下，瀏覽器內核作為基礎服務也必須提供。Mozilla/Gecko本來是要死的，谷爹一看不行，哪天軟軟果果聯合起來一腳把我踢出Web標準委員會（W3C/WHATWG之類的組織），我特麼一個做互聯網內容的還不被他們倆玩死？就像後IE時代這些年前端被瀏覽器大佬們玩的欲仙欲死一樣。所以硬是搞成了現在的三足鼎立，當然谷爹後來親自下山擼袖子，那已經是後話了。
沒人邀請毛遂自薦。
參與過一款大家可能不太知道但是很多人實際用過的嵌入式瀏覽器開發。說很多人用過，因為psp、psv、ps3以及老任的ds、switch的瀏覽器就是這款。（還包括日本大多數非智能手機）
https://en.m.wikipedia.org/wiki/NetFront
瀏覽器內核的主要構成部件包括文本語法解析器，layout引擎和腳本執行器。當然下面還有網路協議棧。
文本語法解析器主要負責HTML/CSS文法的解析；
layout引擎負責排版和渲染；
腳本執行器則負責網頁當中的動態內容，比如javascript的解析執行。
編寫一個瀏覽器引擎，首先需要的是良好的RFC閱讀能力，也就是各種標準的閱讀能力。
接下來，是將這些標準轉化成實際代碼的能力。
這部分要說有多難，其實我覺得準確地說是有多煩（繁）。如果你是一個編程基礎紮實的人，並且有恆心有毅力，將這幾十篇每篇幾百上千頁的標準文檔巨細無遺地翻譯成代碼，那麼至少一個working的瀏覽器內核就出來了。
接下來，如同一些其它回答提到的，就是兼容性問題。為什麼按照標準寫的瀏覽器會有兼容性問題？這個在歷史上很操蛋，因為微軟又是置標準而不顧利用自己的市場佔有率強推非標準瀏覽器（如IE6），致使互聯網上相當一部分內容其實都是非W3C標準（而其實是微軟標準，當然，其實微軟也沒有標準，IE各個版本之間也有很多兼容問題）的。其它瀏覽器不得不模擬IE6的各種非標行為，甚至是bug。這就是我在做這方面工作的時候，各家瀏覽器公司最耗費資源的地方。
再後來，微軟這方面守規矩一些了。但是市面上動態內容的複雜度不斷提升，甚至出現了在瀏覽器裏跑linux這種怪胎。於是乎大家又開始拼腳本執行器的優化。
總之，市面上這些瀏覽器最早的內核相對來說都沒有那麼高門檻。門檻在於過去的這幾十年發生的各種操蛋的事情，現在已經無法再重新經歷。因此要從頭寫一款與現行商業引擎兼容性很高的內核（也就是能正確顯示市面上絕大數有著各種各樣「方言」的內容），與其說難不如說除了大幅抄襲沒人能記住每個細節。就如中華文明的形成一樣，it just works。
所以，如果目標是互聯網，在開源核心上修改本來並沒有什麼，甚至是個明智的決定。能夠深入理解並定製化一個擁有如此複雜歷史沉澱的代碼塊，這挺不容易的。
但是如果只是利用內核本身提供的插件架構，寫了幾個過濾器換了個皮膚這種的，還要標榜自己開發的內核，那就真是恬不知恥了。開源社區有一個最基本的原則，就是要尊重別人的勞動。能夠看懂別人的勞動並在這個基礎上繼承發揮，這已經足夠榮耀了。不能理解這一點的人，覺得必須將所有光環戴在自己頭上的人，一定是底氣不足，知道自己實際並沒有做什麼。
至於某些回答當中所謂的沒有必要造輪子等等的論調，如果是在深入理解輪子是怎麼造的，以及在分析比較之後的言論，那麼我覺得很合理。如果只是囫圇吞棗，老子有的是錢，被別人狂坑也搞不清的貨色，真心希望你們能夠笑到最後。
------ 8月22日更新 -----
對於「輪子論」的一記響亮的耳光
https://www.zhihu.com/question/34448356/answer/59011310
推薦閱讀：
