论坛型应用要考虑SEO，所以SSR是必要的。我本身是个node.js全栈开发者，但是之前都是前后端分离的，也没有SSR的需求，所以这方面我虽然有所了解但没有实际生产经验。

选框架要考虑几点：

下面我也会从这几点谈谈我框架选型的历程。

一、开始时，直觉让我选择Next.js

说到全栈框架，说到SSR，所有人的第一印象，应该都逃不脱Next.js，目前最最流行，生态最最大的框架。

我也不例外。

我本身对国外流行的技术一直都是比较关注的，上来就选择了 create t3，之前一直被他的前后端同构、TS类型从头梭到尾吸引。

但是实际启动一个项目的时候，才感觉到实在是复杂。各种包裹，各种预创建好的不知道干啥的文件。

其实不用管他里面的东西究竟是干啥的，只要按照他的规范要求，往后写自己的业务就行了。但是我对于这种不能全盘把控的感觉非常不喜欢，也不想花时间去看每一个东西，就直接选择换一个框架。

二、换到Sveltekit，DX第一档的SSR框架

看来看去，我决定选择用Sveltekit试一把，因为网上都说他是心智负担最低，DX最好的全栈框架。

我之前从来没写过Svelte，但是写过Vue。

Svelte的语法都没怎么看，就能直接上手。按照Sveltekit的官方文档，启动一个空项目，然后稍微看看，Sveltekit也就额能上手了。

我看完感觉确实是简单好用，完全不用像Next.js里那样考虑是客户端组件还是服务端组件，接口请求也很符合直觉很易用，而且不怕把一些服务端的内容不小心暴露给客户端网页。

于是我决定冲，但是心里明白，选择他就以为着放弃React强大的生态和AI语料。但是一个论坛型的应用，不涉及到特别特别复杂的需求，也不需要多强大的生态，实在不行自己封装下也问题不大。

在AI的加持下，不长的时间就把论坛的雏形写好了。

但是我心里还是老对React的生态念念不忘，并且不喜欢文件路径即路由的写法，没有写纯前端那种随意嵌套的爽感

在出版已经写得差不多的情况下，我又重起炉灶，换用了React Router V7。

我喜欢他的两点：1.路由可以随意嵌套；2.有强大的生态和AI语料。

在AI的加持下，又完成了出版。

但是在后期，让人不爽的事情又出现了。

一是他的不同组件和不同layout是并行请求和渲染的，没法像Sveltekit那样父组件的数据穿透到子组件。比如登录鉴权信息，我不同层级都想用的时候，花了很多功夫去找最佳实践，最终还是搞了个WeakMap进行缓存。

二是一不小心会把服务端的东西打包到客户端，导致网页报错，特别是让AI写的时候。这写起来既不爽，也不安全。

三是开发的时候，因为vite的热更新，开发过程中经常会出现点击路由跳转的时候跳不过去，要刷一下才行；还时不时地因为热更新的问题开发过程中页面报useContext为null的错。虽然这些不影响最终的生产版本，但是开发过程比较蛋疼。

于是我又决定换

有换框架的想法的时候，正好Antigravity和opencode比较火。于是我用opencode登录Antigravity的账号，让AI直接把写好的React Router V7的功能，全部迁移到Next.js上。

过程出乎意料地顺利，中间有一些小错误，给AI一些提示就很快地解决了。

这一次我没有用create t3，直接使用的Next.js，心智负担小了不少。

用Next.js有几个好处：

一是AI语料实在太丰富了，任务基本都可以交给AI来写；

二是生态实在是太丰富了，要啥有啥；

三是有了Sever Action之后，前后端的交互非常顺畅。

所以最终，我还是决定用Next.js来写。