Miễn phí · Không cần đăng ký · Hỗ trợ tệp .mmd

Trình tạo sơ đồ tuần tự Mermaid

Sơ đồ tuần tự cho thấy ai nói với ai và theo thứ tự nào. Nó hợp khi chủ đề là việc trao đổi thông điệp giữa nhiều bên — xác thực, thanh toán, tích hợp giữa các dịch vụ. Nếu chỉ có một bên tham gia và điều quan trọng là các nhánh rẽ, lưu đồ nói cùng một điều với ít nhiễu hơn.

Mở cái này trong trình soạn thảo →Đọc hướng dẫn

Thanh toán bằng mã QR qua ứng dụng ngân hàng

Giá trị của sơ đồ này nằm ở khối `alt`: nó cho thấy giao dịch có hai kết cục khác nhau, và cửa hàng biết kết quả không phải từ khách mà từ hệ thống chuyển mạch. Cũng để ý là mũi tên cuối quay về một cách bất đồng bộ, tách khỏi màn hình của khách. Đó đúng là thứ sơ đồ tuần tự làm cho thấy được còn lưu đồ thì giấu đi.

sequenceDiagram
    autonumber
    participant K as Khách hàng
    participant CH as Cửa hàng
    participant CM as Hệ thống chuyển mạch
    participant NH as Ngân hàng của khách

    K->>CH: Xác nhận đơn hàng
    CH->>CM: Tạo mã QR thanh toán
    CM-->>CH: Mã QR và mã giao dịch
    CH-->>K: Hiển thị mã QR
    K->>NH: Quét mã và xác nhận trong ứng dụng

    alt Đủ số dư và trong hạn mức
        NH->>CM: Ghi nợ thành công
        CM-->>CH: Báo có
        CH->>CH: Đánh dấu đã thanh toán
    else Không đủ số dư hoặc quá hạn mức
        NH->>CM: Từ chối giao dịch
        CM-->>CH: Báo thất bại
        CH->>CH: Giữ đơn hàng ở trạng thái chờ
    end

    CH-->>K: Hiện trang kết quả

Mở cái này trong trình soạn thảo

Quảng cáo

Ví dụ có giải thích

1. Hai bên tham gia và một thông điệp

`->>` là mũi tên đầu đặc, tức một lời gọi. `-->>` là nét đứt và mang nghĩa hồi đáp. Cặp này đủ dùng cho phần lớn sơ đồ.

sequenceDiagram
    Client->>API: Tạo đơn hàng
    API-->>Client: 201 Created

Mở trong trình soạn thảo

2. Bí danh cho tên dài

`participant X as Tên dài` cho bạn một định danh ngắn để gõ và một cái tên dễ đọc để đọc. Khai báo các bên ở đầu cũng cố định thứ tự cột của họ trong hình; nếu không khai báo, thứ tự do lần xuất hiện đầu tiên quyết định.

sequenceDiagram
    participant TD as Trình duyệt
    participant DH as Dịch vụ đơn hàng
    participant KHO as Dịch vụ kho

    TD->>DH: POST /don-hang
    DH->>KHO: Giữ hàng
    KHO-->>DH: Đã giữ hàng
    DH-->>TD: 201 Created

Mở trong trình soạn thảo

3. Kích hoạt và tự gọi chính mình

`activate` và `deactivate` vẽ một thanh cho thấy bên đó đang làm việc. Hậu tố `+` và `-` gắn trên mũi tên làm đúng việc ấy mà gõ ít hơn. Mũi tên từ một bên về chính nó nghĩa là xử lý nội bộ.

sequenceDiagram
    participant A as API
    participant CSDL as Cơ sở dữ liệu

    Client->>+A: GET /hoa-don/42
    A->>+CSDL: SELECT hóa đơn
    CSDL-->>-A: Tìm thấy bản ghi
    A->>A: Tính thuế giá trị gia tăng
    A-->>-Client: 200 OK

Mở trong trình soạn thảo

4. Lựa chọn, tùy chọn và vòng lặp

`alt`/`else` là các nhánh loại trừ nhau, `opt` là khối có thể không xảy ra, còn `loop` là sự lặp lại. Cả ba đều đóng bằng `end`, và quên điều đó là lỗi hay gặp nhất của loại sơ đồ này.

sequenceDiagram
    participant ND as Người dùng
    participant A as API
    participant TH as Dịch vụ thư

    ND->>A: Yêu cầu mở tài khoản
    alt Địa chỉ đã được đăng ký
        A-->>ND: 409 Conflict
    else Địa chỉ còn trống
        A-->>ND: 201 Created
        A->>TH: Gửi thư xác minh
        loop Tối đa 3 lần
            TH->>TH: Gửi lại nếu thất bại
        end
    end
    opt Người dùng đồng ý nhận bản tin
        A->>TH: Thêm vào danh sách
    end

Mở trong trình soạn thảo

5. Ghi chú và xử lý song song

`par` cho thấy các nhánh diễn ra cùng lúc, điều mà lưu đồ chỉ có thể ngụ ý chứ không bao giờ khẳng định. Ghi chú là chỗ đúng cho chi tiết không nhét vừa vào nhãn thông điệp.

sequenceDiagram
    participant DH as Dịch vụ đơn hàng
    participant HD as Hóa đơn
    participant VC as Vận chuyển

    Note over DH: Đơn hàng đã được thanh toán

    par Báo cho bộ phận hóa đơn
        DH->>HD: Phát hành hóa đơn
        HD-->>DH: Hóa đơn 2026/0431
    and Báo cho bộ phận vận chuyển
        DH->>VC: Chuẩn bị gói hàng
        VC-->>DH: Đã tạo mã vận đơn
    end

    Note over HD,VC: Mỗi bên chạy theo nhịp riêng

Mở trong trình soạn thảo

Tóm tắt cú pháp sơ đồ tuần tự

Thứ cần nhớ là các mũi tên, và chúng chỉ thuộc về loại sơ đồ này: dấu `-->` của lưu đồ ở đây mang nghĩa khác, còn dấu `->>` ở đây lại là lỗi trong sơ đồ lớp.

Cú pháp	Ý nghĩa
sequenceDiagram	Mở sơ đồ. Phân biệt hoa thường: `sequencediagram` không chạy.
participant A	Khai báo một bên tham gia và cố định vị trí của họ.
participant A as Tên	Định danh ngắn kèm tên dễ đọc.
actor A	Như participant, nhưng vẽ hình người.
A->>B: văn bản	Thông điệp đầu mũi đặc — một lời gọi.
A-->>B: văn bản	Nét đứt — một hồi đáp.
A-)B: văn bản	Đầu mũi mở — thông điệp bất đồng bộ.
A->>A: văn bản	Một bên tự gọi chính mình.
activate A / deactivate A	Đánh dấu khoảng thời gian A đang làm việc.
A->>+B: / B-->>-A:	Cũng vậy nhưng viết gọn ngay trên mũi tên.
alt điều kiện ... else ... end	Các nhánh loại trừ nhau.
opt điều kiện ... end	Khối có thể không xảy ra.
loop văn bản ... end	Lặp lại.
par ... and ... end	Các nhánh song song.
Note over A,B: văn bản	Ghi chú phía trên một hoặc nhiều bên. Còn có `Note left of` và `Note right of`.
autonumber	Tự đánh số các thông điệp.

Quảng cáo

Sáu lỗi làm hỏng sơ đồ tuần tự

Đều dựng lại trên Mermaid 11.12.2. Lỗi đầu tiên phổ biến hơn hẳn, và thông báo đi kèm nó thuộc loại chỉ sai chỗ nhất.

Bạn thấy gì

Parse error chỉ vào dòng cuối cùng của sơ đồ

Vì sao

Một khối đã mở mà không bao giờ đóng. `alt`, `opt`, `loop` và `par` đều đòi `end` của riêng chúng. Mermaid báo lỗi ở chỗ nó hết dữ liệu vào, nên số dòng chỉ vào cuối tệp chứ không chỉ vào khối còn dang dở. Với hai khối lồng nhau thì tìm ra thật sự khó.

Cách sửa

Đếm số khối đã mở và số `end` bạn đã viết. Nếu lỗi chỉ vào dòng cuối thì gần như luôn là chuyện này.

Sai

sequenceDiagram
    Client->>API: Yêu cầu
    alt Mọi thứ ổn
        API-->>Client: 200 OK

Đúng

sequenceDiagram
    Client->>API: Yêu cầu
    alt Mọi thứ ổn
        API-->>Client: 200 OK
    end

Bạn thấy gì

No diagram type detected matching given configuration

Vì sao

Viết sai hoa thường ở từ khóa. `sequenceDiagram` chạy được; `sequencediagram` và `SequenceDiagram` thì không. Mermaid phân biệt hoa thường ở mọi từ khóa.

Cách sửa

Chữ D viết hoa, phần còn lại viết thường.

Sai

sequencediagram
    Client->>API: Xin chào

Đúng

sequenceDiagram
    Client->>API: Xin chào

Bạn thấy gì

Vẽ được, nhưng thông điệp ra không có chữ

Vì sao

Không có chữ sau dấu hai chấm. Đã đo: Mermaid không từ chối — nó vẽ thông điệp với nhãn rỗng, và mũi tên nằm đó không một lời giải thích. Thứ thật sự đổ là bỏ hẳn dấu hai chấm: chỉ `Client->>API` sẽ cho `Expecting 'TXT', got 'NEWLINE'`. Vậy dấu hai chấm là bắt buộc còn phần chữ thì không — ngược hẳn với suy đoán thông thường.

Cách sửa

Hãy viết gì đó sau dấu hai chấm, dù chỉ một chữ. Một mũi tên không nhãn gần như không bao giờ là điều bạn muốn.

Sai

sequenceDiagram
    Client->>API:
    API-->>Client: 200

Đúng

sequenceDiagram
    Client->>API: Tạo đơn hàng
    API-->>Client: 200

Bạn thấy gì

Parse error sau một `alt` có điều kiện dài

Vì sao

Xuống dòng ngay bên trong điều kiện của khối. Điều kiện của `alt`, `opt` hay `loop` phải nằm gọn trên một dòng; nếu bạn ngắt nó ra, nửa sau bị hiểu thành một thông điệp và không khớp vào đâu cả.

Cách sửa

Giữ điều kiện trên một dòng. Nếu dài quá thì rút gọn và đưa chi tiết vào ghi chú.

Sai

sequenceDiagram
    alt Khách hàng còn đủ
    số dư trong tài khoản
        A-->>B: OK
    end

Đúng

sequenceDiagram
    alt Khách hàng còn đủ số dư
        A-->>B: OK
    end
    Note over A,B: Số dư được đối chiếu với hạn mức ngày

Bạn thấy gì

Vẽ được, nhưng xuất hiện một bên tham gia mà bạn không hề khai báo

Vì sao

Gõ sai tên một bên tham gia. Mermaid tạo bên tham gia ngay lần đầu gặp cái tên đó, nên `Vận chuyển` và `Vận chuyên` là hai cột riêng biệt và không có gì cảnh báo. Trong tiếng Việt, nguồn sai phổ biến nhất là dấu thanh: chỉ cần một lần rơi dấu là có thêm một cột.

Cách sửa

Khai báo các bên bằng `participant` ở đầu. Việc đó không ngăn được lỗi gõ, nhưng làm lộ ra tên nào mới là đúng, và cột thừa sẽ đập ngay vào mắt.

Sai

sequenceDiagram
    ĐơnHàng->>VậnChuyển: Chuẩn bị gói hàng
    VậnChuyên-->>ĐơnHàng: Gói hàng đã xong

Đúng

sequenceDiagram
    participant DH as Đơn hàng
    participant VC as Vận chuyển
    DH->>VC: Chuẩn bị gói hàng
    VC-->>DH: Gói hàng đã xong

Bạn thấy gì

Vẽ được, nhưng thứ tự cột không phải thứ tự bạn muốn

Vì sao

Bạn chưa khai báo các bên tham gia. Không có khai báo thì thứ tự do lần xuất hiện đầu tiên của mỗi tên quyết định, nên một thông điệp thêm vào đầu sơ đồ có thể xếp lại toàn bộ cột và làm các mũi tên cắt chéo nhau. Sơ đồ vẫn đúng, nhưng đọc kém hơn hẳn.

Cách sửa

Khai báo tất cả các bên ở phần đầu, theo đúng thứ tự bạn muốn thấy.

Sai

sequenceDiagram
    NganHang-->>ChuyenMach: Đã ghi nợ
    Khach->>CuaHang: Xác nhận đơn hàng
    CuaHang->>ChuyenMach: Tạo giao dịch

Đúng

sequenceDiagram
    participant Khach
    participant CuaHang
    participant ChuyenMach
    participant NganHang
    Khach->>CuaHang: Xác nhận đơn hàng
    CuaHang->>ChuyenMach: Tạo giao dịch
    ChuyenMach->>NganHang: Chuyển tiếp
    NganHang-->>ChuyenMach: Đã ghi nợ

Ghi chú về việc vẽ

Đo trên Mermaid 11.12.2, đúng phiên bản trang này dùng. Sơ đồ tuần tự khác các loại còn lại ở hai điểm cụ thể.

Chiều rộng do các bên tham gia quyết định, không phải do thông điệp

Đã đo: hai bên tham gia cho viewBox rộng 450 pixel, sáu bên cho 1250, tức khoảng 200 pixel cho mỗi cột thêm vào, bất kể nội dung thông điệp là gì. Thông điệp chỉ thêm chiều cao, mỗi cái khoảng 46 pixel. Có một ngoại lệ: nếu nhãn thông điệp rộng hơn bề rộng tối thiểu của cột thì nó thật sự nới rộng sơ đồ — cùng một cặp bên tham gia đã đi từ 450 lên 603 pixel chỉ vì chữ của một thông điệp dài ra. Nhãn tiếng Việt đo được 217 pixel so với 204 pixel của tiếng Anh cho cùng một ý, nên chuyện đó xảy ra sớm hơn một chút.

Loại duy nhất có gốc viewBox âm

Sơ đồ tuần tự sinh ra với viewBox bắt đầu từ `-50 -10` chứ không phải `0 0`. Đây không phải lỗi: Mermaid chừa khoảng lề đó cho khung của các bên tham gia. Điều này chỉ quan trọng nếu bạn xử lý SVG bằng công cụ riêng, vì mọi phép tính giả định gốc bằng không sẽ cắt mất cột đầu tiên.

Ở đây việc xuất PNG là chính xác

Khác với lưu đồ và các sơ đồ lớp, trạng thái, ER, sơ đồ tuần tự vẽ nhãn bằng văn bản SVG thuần chứ không đặt trong `<foreignObject>`. Nhờ vậy nó chuyển thành ảnh raster trực tiếp được: tệp PNG xuất ra khớp với màn hình, không qua bước vẽ lại trung gian và không lệch kiểu chữ.

Dấu tiếng Việt dùng được trong định danh, chỉ khoảng trắng là không

Đã kiểm chứng: `ĐơnHàng` và `VậnChuyển` chạy tốt làm định danh của bên tham gia, dấu thanh và chữ Đ đều không gây vấn đề gì. Thứ duy nhất làm hỏng là khoảng trắng giữa các âm tiết — và trong sơ đồ tuần tự thì hậu quả nhẹ nhàng hơn nhiều so với chỗ khác, vì `participant X as Tên có khoảng trắng` là cách viết hoàn toàn hợp lệ. Đây là loại sơ đồ duy nhất mà tiếng Việt gần như không phải đánh đổi gì.

Chủ đề đổi màu, không bao giờ đổi hình học

Cùng một sơ đồ ở chủ đề sáng và tối cho viewBox y hệt nhau, nên các cột không xê dịch và các khối không đổi kích thước khi đổi chủ đề.

Khi nào nên dùng loại sơ đồ khác

Nếu chỉ có một bên tham gia thì chẳng có trình tự nào để trình bày. Một sơ đồ chỉ một cột với các mũi tên quay về chính nó là một lưu đồ được viết theo cách bất tiện.

Nếu bạn muốn mô tả các trạng thái mà một thứ đi qua chứ không phải cuộc trao đổi giữa nhiều bên, hãy dùng sơ đồ trạng thái. Dấu hiệu khá rõ: khi bạn viết đi viết lại cùng một thông điệp với điều kiện khác nhau, thứ trước mặt bạn là một máy trạng thái.

Còn nếu cuộc trao đổi vượt quá mười lăm thông điệp, hãy chia nhỏ nó. Một sơ đồ tuần tự sáu mươi thông điệp thì đúng về mặt kỹ thuật và vô dụng với con người; hầu như lúc nào nó cũng đọc tốt hơn khi thành ba sơ đồ, mỗi giai đoạn một cái, nối với nhau bằng một ghi chú.

Các loại sơ đồ khác

Viết bởi Dominik Malsch · Cập nhật lần cuối: 8 tháng 9, 2026

Mở trình soạn thảo →