先叠个甲，我也不怎么喜欢 Next.js ，但是一些事实性错误看到也是挺奇怪的。

来了 V 站，见过吐槽 Next.js 的观点有以下几个：

1. 服务端组件不能用 hooks

这是最令我奇怪的一个点，服务端能用 hooks 还得了，是想让服务端有副作用吗。

这里贴一句 V 站之前看到的评论：“在客户端渲染时，一般通过 useEffect 来获取数据。而在服务端渲染时，我们无法使用 useEffect，这使得在服务端请求数据（以及其他异步操作）成为了一个问题”。

有没有一种可能，服务端组件直接 fetch 就能获取数据了。

2. use client 设计恶心

事实上，Next.js 可以自动判断当前组件是不是客户端组件，但这对开发者来说不是显性的，use client 可以更好告诉你，这个组件是客户端组件。

（另外，有人说 Astro 的 client:load 好的，我就纳闷了，这和 use client 有啥区别......）

不过 Astro 的选择性水和我觉得挺好的，这点比 Next.js 强很多。

直接说可能不明白，既然 Next.js 能做到自动判断当前组件是不是客户端组件，那直接标记这个组件是客户端组件不就行了，那假设我有个组件 C：

function C() {
	return <div>C 组件</div>
}

很明显 C 是一个服务端组件，至少可以当成一个服务端组件，它没有任何副作用，你还有个组件 A （服务端组件）和组件 B （客户端组件），两个组件都用了 C 组件，Next.js 怎么判断 C 组件该如何渲染？你第一次接触 C 组件，要求你从服务端获取数据，你是写 RSC 还是写 useState 和 useEffect ？

3. Remix 的 load 更好

有没有一种可能，Next.js 的 page router 的 getServerSideProps 函数和 load 一样。

4. RSC 无法实现 oClick 等事件

要不你发明一个服务器，能把你浏览器里的元素绑定上这个事件。

想要绑定客户端事件，老老实实写 use client 。

5 ....

欢迎大家补充。

最后

我认为 Next.js 最恶心的地方其实是在于团队十分固执，你必须遵照它的写法，最明显的例子就是之前版本的 Next.js 重写了 fetch ，默认 force-cache 。

而且 Next.js 直接使用 React 的最新代码，稳定性有待考察（这点可以参照 React19 Suspense 变化，因为这个 React19 延迟发布来着）。

另外，Next.js 本身性能极其之差，团队甚至没有意识到这点，或者意识到但是不愿去做任何优化，只是一味地优化开发速度。

最后，Next.js 的使用场景可以说几乎没有，为了首屏加载速度，不好意思 Next.js 太慢了，见 https://github.com/eknkc/ssr-benchmark 。你说为了 seo ，个人项目我能理解，公司项目不如花点钱排名竞价，比用 Next.js 成本小很多（仅限国内）。想了想也就个人博客、交互性少的页面能用一下了。