。第二種實現成本較高，但是更靈活，而且更安全，更適合對抗場景，我這裏主要講一下第二種。基於語法層面的混淆器其實類似於編譯器，基本原理和編譯器類似，我們先對編譯器做一些基本的介紹。
詞法分析、語法分析
名詞解釋
token: 詞法單元，也有叫詞法記號的，詞法分析器的產物，文本流被分割後的最小單位。
AST: 抽象語法樹，語法分析器的產物，是源代碼的抽象語法結構的樹狀表現形式。
編譯器VS混淆器
編譯器工作流程
簡單的說，當我們讀入一段字符串文本（source code），詞法分析器會把它拆成一個一個小的單位（token），比如數字1 是一個token, 字符串'abc'是一個token等等。接下來語法分析器會把這些單位組成一顆樹狀結構（AST），這個樹狀結構就代表了token們的組成關係。比如 1 + 2 就會展示成一棵加法樹，左右子節點分別是token - 1 和token - 2 ，中間token表示加法。編譯器根據生成的AST轉換到中間代碼，最終轉換成機器代碼。
對編譯器更多細節感興趣的同學可以移步龍書：編譯原理
混淆器工作流程
編譯器需要把源代碼編譯成中間代碼或者機器碼，而我們的混淆器輸出其實還是js。所以我們從語法分析之後往下的步驟並不需要。想想我們的目標是什麼，是修改原有的js代碼結構，在這裏面這個結構對應的是什麼呢？就是AST。任何一段正確的js代碼一定可以組成一顆AST，同樣，因爲AST表示了各個token的邏輯關係，我們也可以通過AST反過來生成一段js代碼。所以，你只需要構造出一顆AST，就能生成任何js代碼！混淆過程如上右圖所示
通過修改AST生成一個新的AST，新的AST就可以對應新的JavaScript代碼。
規則設計
知道了大致的混淆流程，最重要的環節就是設計規則。我們上面說了，我們需要生成新的AST結構意味着會生成和源代碼不一樣的js代碼，但是我們的混淆是不能破壞原有代碼的執行結果的，所以混淆規則必須保證是在不破壞代碼執行結果的情況下，讓代碼變得更難以閱讀。
具體的混淆規則各位可以自行根據需求設計，比如拆分字符串、拆分數組，增加廢代碼等等。