Бесплатно · Без регистрации · Поддержка файлов .mmd

Редактор диаграмм последовательности Mermaid

Диаграмма последовательности показывает, кто с кем разговаривает и в каком порядке. Она уместна, когда интересен обмен сообщениями между несколькими сторонами: авторизация, оплата, интеграция между сервисами. Если участник один, а важны ветвления, блок-схема скажет то же самое с меньшим шумом.

Открыть в редакторе →Читать руководство

Оплата картой с подтверждением по коду

Ценность этой диаграммы — в блоках `alt`: они показывают, что подтверждение запрашивается не всегда и что исходов два. Обратите внимание и на то, что платёжный шлюз общается с банком, а магазин об этом не знает: именно это диаграмма последовательности делает видимым, а блок-схема прячет.

sequenceDiagram
    autonumber
    participant K as Клиент
    participant M as Магазин
    participant P as Платёжный шлюз
    participant B as Банк-эмитент

    K->>M: Подтвердить заказ
    M->>P: Запросить авторизацию
    P->>B: Передать операцию
    B-->>P: Требуется подтверждение

    alt Банк запрашивает код
        P-->>K: Перенаправить на страницу банка
        K->>B: Ввести код из СМС
        B-->>P: Подтверждение пройдено
    else Банк не запрашивает
        B-->>P: Авторизовано сразу
    end

    P-->>M: Авторизация получена
    M-->>K: Заказ подтверждён
    M->>M: Зафиксировать продажу

Открыть в редакторе

Разобранные примеры

1. Два участника и одно сообщение

`->>` — стрелка со сплошным наконечником, это вызов. `-->>` — пунктирная, это ответ. Этой пары хватает для большинства диаграмм.

sequenceDiagram
    Клиент->>API: Создать заказ
    API-->>Клиент: 201 Created

Открыть в редакторе

2. Псевдонимы для длинных имён

`participant X as Длинное имя` даёт короткий идентификатор для набора и читаемое имя для чтения. Объявление участников в начале заодно фиксирует их порядок на рисунке — иначе его определяет порядок первого упоминания.

sequenceDiagram
    participant Б as Браузер
    participant A as API заказов
    participant С as Сервис склада

    Б->>A: POST /orders
    A->>С: Зарезервировать товар
    С-->>A: Резерв подтверждён
    A-->>Б: 201 Created

Открыть в редакторе

3. Активации и вызовы самого себя

`activate` и `deactivate` рисуют полосу, показывающую, что участник занят работой. Суффиксы `+` и `-` на стрелке делают то же самое короче. Стрелка участника к самому себе — это внутренняя работа.

sequenceDiagram
    participant A as API
    participant Д as База данных

    Клиент->>+A: GET /invoice/42
    A->>+Д: SELECT счёт
    Д-->>-A: Строка найдена
    A->>A: Посчитать НДС
    A-->>-Клиент: 200 OK

Открыть в редакторе

4. Альтернативы, опции и циклы

`alt`/`else` — взаимоисключающие пути, `opt` — блок, которого может не быть, `loop` — повторение. Все три закрываются через `end`, и забыть про него — самая частая ошибка этого типа.

sequenceDiagram
    participant K as Клиент
    participant A as API
    participant П as Почтовый сервис

    K->>A: Запрос на регистрацию
    alt Адрес уже занят
        A-->>K: 409 Conflict
    else Адрес свободен
        A-->>K: 201 Created
        A->>П: Отправить письмо-подтверждение
        loop До 3 попыток
            П->>П: Повторить при сбое отправки
        end
    end
    opt Клиент согласился на рассылку
        A->>П: Добавить в список
    end

Открыть в редакторе

5. Заметки и параллельные ветви

`par` показывает ветви, идущие одновременно, — то, на что блок-схема лишь намекает, но никогда не утверждает. Заметки — правильное место для подробности, которая не влезает в подпись сообщения.

sequenceDiagram
    participant A as API заказов
    participant Б as Биллинг
    participant Л as Логистика

    Note over A: Заказ уже оплачен

    par Уведомить биллинг
        A->>Б: Выставить счёт
        Б-->>A: Счёт 2026/0431
    and Уведомить логистику
        A->>Л: Подготовить отгрузку
        Л-->>A: Накладная создана
    end

    Note over Б,Л: Каждая идёт в своём темпе

Открыть в редакторе

Справочник синтаксиса диаграммы последовательности

Запоминать надо стрелки, и они принадлежат только этому типу: `-->` из блок-схемы здесь означает другое, а `->>` отсюда в диаграмме классов даёт ошибку.

Синтаксис	Значение
sequenceDiagram	Открывает диаграмму. Регистр важен: `sequencediagram` не работает.
participant A	Объявляет участника и фиксирует его позицию.
participant A as Имя	Короткий идентификатор с читаемым именем.
actor A	То же, что participant, но рисует человечка.
A->>B: текст	Сообщение со сплошным наконечником — вызов.
A-->>B: текст	Пунктирная линия — ответ.
A-)B: текст	Открытый наконечник — асинхронное сообщение.
A->>A: текст	Участник вызывает сам себя.
activate A / deactivate A	Отмечает период, когда A занят.
A->>+B: / B-->>-A:	То же самое в краткой форме, прямо на стрелке.
alt условие ... else ... end	Взаимоисключающие пути.
opt условие ... end	Блок, которого может не быть.
loop текст ... end	Повторение.
par ... and ... end	Одновременные ветви.
Note over A,B: текст	Заметка над одним или несколькими участниками. Есть `Note left of` и `Note right of`.
autonumber	Автоматически нумерует сообщения.

Шесть ошибок, ломающих диаграмму последовательности

Воспроизведены на Mermaid 11.12.2. Самая частая с большим отрывом — первая, и её сообщение об ошибке хуже всех указывает на место проблемы.

Что вы видите

Parse error, указывающая на последнюю строку диаграммы

Почему

Блок открыт и не закрыт. `alt`, `opt`, `loop` и `par` требуют своего `end`. Mermaid сообщает о сбое в тот момент, когда у него кончается ввод, поэтому номер строки указывает на конец файла, а не на незакрытый блок. При двух вложенных блоках это становится по-настоящему трудно разглядеть.

Решение

Посчитайте открытые блоки и написанные `end`. Если ошибка указывает на последнюю строку, почти всегда дело в этом.

Ошибка

sequenceDiagram
    Клиент->>API: Запрос
    alt Всё хорошо
        API-->>Клиент: 200 OK

Исправлено

sequenceDiagram
    Клиент->>API: Запрос
    alt Всё хорошо
        API-->>Клиент: 200 OK
    end

Что вы видите

No diagram type detected matching given configuration

Почему

Неверный регистр в ключевом слове. `sequenceDiagram` работает, `sequencediagram` и `SequenceDiagram` — нет. Mermaid различает регистр во всех ключевых словах.

Решение

Заглавная D, остальное строчными.

Ошибка

sequencediagram
    Клиент->>API: Привет

Исправлено

sequenceDiagram
    Клиент->>API: Привет

Что вы видите

Диаграмма рисуется, но сообщение выходит без подписи

Почему

После двоеточия нет текста. Измерено: Mermaid этого не отвергает — он рисует сообщение с пустой подписью, и стрелка остаётся без пояснения. По-настоящему падает другое — пропуск самого двоеточия: `Клиент->>API` без него даёт `Expecting 'TXT', got 'NEWLINE'`. Значит, двоеточие обязательно, а текст нет, ровно наоборот тому, что можно предположить.

Решение

Напишите после двоеточия хоть одно слово. Стрелка без подписи почти никогда не то, что вы имели в виду.

Ошибка

sequenceDiagram
    Клиент->>API:
    API-->>Клиент: 200

Исправлено

sequenceDiagram
    Клиент->>API: Создать заказ
    API-->>Клиент: 200

Что вы видите

Parse error после `alt` с длинным условием

Почему

Перенос строки внутри условия блока. Условие `alt`, `opt` или `loop` должно умещаться в одну строку; при переносе вторая половина трактуется как сообщение и никуда не встаёт.

Решение

Держите условие в одной строке. Если оно слишком длинное, сократите его, а подробность вынесите в заметку.

Ошибка

sequenceDiagram
    alt На счёте достаточно
    средств для списания
        A-->>B: OK
    end

Исправлено

sequenceDiagram
    alt На счёте достаточно средств
        A-->>B: OK
    end
    Note over A,B: Остаток сверяется с дневным лимитом

Что вы видите

Диаграмма рисуется, но появляется участник, которого вы не объявляли

Почему

Опечатка в имени участника. Mermaid создаёт участника при первом упоминании, поэтому `Биллинг` и `Билинг` — две разные колонки, и никакого предупреждения не будет. По-русски отдельно подводит буква ё: `Платёж` и `Платеж` выглядят почти одинаково и дают две колонки.

Решение

Объявляйте участников через `participant` в начале. Опечатку это не предотвратит, но сделает видимым список допустимых имён, и лишняя колонка сразу бросится в глаза.

Ошибка

sequenceDiagram
    Клиент->>Платёж: Списать средства
    Платеж-->>Клиент: Списано

Исправлено

sequenceDiagram
    participant K as Клиент
    participant П as Платёж
    K->>П: Списать средства
    П-->>K: Списано

Что вы видите

Диаграмма рисуется, но порядок колонок не тот, который вы хотели

Почему

Вы не объявили участников. Без объявлений порядок задаётся первым упоминанием каждого имени, поэтому сообщение, добавленное в начало диаграммы, может переставить все колонки и перекрестить стрелки. Диаграмма остаётся верной, но читается заметно хуже.

Решение

Объявите всех участников в начале, в том порядке, в котором хотите их видеть.

Ошибка

sequenceDiagram
    Банк-->>Шлюз: Авторизовано
    Клиент->>Магазин: Подтвердить заказ
    Магазин->>Шлюз: Авторизовать

Исправлено

sequenceDiagram
    participant Клиент
    participant Магазин
    participant Шлюз
    participant Банк
    Клиент->>Магазин: Подтвердить заказ
    Магазин->>Шлюз: Авторизовать
    Шлюз->>Банк: Передать операцию
    Банк-->>Шлюз: Авторизовано

Заметки о рендеринге

Измерено на том Mermaid 11.12.2, который использует сайт. Диаграмма последовательности отличается от остальных в двух конкретных вещах.

Ширину задают участники, а не сообщения

Измерено: два участника дают viewBox шириной 450 пикселей, шесть — 1250, то есть примерно 200 пикселей на каждую добавленную колонку, независимо от текста сообщений. Сообщения добавляют только высоту, около 46 пикселей каждое. С одной оговоркой: если подпись сообщения длиннее минимальной ширины колонки, она всё-таки расширяет диаграмму — та же пара участников выросла с 450 до 603 пикселей только из-за удлинения текста одного сообщения. По-русски подписи в среднем длиннее английских, так что этот порог достигается раньше.

Единственный тип с отрицательным началом viewBox

Диаграммы последовательности выходят с viewBox, начинающимся с `-50 -10`, а не с `0 0`. Это не дефект: Mermaid резервирует этот отступ под рамки участников. Значение это имеет только если вы обрабатываете SVG собственными инструментами, потому что любой расчёт, полагающий начало координат нулевым, обрежет первую колонку.

Здесь экспорт в PNG точен

В отличие от блок-схемы, диаграмм классов, состояний и ER, диаграмма последовательности рисует подписи обычным SVG-текстом, а не внутри `<foreignObject>`. Поэтому её можно растрировать напрямую: экспортированный PNG совпадает с экраном без промежуточной перерисовки и без сдвига типографики.

Объявленный и ни разу не использованный участник всё равно рисуется

`participant`, который не отправляет и не получает ни одного сообщения, появляется на диаграмме пустой колонкой. Иногда это делают намеренно — показать, что кто-то существует, но в этом потоке не участвует. Но чаще это просто остаток: удалили последнее сообщение участника и забыли удалить его объявление.

Тема меняет цвета, но никогда — геометрию

Одна и та же диаграмма в светлой и тёмной теме даёт одинаковый viewBox, так что колонки не сдвигаются, а блоки не меняют размер при смене темы.

Когда лучше взять другую диаграмму

Если участник только один, показывать нечего. Диаграмма из одной колонки со стрелками к самой себе — это неудобно записанная блок-схема.

Если вы хотите описать состояния, через которые проходит объект, а не разговор нескольких сторон, возьмите диаграмму состояний. Признак заметный: если вы раз за разом пишете одно и то же сообщение с разными условиями, перед вами конечный автомат.

А если в обмене больше десятка сообщений, разбейте его. Диаграмма последовательности на шестьдесят сообщений технически верна и практически непригодна; почти всегда она читается лучше как три диаграммы — по одной на фазу, связанные заметкой.

Другие типы диаграмм

Автор Dominik Malsch · Обновлено: 8 сентября 2026 г.

Открыть редактор →