JS
我曾经用Next.
JS搭建过一个演示网站，确实得说，Vercel的
服务器性能非常优秀，甚至让我一度动了付费使用的念头。但无奈我的访问量实在太低，连他们的最低付费门槛都达不到，所以目前还是免费使用着。在开发体验上，我觉得Next.
JS相比Nuxt更加顺手，这可能与
JSX语法有关，写起来感觉特别自然。而且基于文件系统的路由设计也非常方便，至少对于我这种专注于企业站开发的人来说，完全够用了。因为我的项目中并没有特别复杂的URL需求，所以这样的路由方案已经很合适了。不过即便如此，Next.
JS在国内并不算热门，在国外也常常被批评。其中争议最大的一点是它和React之间的关系。从最新的Next.
JS 15版本开始，React和Next.
JS几乎被绑定了，React更像是为Next.
JS服务的一个UI库。这让一些开发者感到不满，毕竟很多使用React的人并不一定需要绑定后端逻辑。而Next.
JS对React底层逻辑的改动也让部分用户感到不适。另一个问题是，尽管Next.
JS对React做了不少深度修改，但它仍然会将所有数据传递到
客户端，这存在一定的安全隐患。更糟糕的是，升级后的Next.
JS竟然不支持国际化功能，官方文档甚至直接教你通过Hack的方式来实现多语言支持。作为一个UI框架，这种做法显然违背了其他框架努力减少开发者工作量的趋势，反而让Next.
JS显得有些退步，令人对其信任度下降。此外，还有一个关于第三方库的问题。比如shadcn这类React插件，往往都需要回退到client模式才能正常使用。这让我在开发过程中感到困惑：明明有些效果仅靠
CSS就能实现，为什么这些库非要加入
JavaScript逻辑？这可能是因为某些
CSS特性在老旧浏览器中无法兼容，只能借助
JavaScript来实现。但如果目标用户群体使用的是较为先进的设备（例如Mac系统），那么这些问题基本可以忽略；但如果希望覆盖更广泛的用户群体，这套组合可能就不太适合了。综上所述，如果你的目标用户大多是高知人群，并且主要使用现代设备，那Next.
JS无疑是一个不错的选择。但如果你希望吸引更广泛的用户群体，则需要慎重考虑是否采用这一技术栈。
