Mermaid-Diagramme: Schnellstart und Cheat Sheet für Entwickler

Mermaid ist ein textbasiertes Diagrammwerkzeug für Menschen, die Diagramme lieber schreiben, als Kästchen auf einer Leinwand zu verschieben. Es verwendet eine Markdown-ähnliche Syntax, um Flussdiagramme, Sequenzdiagramme, Klassendiagramme, Zustandsautomaten, Zeitachsen, Gantt-Diagramme, Entity-Relationship-Diagramme und mehr zu beschreiben.

Für technische Blogs ist Mermaid eine sehr gute Standardoption. Die Diagramme leben direkt neben dem Artikel, können in Git überprüft werden und lassen sich bei Systemänderungen leicht aktualisieren. Statische Bilddiagramme sehen zwar schön aus, jedoch nur bis zur ersten Architekturänderung. Mermaid-Diagramme sind nicht perfekt, altern aber deutlich besser.

Dieser Leitfaden ist ein praktisches Mermaid-Schnellstart- und Cheat-Sheet für Entwickler, technische Schriftsteller und Hugo-Website-Betreiber. Er ist Teil des Hubs Dokumentationswerkzeuge 2026: Markdown, LaTeX, PDF & Druckworkflows.

Was ist Mermaid?

Mermaid ist eine „Diagramm-als-Code“-Syntax. Sie schreiben einen kleinen Textblock, und Mermaid rendert ihn als Diagramm.

Ein grundlegendes Mermaid-Diagramm sieht so aus:

Dieser Code:

```mermaid
flowchart TD
    A[Markdown schreiben] --> B[Mermaid-Block hinzufügen]
    B --> C[Seite rendern]
    C --> D[Diagramm veröffentlichen]
```

Erzeugt dieses Diagramm:

Die wichtige Idee ist einfach: Die Quelle des Diagramms ist reiner Text. Das macht es durchsuchbar, überprüfbar, portabel und leicht mit der Dokumentation, die es erklärt, zu verwalten.

Warum Mermaid in einem technischen Blog verwenden?

Mermaid ist nützlich, wenn Ihr Artikel mehr als nur Fließtext benötigt, aber weniger als ein volles Design-Tool.

Verwenden Sie Mermaid, wenn Sie Folgendes erklären möchten:

• Anfrage- und Antwortflüsse
• Bereitstellungs-Pipelines
• Service-Abhängigkeiten
• Zustandsübergänge
• Datenbankbeziehungen
• Benutzerreisen (User Journeys)
• Build-Schritte
• Entscheidungslogik
• Projekt-Zeitpläne

Ich würde Mermaid nicht für jedes visuelle Element verwenden. Screenshots, handgezeichnete Architekturskizzen und polierte Marketing-Diagramme haben weiterhin ihren Platz. Aber für technische Dokumentation ist Mermaid oft die am besten wartbare Option.

Mermaid Schnellstart

Grundlegende Markdown-Nutzung

In Markdown verwenden Sie einen eingrenzten Codeblock (fenced code block) mit mermaid als Sprache:

```mermaid
flowchart LR
    A[Start] --> B[Prozess]
    B --> C[Fertig]
```

Viele Plattformen verstehen dieses Format direkt. mermaid ist einer der speziellen Sprachidentifikatoren — neben diff, geojson und anderen — den bestimmte Renderer als Blocktyp erster Klasse behandeln, anstatt nur Syntaxhervorhebung anzuwenden. Für eine vollständige Aufschlüsselung der Syntax für eingegrenzte Blöcke und unterstützter Sprachidentifikatoren sehen Sie den Leitfaden zu Markdown-Codeblöcken. Für Hugo hängt die Darstellung von Ihrem Theme oder Ihrer Site-Konfiguration ab. Mehr dazu später.

Diagramme vor der Veröffentlichung testen

Der einfachste Workflow ist:

1. Schreiben Sie das Diagramm in Ihre Markdown-Datei.
2. Fügen Sie es in einen Mermaid-Live-Editor oder eine lokale Vorschau ein.
3. Korrigieren Sie Syntaxfehler.
4. Commiten Sie den Markdown-Quelltext.
5. Prüfen Sie die final gerenderte Seite.

Dies vermeidet das klassische Problem, bei dem ein Diagramm in einem Renderer funktioniert, in einem anderen jedoch aufgrund eines kleinen Syntaxdetails fehlschlägt.

Flussdiagramm-Syntax

Flussdiagramme sind die häufigste Art von Mermaid-Diagrammen. Verwenden Sie sie für Workflows, Algorithmen, Entscheidungsbäume und Systemschritte.

Grundlegendes Flussdiagramm

Dieser Code:

```mermaid
flowchart TD
    A[Benutzer öffnet Website] --> B{Ist Benutzer angemeldet?}
    B -->|Ja| C[Dashboard anzeigen]
    B -->|Nein| D[Login-Seite anzeigen]
```

Erzeugt dieses Diagramm:

Flussdiagramm-Richtungen

Mermaid-Flussdiagramme unterstützen mehrere Richtungen:

TD - von oben nach unten
TB - von oben nach unten
BT - von unten nach oben
LR - von links nach rechts
RL - von rechts nach links

Beispiel:

Dieser Code:

```mermaid
flowchart LR
    Browser --> CDN
    CDN --> WebServer
    WebServer --> Datenbank
```

Erzeugt dieses Diagramm:

Für Blogartikel ist LR (links nach rechts) oft leichter zu lesen für Architekturdiagramme. Für Schritt-für-Schritt-Prozesse ist TD (oben nach unten) in der Regel besser.

Häufige Knotenformen

Dieser Code:

```mermaid
flowchart TD
    A[Rechteck]
    B(Abgerundetes Rechteck)
    C{Entscheidung}
    D((Kreis))
    E[(Datenbank)]
    F[[Subroutine]]
```

Erzeugt dieses Diagramm:

Flussdiagramm-Pfeile

Dieser Code:

```mermaid
flowchart LR
    A --> B
    B --- C
    C -.-> D
    D ==> E
    E -- Beschriftung --> F
```

Erzeugt dieses Diagramm:

Subgraphs

Verwenden Sie Subgraphs, um verwandte Teile eines Systems zu gruppieren.

Dieser Code:

```mermaid
flowchart LR
    subgraph Client
        Browser
    end

    subgraph Backend
        API
        Worker
    end

    subgraph Storage
        DB[(PostgreSQL)]
        Cache[(Redis)]
    end

    Browser --> API
    API --> DB
    API --> Cache
    API --> Worker
```

Erzeugt dieses Diagramm:

Subgraphs sind mächtig, sollten aber mit Bedacht verwendet werden. Ein Diagramm mit sechs Subgraphs und zwanzig Pfeilen ist in der Regel ein Zeichen dafür, dass der Artikel zwei kleinere Diagramme benötigt.

Sequenzdiagramm-Syntax

Sequenzdiagramme zeigen die Kommunikation zwischen Akteuren oder Diensten über die Zeit.

Dieser Code:

```mermaid
sequenceDiagram
    participant User
    participant App
    participant API
    participant DB

    User->>App: Login klicken
    App->>API: POST /login
    API->>DB: Anmeldeinformationen validieren
    DB-->>API: Benutzerdatensatz
    API-->>App: Access Token
    App-->>User: Dashboard anzeigen
```

Erzeugt dieses Diagramm:

Häufige Sequenzpfeile

->      durchgezogene Linie ohne Pfeil
-->     gepunktete Linie ohne Pfeil
->>     durchgezogene Linie mit Pfeil
-->>    gepunktete Linie mit Pfeil
-x      durchgezogene Linie mit Kreuz
--x     gepunktete Linie mit Kreuz

Aktivierungsleisten

Aktivierungsleisten machen klarer, wann ein Teilnehmer Arbeit leistet.

Dieser Code:

```mermaid
sequenceDiagram
    participant Client
    participant Server

    Client->>Server: Daten anfordern
    activate Server
    Server-->>Client: Antwort
    deactivate Server
```

Erzeugt dieses Diagramm:

Alternativen und Bedingungen

Dieser Code:

```mermaid
sequenceDiagram
    participant User
    participant API
    participant Payment

    User->>API: Bestellung aufgeben

    alt Zahlung erfolgreich
        API->>Payment: Karte belasten
        Payment-->>API: Genehmigt
        API-->>User: Bestellung bestätigt
    else Zahlung fehlgeschlagen
        Payment-->>API: Abgelehnt
        API-->>User: Fehler anzeigen
    end
```

Erzeugt dieses Diagramm:

Sequenzdiagramme sind hervorragend für API-Artikel. Sie zeigen nicht nur, welche Komponenten existieren, sondern auch, wie sie miteinander kommunizieren.

Klassendiagramm-Syntax

Klassendiagramme sind nützlich für Domänenmodelle und Objektbeziehungen.

Dieser Code:

```mermaid
classDiagram
    class User {
        +string id
        +string email
        +login()
        +logout()
    }

    class Order {
        +string id
        +float total
        +submit()
    }

    User "1" --> "*" Order
```

Erzeugt dieses Diagramm:

Klassenbeziehungen

<|-- Vererbung
*-- Komposition
o-- Aggregation
--> Assoziation
-- Link
..> Abhängigkeit
..|> Realisierung

Beispiel:

Dieser Code:

```mermaid
classDiagram
    Animal <|-- Dog
    Animal <|-- Cat
    User "1" --> "*" Order
    Order *-- OrderItem
```

Erzeugt dieses Diagramm:

Klassendiagramme können schnell unübersichtlich werden. In einem Blogbeitrag ist ein kleiner Ausschnitt der Domäne einem vollständigen Anwendungsmodell vorzuziehen.

Zustandsdiagramm-Syntax

Zustandsdiagramme erklären, wie sich etwas im Laufe der Zeit ändert.

Dieser Code:

```mermaid
stateDiagram-v2
    [*] --> Entwurf
    Entwurf --> Überprüfung: einreichen
    Überprüfung --> Veröffentlicht: genehmigen
    Überprüfung --> Entwurf: Änderungen anfordern
    Veröffentlicht --> Archiviert: archivieren
    Archiviert --> [*]
```

Erzeugt dieses Diagramm:

Verwenden Sie Zustandsdiagramme für:

• Bestell-Lebenszyklen
• Bereitstellungsstatus
• Authentifizierungsabläufe
• Status von Hintergrundjobs
• Content-Publishing-Workflows

Zustandsdiagramme sind unterschätzt. Sie erklären Geschäftslogik oft besser als ein langer Absatz.

Entity-Relationship-Diagramm-Syntax

Entity-Relationship-Diagramme (ER-Diagramme) sind nützlich für Datenbankmodelle.

Dieser Code:

```mermaid
erDiagram
    USER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_ITEM : contains
    PRODUCT ||--o{ ORDER_ITEM : appears_in

    USER {
        string id
        string email
    }

    ORDER {
        string id
        datetime created_at
    }

    PRODUCT {
        string id
        string name
    }
```

Erzeugt dieses Diagramm:

ER-Beziehungsmarker

||  genau eins
o|  null oder eins
}|  eines oder mehrere
}o  null oder mehrere

ER-Diagramme sind am besten, wenn sie Beziehungen erklären, nicht jede Spalte. Halten Sie Implementierungsdetails in Migrationen oder Schema-Dokumenten.

Gantt-Diagramm-Syntax

Gantt-Diagramme sind nützlich für Projektzeitpläne.

Dieser Code:

```mermaid
gantt
    title Dokumentationsmigrationsplan
    dateFormat  YYYY-MM-DD

    section Planung
    Audit der aktuellen Docs      :a1, 2026-06-01, 5d
    Struktur definieren           :a2, nach a1, 3d

    section Schreiben
    Leitfäden neu schreiben       :b1, nach a2, 10d
    Überprüfung und Veröffentlichung :b2, nach b1, 4d
```

Erzeugt dieses Diagramm:

Gantt-Diagramme sind hilfreich in internen Planungsbeiträgen, können aber schnell veralten. Verwenden Sie sie, wenn der Zeitplan selbst der Kernpunkt ist.

Zeitachsen-Syntax

Zeitachsen sind gut für Release-Historien, Incident-Writeups und Projektzusammenfassungen.

Dieser Code:

```mermaid
timeline
    title API-Entwicklung
    2024 : REST API gestartet
    2025 : Webhooks hinzugefügt
    2026 : Event Streaming eingeführt
```

Erzeugt dieses Diagramm:

Verwenden Sie eine Zeitachse, wenn die Reihenfolge wichtiger ist als die Abhängigkeit. Wenn es Ihnen um die Abfolge von Ereignissen geht, eher als um deren kausale Verknüpfung, hält eine Zeitachse den Fokus dort, wo er hingehört, und bleibt auf den ersten Blick leicht zu lesen.

Kreisdiagramm-Syntax

Kreisdiagramme werden unterstützt, seien Sie jedoch vorsichtig. Sie sind leicht zu lesen, wenn es nur wenige Kategorien gibt und die Werte deutlich unterschiedlich sind.

Dieser Code:

```mermaid
pie title Build-Zeit nach Schritt
    "Abhängigkeiten installieren" : 35
    "Tests ausführen" : 45
    "Assets bauen" : 20
```

Erzeugt dieses Diagramm:

Persönliche Empfehlung: Wenn die Werte ähnlich sind oder es mehr als fünf Kategorien gibt, verwenden Sie stattdessen eine Tabelle. Eine gut formatierte Tabelle kommuniziert präzise Zahlen ehrlicher als ein Kreisdiagramm, bei dem die Sektoren nahezu identisch aussehen.

Git-Graph-Syntax

Git-Graphen können Branching-Strategien und Release-Flüsse erklären.

Dieser Code:

```mermaid
gitGraph
    commit
    branch feature
    checkout feature
    commit
    commit
    checkout main
    merge feature
    commit
```

Erzeugt dieses Diagramm:

Dies ist nützlich für Artikel über Git-Workflows, trunk-basierte Entwicklung, Release-Branches und Hotfixes. Wenn Sie eine schnelle Referenz für die zugrunde liegenden Branching-Befehle benötigen, deckt das GIT Cheat Sheet die häufigsten Befehle neben Merge- und Rebase-Workflows ab.

Mermaid Cheat Sheet

Diagrammtypen

flowchart TD
sequenceDiagram
classDiagram
stateDiagram-v2
erDiagram
gantt
timeline
pie
gitGraph
mindmap
journey

Flussdiagramm-Grundlagen

flowchart TD
A[Text] --> B[Text]
A -->|Beschriftung| B
A -.-> B
A ==> B
A --- B

Flussdiagramm-Formen

A[Rechteck]
A(Abgerundet)
A{Entscheidung}
A((Kreis))
A[(Datenbank)]
A[[Subroutine]]
A>Flagge]

Sequenzdiagramm-Grundlagen

sequenceDiagram
participant A
participant B
A->>B: Nachricht
B-->>A: Antwort
activate B
deactivate B

Sequenzblöcke

alt Bedingung
else andere Bedingung
end

opt optionaler Schritt
end

loop jedes Element
end

par parallele Aufgabe
and andere Aufgabe
end

Klassendiagramm-Grundlagen

classDiagram
class User
class Order
User --> Order
User "1" --> "*" Order

Zustandsdiagramm-Grundlagen

stateDiagram-v2
[*] --> Idle
Idle --> Running
Running --> Done
Done --> [*]

ER-Diagramm-Grundlagen

erDiagram
USER ||--o{ ORDER : places
ORDER ||--|{ ORDER_ITEM : contains

Kommentare

Mermaid unterstützt Kommentare mit %%.

Dieser Code:

```mermaid
flowchart TD
    %% Das ist ein Kommentar
    A --> B
```

Erzeugt dieses Diagramm:

Mermaid in Hugo verwenden

Hugo-Inhalte werden in der Regel in Markdown geschrieben, daher passt Mermaid natürlich in einen auf Hugo basierenden technischen Blog. Das genaue Setup hängt von Ihrem Theme und Ihrer Markdown-Rendering-Konfiguration ab.

Das gängige Authoring-Muster ist immer noch dasselbe:

```mermaid
flowchart LR
    Markdown --> Hugo
    Hugo --> HTML
    HTML --> Browser
```

Wenn Ihr Hugo-Theme Mermaid bereits unterstützt, kann dies ohne zusätzlichen Aufwand gerendert werden. Wenn nicht, benötigen Sie in der Regel einen Render-Hook, einen Shortcode, ein Partial oder eine Theme-Konfiguration, die Mermaid auf Seiten lädt, die Mermaid-Diagramme enthalten.

Ein praktisches Hugo-Setup sollte diese Regeln anstreben:

• Halten Sie Mermaid-Quellen innerhalb normaler Markdown-Artikel.
• Laden Sie Mermaid nur auf Seiten, die es benötigen.
• Vermeiden Sie globales JavaScript, wenn die meisten Seiten keine Diagramme verwenden.
• Testen Sie Diagramme während der lokalen Vorschau.
• Halten Sie die Diagrammquelle in Git lesbar.

Für einen technischen Blog sind eingegrenzte Codeblöcke in der Regel besser als benutzerdefinierte Shortcodes, da sie portabler sind. Wenn Sie Inhalte später zu GitHub, einem anderen statischen Site-Generator oder einer Dokumentationsplattform verschieben, sind standardisierte Mermaid-Blöcke leichter wiederverwendbar.

Mermaid Best Practices

Diagramme klein halten

Ein Diagramm sollte den Artikel klären, nicht ersetzen. Wenn Leser zoomen müssen, ist das Diagramm wahrscheinlich zu groß.

Gute Diagramme haben in der Regel:

• Eine Idee
• Klare Richtung
• Kurze Beschriftungen
• Wenige kreuzende Linien
• Konsistente Benennung

Bevorzugen Sie mehrere kleine Diagramme

Verwenden Sie statt einem riesigen Systemdiagramm mehrere fokussierte Diagramme:

• Anfragefluss
• Deployment-Topologie
• Datenmodell
• Zustands-Lebenszyklus
• Fehlerpfad

Das ist besser für die Leser und besser für mobile Bildschirme.

Verwenden Sie stabile Namen

Verwenden Sie Namen, die mit Ihrem Code, Ihrer API oder Dokumentation übereinstimmen. Nennen Sie dieselbe Sache nicht in verschiedenen Diagrammen API, Backend und Server, es sei denn, es handelt sich um wirklich unterschiedliche Konzepte.

Beschriften Sie wichtige Pfeile

Unbeschriftete Pfeile sind bei einfachen Flussdiagrammen in Ordnung. In Systemdiagrammen sind Beschriftungen oft wichtig.

Dieser Code:

```mermaid
flowchart LR
    Web -->|HTTPS-Anfrage| API
    API -->|SQL-Abfrage| DB
    API -->|Ereignis veröffentlichen| Queue
```

Erzeugt dieses Diagramm:

Vermeiden Sie „clevere“ Syntax

Mermaid kann viele Dinge. Das bedeutet nicht, dass jeder Artikel sie alle benötigt. Bevorzugen Sie eine Syntax, die ein zukünftiger Maintainer schnell verstehen kann.

Zitieren Sie Beschriftungen bei Bedarf

Wenn eine Beschriftung Zeichen enthält, die Mermaid verwirren, umschließen Sie sie mit Anführungszeichen.

Dieser Code:

```mermaid
flowchart TD
    A["Benutzer klickt auf /checkout"] --> B["POST /api/orders"]
```

Erzeugt dieses Diagramm:

Das ist eine kleine Gewohnheit, die lästige Rendering-Fehler verhindert.

Denken Sie an den Dark Mode

Viele Hugo-Sites unterstützen den Dark Mode. Stellen Sie sicher, dass Ihr Mermaid-Theme oder Ihre Site-CSS-Datei die Diagramme sowohl im hellen als auch im dunklen Erscheinungsbild lesbar hält.

Häufige Mermaid-Fehler

Fehler 1: Zu viele Details

Schlechte Mermaid-Diagramme versuchen oft, jeden Edge-Case zu zeigen. Das macht sie technisch vollständig und praktisch unlesbar. Die Lösung ist fast immer dieselbe: Teilen Sie das Diagramm in zwei oder drei kleinere auf, von denen jeder einen Aspekt abdeckt, sodass Leser die Logik nachverfolgen können, ohne ein Dutzend kreuzender Pfeile verfolgen zu müssen.

Fehler 2: Lange Beschriftungen

Lange Beschriftungen erzeugen breite Boxen und hässliche Layouts.

Statt diesem Code:

```mermaid
flowchart TD
    A[Der Benutzer sendet das Registrierungsformular mit seiner E-Mail-Adresse und seinem Passwort]
```

Erzeugt dieses Diagramm:

Bevorzugen Sie diesen Code:

```mermaid
flowchart TD
    A[Registrierungsformular absenden]
```

Erzeugt dieses Diagramm:

Erklären Sie Details im Absatz unter dem Diagramm.

Fehler 3: Unklare Richtung

Wählen Sie eine Richtung und bleiben Sie dabei. Die meisten Prozessdiagramme sollten TD verwenden. Die meisten Architekturdiagramme sind mit LR leichter zu verstehen.

Fehler 4: Mermaid als Design-Tool behandeln

Mermaid ist kein Figma. Es ist nicht für pixelperfekte Diagramme gedacht, und der Versuch, es in diese Rolle zu zwängen, führt nur zu Frustration. Seine Stärke liegt in der Wartbarkeit, nicht in visueller Perfektion — und dieser Trade-off ist beabsichtigt.

Mermaid SEO-Tipps für technische Blogs

Mermaid-Diagramme können technische Artikel nützlicher machen, aber Suchmaschinen benötigen weiterhin Text. Verlassen Sie sich nicht nur auf Diagramme.

Für SEO-freundliche Mermaid-Artikel:

• Verwenden Sie beschreibende H2- und H3-Überschriften.
• Erklären Sie jedes Diagramm im benachbarten Text.
• Integrieren Sie wichtige Keywords in den normalen Fließtext.
• Halten Sie Codebeispiele kopierbar.
• Fügen Sie unter komplexen Diagrammen eine Erklärung im Stil von Alt-Text hinzu.
• Verwenden Sie prägnante Titel und Beschreibungen im Front Matter.
• Vermeiden Sie es, die gesamte Bedeutung im gerenderten SVG zu verstecken.

Ein Mermaid-Diagramm sollte den Artikel unterstützen. Es sollte nicht der einzige Ort sein, an dem wichtige Informationen existieren.

Copy-Paste Mermaid-Beispiele

API-Anfragefluss

Dieser Code:

```mermaid
sequenceDiagram
    participant Client
    participant API
    participant Auth
    participant DB

    Client->>API: GET /account
    API->>Auth: Token validieren
    Auth-->>API: Token gültig
    API->>DB: Konto laden
    DB-->>API: Kontodaten
    API-->>Client: 200 OK
```

Erzeugt dieses Diagramm:

CI-Pipeline

Dieser Code:

```mermaid
flowchart TD
    A[Commit pushen] --> B[Abhängigkeiten installieren]
    B --> C[Lint ausführen]
    C --> D[Tests ausführen]
    D --> E[Site bauen]
    E --> F[Deployen]
```

Erzeugt dieses Diagramm:

Dieses Muster bildet sich natürlich auf eine echte CI-Konfiguration ab. Für die Schritt-für-Schritt-Syntax von GitHub Actions-Workflows ist das GitHub Actions Cheat Sheet ein hilfreicher Begleiter, wenn Sie das obige Diagramm in eine funktionierende Pipeline umwandeln möchten.

Publishing-Workflow

Dieser Code:

```mermaid
stateDiagram-v2
    [*] --> Entwurf
    Entwurf --> Bearbeitung
    Bearbeitung --> Überprüfung
    Überprüfung --> Veröffentlicht
    Überprüfung --> Bearbeitung
    Veröffentlicht --> [*]
```

Erzeugt dieses Diagramm:

Einfaches Datenmodell

Dieser Code:

```mermaid
erDiagram
    AUTHOR ||--o{ POST : writes
    POST ||--o{ COMMENT : receives

    AUTHOR {
        string id
        string name
    }

    POST {
        string id
        string title
        datetime published_at
    }

    COMMENT {
        string id
        string body
    }
```

Erzeugt dieses Diagramm:

Wann man Mermaid nicht verwenden sollte

Verwenden Sie Mermaid nicht, wenn:

• Das Diagramm ein präzises visuelles Layout benötigt.
• Das Design exakt einem Branding-System entsprechen muss.
• Das visuelle Element hauptsächlich dekorativ ist.
• Das Diagramm zu viele Knoten zum Lesen hat.
• Ein Screenshot den Punkt besser erklären würde.
• Der Inhalt sich selten ändert und mehr Politur als Wartbarkeit benötigt.

Mermaid ist hervorragend für lebendige technische Dokumentation. Es ist weniger gut für Präsentationskunstwerke. Für diagrammatische Darstellungen in Druck- oder PDF-Kontexten bietet LaTeX Pakete wie TikZ und pgfplots, die Ihnen eine viel größere Layoutkontrolle geben — das LaTeX Cheat Sheet deckt die Diagrammeinbindung neben dem restlichen LaTeX-Toolkit ab.

Abschließende Gedanken

Mermaid ist eines der besten Tools für das technische Bloggen, weil es respektiert, wie Entwickler bereits arbeiten: Textdateien, Markdown, Git, Code Review und wiederholbare Builds. Für alles rund um die Diagramme — Überschriften, Listen, Tabellen, Codeblöcke — ist das Markdown Cheat Sheet die schnelle Referenz, die Sie neben diesem Leitfaden aufbewahren sollten.

Die besten Mermaid-Diagramme sind nicht die komplexesten. Sie sind die Diagramme, die ein Konzept offensichtlich machen und sechs Monate später noch leicht zu bearbeiten sind.

Verwenden Sie Mermaid für die Diagramme, die mit Ihrer Dokumentation leben sollen. Halten Sie sie klein, halten Sie sie lesbar und behandeln Sie sie als Teil des Quellcodes Ihres Artikels.