说几点个人使用 nextjs 的感受

[MorningStar0]

网页： https://freezer-home.ashesborn.cloud/ 仓库： https://github.com/sadofriod/freezer-home

部署角度

目前体验基本满分。结合 vercel 基本不用任何配置，就能快速部署。并且使用 cloudflare 的域名后，也可以实现让国内访问。

开发体验角度

无法在 server component 里直接使用 hooks ，ref 和 react 的事件收集（ onChange 这类）的功能，所以有些动画需要原生实现，失去了 react 的很多便利性。

SEO 角度

由于可以将大部分内容直接通过静态页面返回，所以确实带来了巨大的提升。但是官方文档对于 robots ，sitemap ，meta 标签的 keywords 之类的常见功能没有提供一个比较好的解决方案(目前还是采用字符串模版拼接的方式，或者是我没仔细看)，理想的情况下希望能提供几个函数来收集每个路由下的信息来解决这个问题。

监控工具的集成角度

目前我集成了 google analytics 、tag manager 、google 站长工具。官方提供了一个集成的 component 配置比较简单。

server 负载角度

对于大部分网页访问量不高的情况不会有问题，但虽然提供了 server component 的渲染缓存，但对于接入数据的变动 server component 来说，还是存在部分 CPU 密集型的计算在 nodejs 的 server 中，在访问量比较大的时候，还是需要考虑。

总结

总的来说，对于我个人来讲，如果没有强烈的 SEO 需求，对于一般项目的话不会采用 nextjs 。server component 和 client component 的分离，迫使我在状态管理上要做更多思考和操作。而且对于首屏的渲染在现在协商缓存的基础下，也只有用户收到新版本的网页的时候会有差距，其他大部分情况下差距不大。

[tpxcer]

那你的描述似乎 NUXT 比较舒服些。

[zsj1029]

Astro 试试

[lavard]

生态为王，nextjs + tailwindcss + shadcn/ui 这套太能打了，太适合目前的 AI 时代了，很多产品只要描述下就能生成。就是 React 19 大改了， 很多第三方库还没跟上，用 next15 又上 React 19 又有点尴尬 ， 开发体验还没那么快升上去，等周边生态吧。

[MorningStar0]

@tpxcer 因为一直是 react 生态 nuxt 还没体验过

[MorningStar0]

@zsj1029 之前用过，怎么说呢，感觉开发体验有点原始

[MorningStar0]

@lavard 我是使用 MUI( https://mui.com/)这个库了，而且总感觉 css in js 比 tailwindcss 更适合 JSX 这种情况😂

[snowlee]

开发体验确实不太行，热更新慢而且老报错

如果不是考虑 SSR 还是用 Vite 开发舒服，生态完全可以自己选择，Vite + tailwindcss + shadcn/u,

或者 Vite + mui or antd+ styled-compoents 都不错

[MorningStar0]

@snowlee 我用 v15 ，现在在创建项目的时候可选 turbopack 了，所以热更新还挺快的。

[snowlee]

@MorningStar0 #8 15 确实没太了解。https://www.snowlee.site/ 我的博客是 13 搭建的，基本加个新页面就要重新启动，然后热更新真的比 vite 慢好多好多

[Frankcox]

我是 SRE ，目前也刚刚开始自学 React 和 Next.js ，现在有个问题想请教下，React Next.js 开发时是需要明确区分服务端组件还是客户端组件吗？这些一般都是在设计的时候根据数据情况来进行区分吗？

[MorningStar0]

@Frankcox 是的，在 server component 中是无法使用 useEffect 和 useState 这些常用 hook 的。如果当前组件是 client component 需要在文件最顶部声明。

[jun0205]

觉得 nextjs 除了 api 比较好用，其它的算是把前端开发都变复杂了，然后开发环境是真慢，用 nextjs 主要还是为了使用 vercel

[cwliang]

用过一段时间，体验不是很舒服，如果不考虑 SEO ，我是不会用这玩意的。
13=>14=>15 每个版本变动很大，需要重新看文档。文档比较杂，同一个东西能看到好几种使用姿势。还有那个 NextAuth ，简直就是一坨。跑起来很吃内存，如果有内存泄漏问题，需要很强的 node.js 功底去排查，用起来成本挺高的

[9ki]

不喜欢 next.js 的一个重要原因是它的脚手架又重又难用, 和基于 vite 的一堆 ssr 框架相比体验差太远了

[witcan]

为什么我用最新版的 nextjs ，什么都不改，构建生产文件就报错，不知道是不是姿势不对

[fescover]

试试 react-router v7, 一个框架集齐 spa, ssr, ssg
https://reactrouter.com/home

搭配 trpc, 全栈开发体验丝滑
https://github.com/SteveSuv/remix-t3-stack

[monkeyWie]

我用 nextjs 不用它的 SSR ，我还是前后端分离，build 出来的静态文件放 CDN ，这样感觉最完美

[zhengfan2016]

公司主用框架就是 nextjs ，实话说我觉得 op 对 nextjs 很大概率仅存于业余上的使用或者就不是专业的 react 前端，才能得出 server component 不好用的结论。server 组件优势就是可以把一些内容移到水合前就填充进白纸 html 里，加快首屏渲染速度。至于 hooks ，你完全可以分离拆组件，而且 nextjs 允许你客户端和服务端组件相互嵌套，你只要不通过 props 传递 JSX 就可以，其实是有一丢丢像 astro 的岛，每个客户端组件就是一个岛

推荐阅读国外其他前端 er 对 react 服务端的帖子： https://www.joshwcomeau.com/react/server-components/

我是工作经验 1.5 年的 react 前端，如果你工作年限比我大，那么你说得对😁

[MorningStar0]

@zhengfan2016 不好评价 可以看看我 blog

[zhwithsweet]

无所谓，我全都要 https://github.com/fisand/f3-app

[zhwithsweet]

@zhwithsweet #20 地址 [f3-app]( https://github.com/fisand/f3-app)

[MorningStar0]

https://sadofriod.github.io/

[luvsic]

@zhengfan2016 #18
我也觉得 Next.js App router 的心智负担大，https://qwik.dev/ 的代码更好理解

[Plumbiu]

@zhengfan2016 我觉得你也有误解，客户端和服务端是不能传递函数，不是不能传递 JSX ，你话说的范围缩小了

[yeluowjz]

@cwliang 解析富文本的 json 数据，递归生成节点树的时候，图片类型用了 Image 组件，结果就内存泄漏了

[zhengfan2016]

@Plumbiu 你说得对，确实是不能传递函数，这个我打错了

[ZZ74]

@zhengfan2016 和 jsp 一样的.... 好不好用看项目。但是 jsp 被淘汰也是值得吸取的教训

[fyxtc]

我去年用 13 写了个项目，然后今年又用 15 写了个项目，重新看 app router 概念，刚看的那时觉得很恶心，为什么变化这么大，用过了其实就还好。还有就是 server 里用 client hooks 很容易，直接把变化的部分抽成 client 就好了。整体来说新版适应后还是更舒服，数据交互写起来爽很多，不用像 13 一样到处都是 swr 和判断 loading ，直接在 server 里 db 出来就好了，用过了就回不去了

[zhjrcc]

感觉 OP 这种贴真挺好的，有经验的前辈可以讨论，然后我们有一些在学习的也能从你们的讨论中得到一些知识~~

[SkywalkerJi]

@lavard 现在对 ai 适配最好的就是 next 吗

[shiny]

sitemap.xml 、robots.txt 、meta 自带了一些方案，如 generateSitemaps, generateMetadata, robots.ts ，我感觉还挺好用的

[OneNewLife]

12 以前我给满分，从 13 开始一直是负增长。。。

[XTTX]

用 1.5 年的经验去评价别人对一个栈的理解业余， 这事本身就很业余。
1. 是不是真的快
2. 快多少
3. 服务器需要增加多少费用
4. 增加的心智负担
5. 增加的复杂程度
6. 增加的接手成本

这是取舍题。

sitemap, OG gen, meta 都有不用 ssr 的方案， 而且 SEO 早就不是问题了，2024 了 google 也不至于这么落后。

[gogozs]

如果公司组织架构本身就前后端分离，你用 rsc 也没多大意义，一个接口请求慢，你这边本身也做不了什么事情。如果在 layout 做 rsc ，rsc 调接口，甚至每个页面返回都变慢。

如果全栈，那接口慢就自己直接改造了，那还是很爽的。关键还是你得按照 next js 想要的方式写就很爽，如果还是前后端分离，那是自己给自己找麻烦。

再补充一个点，router.push 后，useSearchParam() 更新还得过一次服务端，然后客户端组件就会可能用到旧参数渲染。

[MorningStar0]

@shiny 我看了官方的这些例子，正如我描述的，这种维护字符串模版的模式还是没有达到我的预期。如果能自动通过路由收集生成 sitemap ，然后类似用‘use client’或者注释的方式来提供 robots 和 meta ，这是我希望它能达到的效果。

[XCFOX]

React Server Component 在我看来不是一个好的设计，为了解决一个简单问题的问题引入了更多概念和复杂度。

最初 RSC 要解决的简单问题是：在服务端渲染时如何请求数据？
由于 React hooks 令人费解的设计哲学，React 传统组件无法异步。在客户端渲染时，一般通过 `useEffect` 来获取数据。而在服务端渲染时，我们无法使用 `useEffect`，这使得在服务端请求数据（以及其他异步操作）成为了一个问题。顺带一提，vue3(nuxt.js) 就不会面临这个问题，因为 vue3 的组合式 API 没有 React hooks 的一堆限制，并且 setup 是能够异步的。

Next.js(RSC)给出的答案是：设计一个全新的服务端组件，专门用来在服务端发请求。好处是，这个组件可以异步了，坏处是，在这个组件中无法使用 hooks 。
Remix(React-Router-v7)的答案是：Loader 。预先定义好要加载的数据，框架会在数据加载完后将数据注入到组件中。

在我看来 Loader 方案明显比 RSC 更好：

1. 性能更好：Loader 单次加载完成页面所有数据； RSC 每次加载一个组件，加载完父组件的数据，再加载子组件的数据。
2. 更低的心智负担：Loader 只需要提前写好请求，然后方便地通过 useLoaderData 拿到数据； RSC 则引入了额外的服务端组件的概念，在编写时得区分是否为服务端组件，还得到处写 "use client"。

包括新出的 TanStack 也是提倡使用 Loader 方案而不是 RSC 。

参考：
https://react.dev/blog/2020/12/21/data-fetching-with-react-server-components
https://nuxt.com/docs/getting-started/data-fetching
https://remix.run/docs/en/main/discussion/data-flow
https://tanstack.com/router/latest/docs/framework/react/guide/data-loading

[XTTX]

@MorningStar0 sitemap 生成自己写 https://github.com/supabase/supabase/blob/master/apps/www/internals/generate-sitemap.mjs 每个网站的需求都不一样， 很多需要读 mdx ， 有些 url 又需要过滤掉。package.json 里 写个 postbuild, 指向这个 script 就行了。