Statechart 可以透過多種方式來解釋，我們稍後會談到這些解釋，但本質上，Statechart 是一種繪圖。
這是一個簡單的 Statechart：
然而，對於想要從中獲益的軟體工程師來說，這種繪圖方式並不是很有用，所以讓我們深入探討其他描述 Statechart 是什麼的方法。定義 Statechart 的原始論文將它們稱為「複雜系統的視覺形式化語言」（Harel, 1987）。了解了這一點，讓我們試著解釋 Statechart。
簡單來說，Statechart 是一種功能更強大的狀態機。這種增強解決了狀態機的許多問題，特別是隨著狀態機的成長而發生的狀態爆炸。本網站的目標之一就是幫助解釋 Statechart 是什麼以及它們如何有用。
Statechart 提供了令人驚訝的好處。
值得注意的是，你已經在程式碼中編寫了狀態機，只是它們隱藏在程式碼中。
使用 Statechart 有一些缺點，你應該注意。
除了上述幾點之外，還有一些常見的反對 Statechart 的論點：
上述的好處應該很清楚，引入 Statechart 通常是淨收益。
首先，要知道一個 W3C 技術委員會花了 10 多年（2005 年至 2015 年）將稱為 SCXML（是的，Statechart XML）的標準化，它定義了許多語義並規定了如何處理某些邊緣情況。有許多工具可以讀取、編寫甚至執行用 SCXML 編寫的 Statechart，支援多種語言。也有一些衍生產品支援與 SCXML 相同的模型，但使用不同的語法。
此外，還有針對各種平台的 Statechart 函式庫，它們在不同程度上支援 SCXML 所描述的語義。你應該考慮使用這些函式庫來處理那些邊緣情況。這些函式庫通常會以正確的順序執行進入和退出動作等。
除了僅使用 Statechart 來為獨立於實際執行程式碼的文檔中的行為建模之外，還可以利用各種機器格式來設計行為，並在執行時實際成為行為。其想法是擁有一個描述元件行為的單一事實來源，這個單一來源可以驅動實際的執行程式碼，同時也可以用來生成精確的圖表來視覺化 Statechart。
這帶來了一些不同的優缺點：
本質上，如果你在程式碼中有任何 Statechart 的定義，你所需要做的就是採用該表示法並自動生成視覺化的 Statechart。當然，當定義在單獨的檔案中時，例如 JSON 或 XML 檔案，這會更簡單。
這一切都在如何使用 Statechart 的頁面上進行了解釋！
如果你想與人聊聊 Statechart，可以前往 gitter.im（無需登入即可查看聊天），在那裡你會找到一個志同道合的開發者社群，他們可以幫助你理解並從使用 Statechart 中獲益。對於更偏向問答的網站，請前往 statecharts GitHub 討論區，我們將盡力回答你的問題。
有相當多的人撰寫了書籍或舉辦了演講，以各種方式探討 Statechart，它們都包含在我們的資源頁面中。如果你寫了相關內容，請透過在 GitHub 討論區發布來分享。
有些頁面在文檔網路上沒有找到合適的位置，因此在此榮譽提及：
此術語解釋來自 statecharts.dev 專案。請查看 GitHub 上的討論，在那裡你可以找到更多討論 Statechart 的人。
使用 github.com/statecharts 的 GitHub Pages 發布（編輯此頁面）
術語：動作、活動、原子狀態、自動轉換、複合狀態、條件狀態、延遲事件、延遲轉換、進入事件、退出、最終狀態、生成事件、保護、歷史狀態、初始狀態、內部事件、局部轉換、並行狀態、偽狀態、觸發事件、精煉、自我轉換、狀態轉換