NextJS SSR流程中React生命周期方法的调用时机与方式

Great question—this is a common point of confusion with SSR in Next.js, especially since the line between server-rendered content and client-side interactivity can feel blurry. Let’s break this down step by step, including how React fits into the picture.

1. Server-Side Rendering (First Load from External URL) #

When you access the app via an external URL (not through Next.js's <Link> component):

• The Next.js server receives the request and locates the corresponding page component.
• If the page uses getInitialProps (or the more modern/recommended getServerSideProps/getStaticProps), this function runs exclusively on the server to fetch initial data for the page.
• React on the server renders the page component with this data, generating a complete static HTML file that includes all visible content (what the user will see first).
• The server sends this HTML to the browser, along with the Next.js framework code, React runtime, and your client-side component logic.

Crucially, this isn't an empty container—it's fully rendered content the user can immediately see.

2. Client-Side Hydration (The Browser Phase) #

This is the heart of your question: the browser doesn't replace the entire HTML after SSR—it performs hydration instead:

• First, the browser parses and renders the static HTML from the server. Users see content right away (this is the big win for SSR: fast first paint, SEO-friendly content).
• At the same time, the browser loads and executes the accompanying JS code (React, Next.js, your component logic).
• React "matches up" the static DOM elements with their corresponding component instances, attaching event listeners, state management, and other interactive capabilities.
• Critically, React doesn't re-render the entire page here—it reuses the existing DOM nodes, just activating their interactivity.

3. Execution Timing & Location of Key Hooks/Methods #

Let's clarify where and when core logic runs:

• getInitialProps/getServerSideProps/getStaticProps: Server-side only (for the initial external URL load). They fetch data and pass it as props to the page component during SSR.
• Server-side React rendering: Generates static HTML, but no React lifecycle methods run here—it's just generating an HTML string, not creating live component instances.
• componentDidMount/useEffect: Client-side only, triggered after hydration completes. This is why you can safely access localStorage, window, or other client-only APIs here—these hooks never run on the server.
• Subsequent client-side navigation (using <Link>): Full SPA mode, no SSR involved. All logic runs client-side, including data fetching (like using useSWR or client-side API calls).

4. Your Core Question Answered: No Full Re-Render—Just Hydration #

To directly address your question: No, the SSR-delivered HTML isn't replaced by a SPA re-render.

• The static HTML from the server remains as the initial DOM structure.
• React's hydration process injects interactivity into those existing DOM nodes, rather than deleting and recreating them.
• Only when state changes later (like a button click or component update) will React perform partial DOM updates, just like in a regular SPA.

For example: If your SSR page has a button, the server sends the button's DOM element already rendered. After hydration, React adds a click event listener to that exact button—it doesn't delete the original and make a new one.

Bonus: Why This Matters #

This approach combines the best of both worlds: SSR gives you fast initial loads and crawlable content, while hydration lets you retain the smooth, dynamic experience of a SPA. Next.js handles most of this complexity under the hood, but understanding it helps you avoid common pitfalls (like accidentally accessing client APIs in server-side code, or fixing hydration mismatch errors).

内容的提问来源于stack exchange，提问作者Cerulean