Interviewers open with "what is hydration?" not to hear a definition but to find out whether you know what the client actually does with the server HTML, and therefore why the fixes on the following pages work. A mid-level answer says "Vue attaches event listeners". A senior answer explains the parallel walk, where the inputs come from, and what recovery costs.

Know

• Server: Nitro's render handler builds the app with createSSRApp and calls Vue's renderToString(app, ssrContext) from vue/server-renderer. Nuxt wraps the result with the head tags unhead collected and with the payload: useState and useAsyncData/useFetch results serialised (via devalue) into a <script type="application/json" id="__NUXT_DATA__"> block.
• Client: the entry calls createSSRApp(App).mount('#__nuxt'). Because the app was created with createSSRApp, mount hydrates: Vue runs the first render, and for every vnode it produces it steps to the next existing DOM node, claims it (vnode.el), attaches listeners and moves on. It creates nothing. Hydration succeeds only if the client's first render yields the same tree the server rendered.
• Same inputs on both sides is Nuxt's job. The payload is revived before the app renders, so useState refs and useAsyncData results already hold the server's values on the client; useCookie reads the request's Cookie header on the server and document.cookie in the browser, so both see the same value; unhead renders head tags on the server and hydrates them on the client. Anything outside these channels (Date.now(), window, a raw $fetch) is an input only one side has.
• Development (Vue 3.4+): the console shows Hydration node mismatch, Hydration text mismatch, Hydration children mismatch, Hydration attribute/class/style mismatch, each with "rendered on server" against "expected on client" plus a component trace, and finally Hydration completed but contains mismatches.
• Production: silent recovery. Text content is overwritten; a node of the wrong type is discarded and the vnode mounted fresh; surplus server nodes are removed, missing ones mounted. Costs: layout shift, a flash of the server version, lost server-rendered content, listeners bound to nodes that get replaced, and a partial re-mount on the main thread while the user waits for interactivity.
• __VUE_PROD_HYDRATION_MISMATCH_DETAILS__ (Vue 3.4, compile-time flag, default false) makes production builds log the same details as development, at some bundle cost. Vue's docs set it through Vite define; Nuxt's debug option does the same thing for you: debug: { hydration: true } (or debug: true, which expands to every debug flag) sets the define in the Vite builder.
• data-allow-mismatch (Vue 3.5) declares an expected mismatch on one element. Values: text, children (direct children only), class, style, attribute; no value allows every kind. It suppresses the warning; the recovery still happens.
• useId() (Vue 3.5, import from vue) returns an id that is unique per app instance and identical on server and client, the correct source for generated id / aria-* / for attributes. Prefix apps sharing one page with app.config.idPrefix; never call it inside computed. Nuxt 4 no longer documents a useId of its own; use Vue's.

How it works

Stripped of Nuxt's plumbing, the two entries look like this:

// server (inside Nitro's render handler)
import { createSSRApp } from 'vue'
import { renderToString } from 'vue/server-renderer'

const app = createSSRApp(App)
const html = await renderToString(app, ssrContext) // components run once in Node
// ...Nuxt adds unhead tags + the devalue payload and sends the document

// client (app entry)
const app = createSSRApp(App)
app.mount('#__nuxt') // components run again; Vue walks the existing DOM instead of creating it

Turning production details on for one environment only, so a staging build tells you what production would not:

export default defineNuxtConfig({
  $env: {
    staging: {
      // sets __VUE_PROD_HYDRATION_MISMATCH_DETAILS__ = true in the Vite build
      debug: { hydration: true },
    },
  },
})

Build it with nuxt build --envName staging. The equivalent without the Nuxt option is vite: { define: { __VUE_PROD_HYDRATION_MISMATCH_DETAILS__: 'true' } }.

A component that uses both Vue 3.5 tools, one to prevent a mismatch and one to declare an acceptable one:

<script setup lang="ts">
import { useId } from 'vue'

defineProps<{ iso: string }>()
const labelId = useId() // identical on server and client
</script>

<template>
  <p>
    <span :id="labelId">Published</span>
    <!-- Node and the browser format dates with different locale/timezone; the flash is acceptable here -->
    <time :datetime="iso" :aria-labelledby="labelId" data-allow-mismatch="text">
      {{ new Date(iso).toLocaleString() }}
    </time>
  </p>
</template>

Exercise

Be able to say