在很多內容系統中，都需要過濾一些敏感詞，比如說"fuck you shit up"就要發現裡面有"fuck"、"shit"這些髒詞。

首先，我們要先了解敏感詞過濾的一些特徵：

1. 敏感詞多，一般成千上萬

2. 單詞長度有限，一般不會超過10

3. 要過濾的句子長度有限，一般不過1000

通過上面特徵，我們粗略的算一下，如果採用暴力匹配方案的話，複雜度將會是1k*10*1k=10^7左右的運算量。

現在再考慮一下，該機制要用在什麼樣的系統中。如果是一個內容釋出平臺，每天呼叫次數有限，比如評論功能，不是特別頻繁的，暴力匹配或許是個還不錯的方案，因為簡單易實現難出錯：

是的，不要想太多，暴力匹配就好了。仔細想想，併發量不高，不會產生大量匹配過程，CPU不會太繁忙，暴力匹配也並不會對系統造成什麼影響。

但如果是用在IM(及時訊息)系統中呢？比如直播。

該類系統的特點是，在一段時間內，會同時有大量的請求。字串處理是很耗CPU的操作，用上面暴力匹配方式的話，大量併發的請求，會不會造成大量的訊息延時？

所以現在我們需要一種結構，可以儲存多個字串，並且快速匹配，最適合的莫過於Trie(字典樹)了，也就是網上常說的DFA(確定有限狀態機):

(不好意思，寫的有點緊湊了，螢幕大小有限。)這種辦法的好處很明顯了，把詞庫數量忽略了，計算量只剩10*1k=1w了。

上面字典樹的好處很明顯，但也會發現一個問題，就是每次都從根上走一遍，那有沒有辦法呢？有，就是用AC自動機，在每個節點上多記錄一個fail指標，但這種方法優化下來，最終的結果還是10*1k=1w。

這裡先推薦一個AC自動機的庫：https://github.com/eachain/aca，github上的一個AC自動機的庫，這個庫比較好玩的是Debug功能，可以把整棵樹打印出來，方便除錯及學習用。

好，言歸正傳，仔細觀察會發現，fail指標指向的節點多數還不是完整的單詞，這就造成了多數時候的跳轉是無用的。所以上面的庫優化了這一點，fail指標指向的就是一個完整的單詞，這樣就會把失配情況拋棄掉。但同樣的，這也只是無限逼近O(1k)。

我把一個7700大小的庫匯入試了一下，發現大多情況是這樣的：

發現了麼？只有及其少數的fail指標是有指向的，翻幾屏發現fail全是0的太常見了，當然這是優化過後的，如果是優化之前的，應該會多一些有指向的fail。

到現在為止，我們說的都是機械的掃描字串的辦法，會有很多誤判的時候，比如“江陰毛紡廠”，不能做分詞，就會誤判了。但那些方法已經超出本篇範圍，這裡就不說了。

最後，如果大家要做敏感詞過濾機制，而且可以有一定誤判的情況下，建議用優化後的AC自動機，99%的情況下，時間複雜度等於串長。