diff --git a/.vitepress/config.ts b/.vitepress/config.ts
index 72dd5194..7ade2a08 100644
--- a/.vitepress/config.ts
+++ b/.vitepress/config.ts
@@ -807,6 +807,11 @@ export default ({ mode }: { mode: string }) => {
                 link: '/guide/browser/trace-view',
                 docFooterText: '追踪查看器 | 浏览器模式',
               },
+              {
+                text: 'ARIA Snapshots',
+                link: '/guide/browser/aria-snapshots',
+                docFooterText: 'ARIA Snapshots | Browser Mode',
+              },
             ],
           },
           {
diff --git a/api/expect.md b/api/expect.md
index 418fee79..4a62783e 100644
--- a/api/expect.md
+++ b/api/expect.md
@@ -1011,6 +1011,43 @@ it('render basic', async () => {
 - **类型:** `(snapshot?: string, hint?: string) => void`
 
 与 [`toMatchInlineSnapshot`](#tomatchinlinesnapshot) 类似，但期望的值与 [`toThrow`](#toThrow) 相同。
+<!-- TODO: translation -->
+## toMatchAriaSnapshot <Version type="experimental">4.1.4</Version> <Experimental /> {#tomatcharisnapshot}
+
+- **Type:** `() => void`
+
+Captures the accessibility tree of a DOM element and generate a snapshot file or compares it against a stored snapshot. See the [ARIA Snapshots guide](/guide/browser/aria-snapshots) for more details.
+
+```ts
+import { expect, test } from 'vitest'
+
+test('navigation accessibility', () => {
+  document.body.innerHTML = `
+    <nav aria-label="Actions">
+      <button>Save</button>
+      <button>Cancel</button>
+    </nav>
+  `
+  expect(document.querySelector('nav')).toMatchAriaSnapshot()
+})
+```
+
+## toMatchAriaInlineSnapshot <Version type="experimental">4.1.4</Version> <Experimental /> {#tomatchariainlinesnapshot}
+
+- **Type:** `(snapshot?: string) => void`
+
+Same as [`toMatchAriaSnapshot`](#tomatcharisnapshot), but stores the snapshot inline in the test file. See the [ARIA Snapshots guide](/guide/browser/aria-snapshots) for more details.
+
+```ts
+import { expect, test } from 'vitest'
+
+test('user profile', () => {
+  expect(document.body).toMatchAriaInlineSnapshot(`
+    - heading "Dashboard" [level=1]
+    - button /User \\d+/: Profile
+  `)
+})
+```
 
 ## toHaveBeenCalled
 
diff --git a/guide/browser/aria-snapshots.md b/guide/browser/aria-snapshots.md
new file mode 100644
index 00000000..1867e963
--- /dev/null
+++ b/guide/browser/aria-snapshots.md
@@ -0,0 +1,475 @@
+---
+title: ARIA Snapshots | Guide
+outline: deep
+---
+<!-- TODO: translation -->
+# ARIA Snapshots <Badge type="warning">experimental</Badge> <Version>4.1.4</Version>
+
+ARIA snapshots let you test the accessibility structure of your pages. Instead of asserting against raw HTML or visual output, you assert against the accessibility tree — the same structure that screen readers and other assistive technologies use.
+
+Given this HTML:
+
+```html
+<nav aria-label="Main">
+  <a href="/">Home</a>
+  <a href="/about">About</a>
+</nav>
+```
+
+You can assert its accessibility tree:
+
+```ts
+await expect.element(page.getByRole('navigation')).toMatchAriaInlineSnapshot(`
+  - navigation "Main":
+    - link "Home":
+      - /url: /
+    - link "About":
+      - /url: /about
+`)
+```
+
+This catches accessibility regressions: missing labels, broken roles, incorrect heading levels, and more — things that DOM snapshots would miss. Even if the underlying HTML structure changes, the assertion would not fail as long as content matches semantically.
+
+## Snapshot Workflow
+
+ARIA snapshots use the same Vitest snapshot workflow as other snapshot assertions. File snapshots, inline snapshots, `--update` / `-u`, watch mode updates, and CI snapshot behavior all work the same way.
+
+See the main [Snapshot guide](/guide/snapshot) for the general snapshot workflow, update behavior, and review guidelines.
+
+## Basic Usage
+
+Given a page with this HTML:
+
+```html
+<form aria-label="Log In">
+  <input aria-label="Email" />
+  <input aria-label="Password" type="password" />
+  <button>Submit</button>
+</form>
+```
+
+### File Snapshots
+
+Use `toMatchAriaSnapshot()` to store the snapshot in a `.snap` file alongside your test:
+
+```ts [basic.test.ts]
+import { expect, test } from 'vitest'
+
+test('login form', async () => {
+  await expect.element(page.getByRole('form')).toMatchAriaSnapshot()
+})
+```
+
+On first run, Vitest generates a snapshot file entry:
+
+```js [__snapshots__/basic.test.ts.snap]
+// Vitest Snapshot ...
+
+exports[`login form 1`] = `
+- form "Log In":
+  - textbox "Email"
+  - textbox "Password"
+  - button "Submit"
+`
+```
+
+### Inline Snapshots
+
+Use `toMatchAriaInlineSnapshot()` to store the snapshot directly in the test file:
+
+```ts
+import { expect, test } from 'vitest'
+
+test('login form', async () => {
+  await expect.element(page.getByRole('form')).toMatchAriaInlineSnapshot(`
+    - form "Log In":
+      - textbox "Email"
+      - textbox "Password"
+      - button "Submit"
+  `)
+})
+```
+
+## Browser Mode Retry Behavior
+
+In [Browser Mode](/guide/browser/), `expect.element()` polls the DOM and waits for the accessibility tree to **stabilize** before evaluating the result. On each poll, the matcher re-queries the element and re-captures the accessibility tree. The snapshot is considered stable when two consecutive polls produce the same output.
+
+```ts
+await expect.element(page.getByRole('form')).toMatchAriaInlineSnapshot(`
+  - form "Log In":
+    - textbox "Email"
+    - textbox "Password"
+    - button "Submit"
+`)
+```
+
+On first run or with `--update`, the stable result is written as the new snapshot.
+
+When an existing snapshot is present, the matcher also checks whether the stable result matches. If it does not, polling resets and continues — giving the DOM time to reach the expected state. This handles cases like animations, async rendering, or delayed state updates where the tree may briefly stabilize in an intermediate state before settling into its final form.
+
+## Preserving Hand-Edited Patterns
+
+When you hand-edit a snapshot to use regex patterns, those patterns survive `--update`. Only the literal parts that changed are overwritten. This lets you write flexible assertions that don't break when content changes.
+
+### Example
+
+**Step 1.** Your shopping cart page renders this HTML:
+
+```html
+<h1>Your Cart</h1>
+<ul aria-label="Cart Items">
+  <li>Wireless Headphones — $79.99</li>
+</ul>
+<button>Checkout</button>
+```
+
+You run your test for the first time with `--update`. Vitest generates the snapshot:
+
+```yaml
+- heading "Your Cart" [level=1]
+- list "Cart Items":
+    - listitem: Wireless Headphones — $79.99
+- button "Checkout"
+```
+
+**Step 2.** The item names and prices are seeded test data that may change. You hand-edit those lines to regex patterns, but keep the stable structure as literals:
+
+```yaml
+- heading "Your Cart" [level=1]
+- list "Cart Items":
+    - listitem: /.+ — \$\d+\.\d+/
+- button "Checkout"
+```
+
+**Step 3.** Later, a developer renames the button from "Checkout" to "Place Order". Running `--update` updates that literal but preserves your regex patterns:
+
+```yaml
+- heading "Your Cart" [level=1]
+- list "Cart Items":
+    - listitem: /.+ — \$\d+\.\d+/
+- button "Place Order"   👈 New snapshot updated with new string
+```
+
+The regex patterns you wrote in step 2 are preserved because they still match the actual content. Only the mismatched literal "Checkout" was updated to "Place Order".
+
+## Snapshot Format
+
+ARIA snapshots use a YAML-like syntax. Each line represents a node in the accessibility tree.
+
+::: info
+ARIA snapshot templates use a **subset of YAML** syntax. Only the features needed for accessibility trees are supported: scalar values, nested mappings via indentation, and sequences (`- item`). Advanced YAML features like anchors, tags, flow collections, and multi-line scalars are not supported.
+
+Captured text is also whitespace-normalized before it is rendered into the snapshot. Newlines, `<br>` line breaks, tabs, and repeated whitespace collapse to single spaces, so multi-line DOM text is emitted as a single-line snapshot value.
+:::
+
+Each accessible element in the tree is represented as a YAML node:
+
+```yaml
+- role "name" [attribute=value]
+```
+
+- `role`: The ARIA role of the element, such as `heading`, `list`, `listitem`, or `button`
+- `"name"`: The [accessible name](https://w3c.github.io/accname/), when present. Quoted strings match exact values, and `/patterns/` match regular expressions
+- `[attribute=value]`: Accessibility states and properties such as `checked`, `disabled`, `expanded`, `level`, `pressed`, or `selected`
+
+These values come from ARIA attributes and the browser's accessibility tree, including semantics inferred from native HTML elements.
+
+Because ARIA snapshots reflect the browser's accessibility tree, content excluded from that tree, such as `aria-hidden="true"` or `display: none`, does not appear in the snapshot.
+
+### Roles and Accessible Names
+
+For example:
+
+```html
+<button>Submit</button>
+<h1>Welcome</h1>
+<a href="/">Home</a>
+<input aria-label="Email" />
+```
+
+```yaml
+- button "Submit"
+- heading "Welcome" [level=1]
+- link "Home"
+- textbox "Email"
+```
+
+The role usually comes from the element's native semantics, though it can also be defined with ARIA. The accessible name is computed from text content, associated labels, `aria-label`, `aria-labelledby`, and related naming rules.
+
+For a closer look at how names are computed, see [Accessible Name and Description Computation](https://w3c.github.io/accname/).
+
+Some content appears in the snapshot as a text node instead of a role-based element:
+
+```html
+<span>Hello world</span>
+```
+
+```yaml
+- text: Hello world
+```
+
+Text values are always serialized on a single line after whitespace normalization. For example:
+
+```html
+<p>
+Line 1
+Line 2<br />Line 3
+Line 4
+</p>
+```
+
+```yaml
+- paragraph: Line 1 Line 2 Line 3 Line 4
+```
+
+### Children
+
+Child elements appear nested under their parent:
+
+```html
+<ul>
+  <li>First</li>
+  <li>Second</li>
+  <li>Third</li>
+</ul>
+```
+
+```yaml
+- list:
+    - listitem: First
+    - listitem: Second
+    - listitem: Third
+```
+
+If the parent has an accessible name, the snapshot includes it before the nested children:
+
+```html
+<nav aria-label="Main">
+  <a href="/">Home</a>
+  <a href="/about">About</a>
+</nav>
+```
+
+```yaml
+- navigation "Main":
+    - link "Home"
+    - link "About"
+```
+
+If an element only contains a single text child and has no other properties, the text is rendered inline:
+
+```html
+<p>Hello world</p>
+```
+
+```yaml
+- paragraph: Hello world
+```
+
+### Attributes
+
+ARIA states and properties appear in brackets:
+
+| HTML                                                                   | Snapshot                                  |
+| ---------------------------------------------------------------------- | ----------------------------------------- |
+| `<input type="checkbox" checked aria-label="Agree">`                   | `- checkbox "Agree" [checked]`            |
+| `<input type="checkbox" aria-checked="mixed" aria-label="Select all">` | `- checkbox "Select all" [checked=mixed]` |
+| `<button aria-disabled="true">Submit</button>`                         | `- button "Submit" [disabled]`            |
+| `<button aria-expanded="true">Menu</button>`                           | `- button "Menu" [expanded]`              |
+| `<h2>Title</h2>`                                                       | `- heading "Title" [level=2]`             |
+| `<button aria-pressed="true">Bold</button>`                            | `- button "Bold" [pressed]`               |
+| `<button aria-pressed="mixed">Bold</button>`                           | `- button "Bold" [pressed=mixed]`         |
+| `<option selected>English</option>`                                    | `- option "English" [selected]`           |
+
+Attributes only appear when they are active. A button that is not disabled simply has no `[disabled]` attribute — there is no `[disabled=false]`.
+
+### Pseudo-Attributes
+
+Some DOM properties that aren't part of ARIA but are useful for testing are exposed with a `/` prefix:
+
+#### `/url:`
+
+Links include their URL:
+
+```html
+<a href="/">Home</a>
+```
+
+```yaml
+- link "Home":
+    - /url: /
+```
+
+#### `/placeholder:`
+
+Textboxes can include their placeholder text:
+
+```html
+<input aria-label="Email" placeholder="user@example.com" />
+```
+
+```yaml
+- textbox "Email":
+    - /placeholder: user@example.com
+```
+
+::: tip When does `/placeholder:` appear?
+
+The `/placeholder:` pseudo-attribute only appears when the placeholder text is **different from the accessible name**. When an input has a placeholder but no `aria-label` or associated `<label>`, the browser uses the placeholder as the accessible name. In that case, the placeholder information is already in the name and is not duplicated.
+
+- When placeholder is the accessible name:
+
+```html
+<input placeholder="Search" />
+```
+
+```yaml
+- textbox "Search"
+```
+
+- When placeholder differs from the accessible name:
+
+```html
+<input placeholder="Search" aria-label="Search products" />
+```
+
+```yaml
+- textbox "Search products":
+    - /placeholder: Search
+```
+
+:::
+
+## Matching
+
+### Regular Expressions
+
+Use regex patterns to match names flexibly:
+
+```html
+<h1>Welcome, Alice</h1>
+<a href="https://example.com/profile/123">Profile</a>
+```
+
+```yaml
+- heading /Welcome, .*/
+- link "Profile":
+    - /url: /https:\/\/example\.com\/.*/
+```
+
+Regex also works in pseudo-attribute values:
+
+```html
+<input aria-label="Search" placeholder="Type to search..." />
+```
+
+```yaml
+- textbox "Search":
+    - /placeholder: /Type .*/
+```
+
+::: warning Escaping backslashes in regex patterns
+Snapshots are stored as JavaScript strings — in backtick-delimited template literals for inline snapshots and in `.snap` files. Because of this, backslashes need to be **doubled** when you hand-edit a snapshot to add a regex pattern.
+
+For example, to match one or more digits with `\d+`:
+
+```ts
+// ✅ Correct — double backslash
+await expect.element(button).toMatchAriaInlineSnapshot(`
+  - button: /item \\d+/
+`)
+
+// ❌ Wrong — single backslash is consumed by JS, regex sees "d+" instead of "\d+"
+await expect.element(button).toMatchAriaInlineSnapshot(`
+  - button: /item \d+/
+`)
+```
+
+This applies to both inline snapshots and `.snap` files. When Vitest **auto-generates** or **updates** a snapshot, escaping is handled automatically — you only need to worry about this when hand-editing regex patterns.
+:::
+
+### Child Matching
+
+The `/children` directive controls how a node's children are compared against the template. There are three modes:
+
+#### Partial Matching (default)
+
+By default (no `/children` directive), templates use **contain** semantics — extra children in the actual tree are allowed as long as all template children appear as an ordered subsequence. This is the same as `/children: contain`.
+
+```html
+<main>
+  <h1>Welcome</h1>
+  <p>Some intro text</p>
+  <button>Get Started</button>
+</main>
+```
+
+```ts
+// This passes — the template children are a subset of the actual children
+await expect.element(page.getByRole('main')).toMatchAriaInlineSnapshot(`
+  - main:
+    - heading "Welcome" [level=1]
+`)
+```
+
+This is useful for focused, resilient tests that don't break when unrelated content is added.
+
+#### Exact Matching (`/children: equal`)
+
+Requires that the node's immediate children match the template exactly — same count, same order. No extra children are allowed at this level.
+
+```html
+<ul aria-label="Features">
+  <li>Feature A</li>
+  <li>Feature B</li>
+  <li>Feature C</li>
+</ul>
+```
+
+```ts
+// This FAILS — the list has 3 items but the template only lists 2
+await expect.element(page.getByRole('list')).toMatchAriaInlineSnapshot(`
+  - list "Features":
+    - /children: equal
+    - listitem: Feature A
+    - listitem: Feature B
+`)
+```
+
+```ts
+// This PASSES — all 3 items are listed
+await expect.element(page.getByRole('list')).toMatchAriaInlineSnapshot(`
+  - list "Features":
+    - /children: equal
+    - listitem: Feature A
+    - listitem: Feature B
+    - listitem: Feature C
+`)
+```
+
+The strict matching only applies at the level where `/children` is placed. Descendants of each `listitem` still use the default contain semantics.
+
+#### Deep Exact Matching (`/children: deep-equal`)
+
+Like `equal`, but the strict matching **propagates to all descendants**. Every level of nesting must match exactly — same count, same order, no extra nodes at any depth.
+
+```ts
+await expect.element(page.getByRole('navigation')).toMatchAriaInlineSnapshot(`
+  - navigation "Main":
+    - /children: deep-equal
+    - link "Home":
+      - /url: /
+    - link "About":
+      - /url: /about
+`)
+```
+
+With `deep-equal`, every child of each `link` must also match exactly. If a link had an extra child node not listed in the template, the assertion would fail.
+
+#### Comparison
+
+| Mode | Directive | Behavior |
+| --- | --- | --- |
+| Partial | _(default)_ or `/children: contain` | Template children are an ordered subsequence — extra actual children are ignored |
+| Exact | `/children: equal` | Immediate children must match exactly; descendants still use partial matching |
+| Deep exact | `/children: deep-equal` | All children at every depth must match exactly |
diff --git a/guide/reporters.md b/guide/reporters.md
index 04bfd451..b6d7ed23 100644
--- a/guide/reporters.md
+++ b/guide/reporters.md
@@ -421,9 +421,22 @@ JSON 报告示例:
 ```
 
 ::: info
-自Vitest 3起，如果启用了代码覆盖率功能，JSON 报告器会在 `coverageMap` 中包含覆盖率信息。
+自Vitest 3 起，如果启用了代码覆盖率功能，JSON 报告器会在 `coverageMap` 中包含覆盖率信息。
 :::
+<!-- TODO: translation -->
+The `meta` field in each assertion result can be filtered via the `filterMeta` reporter option. It receives the key and value of each field and should return a falsy value to exclude the field from the report:
 
+```ts
+export default defineConfig({
+  test: {
+    reporters: [
+      ['json', {
+        filterMeta: (key, value) => key !== 'internalField',
+      }]
+    ]
+  },
+})
+```
 ### HTML 报告器 {#html-reporter}
 
 生成 HTML 文件，通过交互式 [GUI](/guide/ui) 查看测试结果。文件生成后，Vitest 将保持本地开发服务器运行，并提供一个链接，以便在浏览器中查看报告。
diff --git a/guide/snapshot.md b/guide/snapshot.md
index daf58bc5..14477b13 100644
--- a/guide/snapshot.md
+++ b/guide/snapshot.md
@@ -123,6 +123,38 @@ test('button looks correct', async () => {
 ```
 
 它会捕获屏幕截图并与参考图像进行比较，以检测意外的视觉变化。在 [视觉回归测试指南](/guide/browser/visual-regression-testing)中了解更多内容。
+<!-- TODO: translation -->
+## ARIA Snapshots <Badge type="warning">experimental</Badge> <Version>4.1.4</Version>
+
+ARIA snapshots capture the accessibility tree of a DOM element and compare it against a stored template. Based on [Playwright's ARIA snapshots](https://playwright.dev/docs/aria-snapshots), they provide a semantic alternative to visual regression testing — asserting structure and meaning rather than pixels.
+
+For example, given this HTML:
+
+```html
+<nav aria-label="Main">
+  <a href="/">Home</a>
+  <a href="/about">About</a>
+</nav>
+```
+
+You can assert its accessibility tree:
+
+```ts
+import { expect, test } from 'vitest'
+import { page } from 'vitest/browser'
+
+test('navigation structure', async () => {
+  await expect.element(page.getByRole('navigation')).toMatchAriaInlineSnapshot(`
+    - navigation "Main":
+      - link "Home":
+        - /url: /
+      - link "About":
+        - /url: /about
+  `)
+})
+```
+
+See the dedicated [ARIA Snapshots guide](/guide/browser/aria-snapshots) for syntax details, retry behavior in Browser Mode, and file vs. inline snapshot examples. See [`toMatchAriaSnapshot`](/api/expect#tomatcharisnapshot) and [`toMatchAriaInlineSnapshot`](/api/expect#tomatchariainlinesnapshot) for the full API reference.
 
 ## 自定义序列化器 {#custom-serializer}
 
@@ -254,6 +286,26 @@ For inline snapshot matchers, the snapshot argument must be the last parameter (
 File snapshot matchers must be `async` — `toMatchFileSnapshot` returns a `Promise`. Remember to `await` the result in the matcher and in your test.
 :::
 
+::: warning
+When custom inline snapshot matcher is aynchronous, Vitest cannot automatically infer the call location for inline snapshot rewriting. You must capture the call site by setting the `'error'` flag on the chai assertion object:
+
+```ts
+import { expect, chai, Snapshots } from 'vitest'
+
+const { toMatchInlineSnapshot } = Snapshots
+
+expect.extend({
+  async toMatchTransformedInlineSnapshot(received: string, inlineSnapshot?: string) {
+    // capture call site synchronously at the top of matcher implementation
+    chai.util.flag(this.assertion, 'error', new Error())
+    const transformed = await transform(received)
+    return toMatchInlineSnapshot.call(this, transformed, inlineSnapshot)
+  },
+})
+```
+
+:::
+
 For TypeScript, extend the `Assertion` interface:
 
 ```ts
@@ -271,6 +323,192 @@ declare module 'vitest' {
 ::: tip
 See [Extending Matchers](/guide/extending-matchers) for more on `expect.extend` and custom matcher conventions.
 :::
+<!-- TODO: translation -->
+## Custom Snapshot Domain <Badge type="warning">experimental</Badge> <Version>4.1.4</Version> {#custom-snapshot-domain}
+
+Custom serializers control how values are _rendered_ into snapshot strings, but comparison is still string equality. A **domain snapshot adapter** goes further: it owns the entire comparison pipeline for a custom matcher, including how to capture a value, render it, parse a stored snapshot, and match them semantically.
+
+### The adapter interface
+
+A domain adapter implements four methods and is generic over two types — `Captured` (what the value actually is) and `Expected` (what the stored snapshot parses into):
+
+```ts
+import type { DomainMatchResult, DomainSnapshotAdapter } from '@vitest/snapshot'
+
+const myAdapter: DomainSnapshotAdapter<Captured, Expected> = {
+  name: 'my-domain',
+
+  // Extract structured data from the received value
+  capture(received: unknown): Captured { /* ... */ },
+
+  // Render captured data as the snapshot string (what gets stored)
+  render(captured: Captured): string { /* ... */ },
+
+  // Parse a stored snapshot string into a structured expected value
+  parseExpected(input: string): Expected { /* ... */ },
+
+  // Compare captured vs expected, return pass/fail and resolved output
+  match(captured: Captured, expected: Expected): DomainMatchResult { /* ... */ },
+}
+```
+
+#### `DomainMatchResult`
+
+The `match` method returns a `DomainMatchResult` with two optional string fields beyond `pass`:
+
+- **`resolved`** — the captured value viewed through the template's lens. Where the template uses patterns (e.g. regexes) or omits details, the resolved string adopts those patterns. Where the template doesn't match, it uses literal captured values. This serves as both the actual side of diffs and the value written on `--update`. When omitted, falls back to `render(capture(received))`.
+
+- **`expected`** — the stored template re-rendered as a string. Used as the expected side of diffs. When omitted, falls back to the raw snapshot string from the snap file or inline snapshot.
+
+:::details Why are `Captured` and `Expected` separate types?
+
+When a snapshot is first generated, `render(captured)` produces a plain string that gets stored. But once stored, the user can **hand-edit** it — replacing literals with regex patterns, relaxing assertions, or adding domain-specific query syntax. After editing, `parseExpected(input)` parses this modified string into a type that is _richer_ than what `capture` produces.
+
+For example, in the [key-value adapter](#example-key-value-adapter) below, `Captured` values are always `string`, but `Expected` values can be `string | RegExp`:
+
+```ts
+type KVCaptured = Record<string, string>
+type KVExpected = Record<string, string | RegExp>
+```
+
+This asymmetry is what makes `--update` work correctly: `match` returns a `resolved` string that updates changed literal parts while **preserving** the user's hand-edited patterns. If both sides were the same type, there would be no way to distinguish "what the value actually is" from "what the user chose to assert" — and every update would overwrite the user's patterns.
+
+:::
+
+### Build a matcher from the adapter
+
+Register a custom matcher with `expect.extend(...)` and call the snapshot composables from `vitest`:
+
+```ts [setup.ts]
+import { expect, Snaphsots } from 'vitest'
+
+expect.extend({
+  toMatchMyDomainSnapshot(received: unknown) {
+    return Snaphsots.toMatchDomainSnapshot.call(this, myAdapter, received)
+  },
+  toMatchMyDomainInlineSnapshot(received: unknown, inlineSnapshot?: string) {
+    return Snaphsots.toMatchDomainInlineSnapshot.call(
+      this,
+      myAdapter,
+      received,
+      inlineSnapshot,
+    )
+  },
+})
+```
+
+Then use your matcher in tests:
+
+```ts
+expect(value).toMatchMyDomainSnapshot()
+expect(value).toMatchMyDomainInlineSnapshot(`key=value`)
+```
+
+### Example: key-value adapter
+
+A minimal adapter that stores objects as `key=value` lines, with regex pattern and subset key match support ([full source](https://github.com/vitest-dev/vitest/blob/main/test/snapshots/test/fixtures/domain/basic.ts)):
+
+```ts [kv-adapter.ts]
+import type { DomainMatchResult, DomainSnapshotAdapter } from '@vitest/snapshot'
+
+type KVCaptured = Record<string, string>
+type KVExpected = Record<string, string | RegExp>
+
+function renderKV(obj: Record<string, unknown>) {
+  return `\n${Object.entries(obj).map(([k, v]) => `${k}=${v}`).join('\n')}\n`
+}
+
+export const kvAdapter: DomainSnapshotAdapter<KVCaptured, KVExpected> = {
+  name: 'kv',
+
+  capture(received: unknown): KVCaptured {
+    if (received && typeof received === 'object') {
+      return Object.fromEntries(
+        Object.entries(received).map(([k, v]) => [k, String(v)]),
+      )
+    }
+    throw new TypeError('kv adapter expects a plain object')
+  },
+
+  render(captured: KVCaptured): string {
+    return renderKV(captured)
+  },
+
+  parseExpected(input: string): KVExpected {
+    const entries = input.trim().split('\n').map((line) => {
+      const eq = line.indexOf('=')
+      const key = line.slice(0, eq)
+      const raw = line.slice(eq + 1)
+      const value = (raw.startsWith('/') && raw.endsWith('/') && raw.length > 1)
+        ? new RegExp(raw.slice(1, -1))
+        : raw
+      return [key, value]
+    })
+    return Object.fromEntries(entries)
+  },
+
+  match(captured: KVCaptured, expected: KVExpected): DomainMatchResult {
+    const resolvedLines: string[] = []
+    let pass = true
+
+    for (const [key, actualValue] of Object.entries(captured)) {
+      const expectedValue = expected[key]
+
+      // non-asserted keys are skipped (works as subset match)
+      if (typeof expectedValue === 'undefined') {
+        continue
+      }
+
+      // preserve matched pattern for normalized diff and partial update
+      if (expectedValue instanceof RegExp && expectedValue.test(actualValue)) {
+        resolvedLines.push(`${key}=/${expectedValue.source}/`)
+        continue
+      }
+
+      resolvedLines.push(`${key}=${actualValue}`)
+      pass &&= actualValue === expectedValue
+    }
+
+    return {
+      pass,
+      message: pass ? undefined : 'KV entries do not match',
+      resolved: `\n${resolvedLines.join('\n')}\n`,
+      expected: `\n${renderKV(expected)}\n`,
+    }
+  },
+}
+```
+
+```ts [setup.ts]
+import { expect, Snapshots } from 'vitest'
+import { kvAdapter } from './kv-adapter'
+
+expect.extend({
+  toMatchKvSnapshot(received: unknown) {
+    return Snapshots.toMatchDomainSnapshot.call(this, kvAdapter, received)
+  },
+  toMatchKvInlineSnapshot(received: unknown, inlineSnapshot?: string) {
+    return Snapshots.toMatchDomainInlineSnapshot.call(this, kvAdapter, received, inlineSnapshot)
+  },
+})
+```
+
+```ts [example.test.ts]
+import { expect, test } from 'vitest'
+
+test('user data', () => {
+  const user = { name: 'Alice', score: '42' }
+  expect(user).toMatchKvSnapshot()
+})
+
+test('user data inline', () => {
+  const user = { name: 'Alice', age: 100, score: '42' }
+  expect(user).toMatchKvInlineSnapshot(`
+    name=Alice
+    score=/\\d+/
+  `)
+})
+```
 
 ## 与 Jest 的区别 {#difference-from-jest}