跟一次 Next.js 请求走读源码看渲染的玄学从哪来【免费下载链接】next.jsThe React Framework项目地址: https://gitcode.com/GitHub_Trending/next/next.js你项目node_modules里的react并不是真正参与渲染的那个 React。想读 Next.js 源码这是第一课也是解开版本对不上组件边界怪行为这类玄学的钥匙。不先讲架构直接假设你敲了next dev、访问了 /dashboard把这一条请求从头跟到尾。你写的 React 不是渲染用的 React打包器启动打包时第一件要做的事是查一张模块别名表它由packages/next/next-runtime.webpack-config.js里的makeAppAliases()生成{ react$: next/dist/compiled/react, react-dom$: next/dist/compiled/react-dom, react-dom/client$: next/dist/compiled/react-dom/client, }意思是你项目里每一句import react都被悄悄重定向到 Next.js 自己打包好的那份副本上。好处是全局只有一个 React出现了两份 React 导致 hooks 报错这类经典问题在这里就被掐死了。结尾的$表示完整匹配所以react-dom/client不会被误配到react-dom。别名表下面还跟着一个externals清单ws、undici之类声明这些模块不打包运行时直接加载——就像搬家时重的家具放在门口不装进箱子能搬就搬。从 URL 到页面服务端怎么决定渲染什么请求进服务端后先经过parseUrl()把原始 URL 拆成结构化字段实现在packages/next/src/shared/lib/router/utils/parse-url.tsexport function parseUrl(url: string): ParsedUrl { if (url.startsWith(/)) return parseRelativeUrl(url) const u new URL(url) return { pathname: u.pathname, search: u.search, ... } }拿到pathname之后才开始路由匹配静态路由优先[id]这类动态段往后排谁都没配上就走render404。假设你请求的是 /dashboard对应组件被找到服务端渲染SSR——服务端把组件跑一遍生成 HTML出页面浏览器再执行 hydration把这份静态 HTML 接管成可交互的 React 组件。路由之前先过的那道中间件注意路由还没轮到请求要先过一道门卫packages/next/src/server/base-server.ts里getMiddleware()检查当前路径是否命中你写的中间件。它像小区大门口的保安——能查你的东西读请求头、改你的东西改写 URL、也能拦你重定向到 /login。等保安放行才轮到路由匹配。所以中间件里改 cookie能直接影响后面页面的渲染结果这不是巧合是执行顺序决定的。重复请求为什么不会每次都渲染页面如果每个 /dashboard 都重跑一遍组件树服务器会先扛不住。Next.js 把缓存分了三层内存缓存装同一进程内的热数据文件系统缓存.next目录存构建产物和预渲染内容重启后还在最外面可以再接一层 CDN 接静态资源。revalidate决定缓存多久失效到期后下一个请求会先返回旧内容、后台重新渲染——这就是export const revalidate 60背后的原理业内叫 stale-while-revalidate。开发模式下改文件为什么不刷新整页最后看用得最多的机制。packages/next/src/client/next-dev.ts在启动时调用initHMR和浏览器保持一条长连接你一改文件打包器感知变化只把这一个模块的差量推下去。Fast refresh 热替换组件代码时不重载页面useState里的状态也不丢——像水管工不换整栋楼的管道只换坏的那一段。这也是dev 正常、prod 报错这类问题的根源热替换路径和生产渲染路径本来就是两套代码调试时要分清楚你踩的是哪一条。下次报错时从哪一层查起再遇到版本对不上先想模块有没有走别名表页面内容不对就按中间件 → 路由 → 渲染 → 缓存四步排。请求管线是线性的知道它卡在哪一层问题就解决了一半。【免费下载链接】next.jsThe React Framework项目地址: https://gitcode.com/GitHub_Trending/next/next.js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考