什麼是類圖？
一個類圖是一種結構性UML圖，用於呈現物件導向軟體系統的靜態架構。作為不可或缺的UML圖類型，它會在您的應用程式中標示出個別的類別、介面與資料模型，明確記錄其內部欄位（屬性）、操作功能（方法），以及將它們連結在一起的結構關係。此藍圖對軟體工程師至關重要，因為他們需要將高階領域設計轉換為清晰且可維護的物件結構。
使用Mermaid.js，您可以使用直覺的純文字定義來勾勒出您的資料模型與系統服務。佈局引擎會自動計算方框大小，建立標準的UML資料區塊，並在您的畫布上自動對齊關聯箭頭，無需任何手動格式設定的負擔。
核心語法指南：元素與構造
要在 Mermaid 中設計出準確且符合標準的 UML 類圖，您必須掌握成員宣告、存取修飾符以及結構關係箭頭。
1. 宣告類別與類別區塊
您可以使用兩種有效的格式來定義類別。對於簡單的類別，請使用class關鍵字，後面接上類別名稱。如果您希望立即包含欄位與方法，請使用尾隨的大括號來建立明確的內容區塊：
classDiagram
class UserProfile {
+String username
+String email
+updateEmail(newEmail) void
}
2. 加入可見性／存取修飾符
為了記錄標準的 UML 封裝規則，請在屬性或方法名稱前直接放置特定符號，以定義其可見性層級：
+**公開：** 可從任何其他類別存取。-**私有：** 僅可在宣告類別內存取。#**保護：** 可在類別及其子類別中存取。~**套件 / 內部：** 可在相同套件邊界內存取。
classDiagram
class BankAccount {
-double balance
#String accountHolder
+getBalance() double
}
3. 掌握關係箭頭與繼承連結
為了顯示類別在您的 UML 圖表模型中如何互動，請使用專用的關係字串連接它們的 ID。在 Mermaid 中，線的方向很重要：箭頭頭部指向父類別或容器類別。
- 繼承 / 一般化（虛線或實線箭頭）：
Child --|> Parent（代表「是」關係）。 - 實現 / 實作：
Class ..|> Interface（代表類別履行介面合約）。 - 組合（實心菱形）：
Child --* Parent（代表嚴格的所有權；如果父類別死亡，子類別也會死亡）。 - 聚合（空心菱形）：
Child --o Parent（代表鬆散的集合關係；子類別可以獨立存在）。 - 依賴：
ClassA ..> ClassB（代表暫時的執行時參考）。
classDiagram
Car --|> Vehicle : "繼承自"
Engine --* Car : "是其中一部分"
建立乾淨類別架構佈局的最佳實務
- 視覺化分組類別成員： 始終將類別變數群組在主體區塊的頂部，而將函數群組在底部。此佈局符合標準 IDE 類別結構，使您的圖表立即可讀。
- 指定傳回類型： 在宣告方法時，將傳回類型附加至方法行的結尾（例如，
+fetchData() DataSet）。這能讓你的工程團隊獲得精確的實作背景。 - 保持多重性清晰： 為表示陣列數量或集合大小，請直接將多重性文字字串附加至關聯線包裝中（例如，
Customer "1" --o "many" Order).
現實世界中的 Mermaid.js 類別圖範例
範例 1：支付網關領域子系統（封裝與介面）
此功能藍圖模擬線上結帳領域服務。它示範了如何使用存取修飾符、群組類別成員，並乾淨地實作介面關係。
classDiagram
class PaymentProcessor {
<<interface>>
+processPayment(amount) boolean
+refundPayment(txnId) boolean
}
class StripeGateway {
-String apiKey
-String endpointUrl
+processPayment(amount) boolean
+refundPayment(txnId) boolean
-logTransaction(status) void
}
class PayPalGateway {
-String merchantId
+processPayment(amount) boolean
+refundPayment(txnId) boolean
}
StripeGateway ..|> PaymentProcessor : "實作"
PayPalGateway ..|> PaymentProcessor : "實作"
語法解析： 這個<<interface>> 標籤明確標示 `PaymentProcessor` 為高階架構合約。兩個具體的網關實作類別使用私有欄位（-apiKey）來儲存敏感憑證，同時公開公有付款流程（+processPayment）透過實作箭頭（..|>).
範例 2：企業級訂單處理引擎（組合與多重性）
此進階系統藍圖描繪了複雜的電子商務訂單管理架構，示範了如何在多個相互關聯的類別之間記錄結構上的擁有關係與物件數量。
classDiagram
class Customer {
+int customerId
+String name
+placeOrder() Order
}
class Order {
+int orderId
+Date dateCreated
-String internalStatus
+calculateTotal() double
}
class OrderItem {
+int itemId
+int quantity
+double pricePerUnit
}
class Address {
+String street
+String city
+String postalCode
}
Customer "1" --o "many" Order : "擁有"
OrderItem "1..*" --* "1" Order : "組成"
Address "1" --> Order : "寄送至"
語法分解：此範例說明了聚合與組合之間的差異。實心菱形箭頭（--*) 表示 `OrderItem` 與 `Order` 緊密關聯（若刪除訂單，其個別項目也會被銷毀）。相反地，空心菱形箭頭（--o) 表示 `Customer` 擁有多個訂單，但兩個實體均可獨立存在。多重性字串（例如 "1..*") 定義系統的關聯需求。