目前在用 Go 做后端开发，前端打算使用 next.js ，但是看了几个帖子下来说 next.js 做全栈会更好一点，还有建议使用 vite 创建 react 项目的。所以比较好奇，这样的技术栈搭配会不会有什么问题？

没啥问题，有些小的后端任务懒得用 go 写了就直接 nextjs 里搞定了

用 nextjs 可以用 trpc ，前端不用写接口请求 api 还能做到端到端类型安全

我感觉用 nextjs 挺好的，下可以只写写前端页面，上可以前后写一起全栈，我当时学 react 都是直接在 nextjs 干的。

nextjs 一些轻量的后端可以做，但是要加上中间件、消息队列、授权等之类的话就比较乏力。

嗯嗯，是的，主要看了几个都是做全栈。所以会比较好奇这样的搭配会不会重复，我对前端的理解不多，还停留在数据渲染这些，感谢！

了解，谢谢大佬解答，目前后端技术上是有中间件和消息队列这些，这样的话，能够明白了

还在以渲染为主 ，后端不建议交给前端框架 ，他们现在真的有点飘

早几年 prisma 吹得听牛逼 用了下 坑一大堆 感觉跟后端的 ORM 还差得远 现在不清楚

纯粹渲染挺好的，至于更复杂一些的程序，我选择用 go 来实现

感谢，打算就渲染为主了，主要功能还是会用 Go 来实现

next 很擅长前端渲染 重用户体验的场景 前端部分偏向官网/营销/电商 后端部分偏向接口拼接及面向前端的业务接口 不适合传统意义上的后端和后台管理应用

＃11 后台管理应用不适合，怎么说？

看你要不要服务端渲染了。不要就 vite+react 。

试试 remix spa remix.run/docs/en/main/future/spa-mode

＃12 你要硬用来写后台那也不是不行 但是没必要啊 后台管理是 spa 不管前端用什么路由模式相对服务端都是单页 但是 next 默认你就是多页应用 所有的设计思路都是多页 建议上服务端渲染的 后台应用上 ssr 和 mpa 不是脱裤子放屁吗 vite,cra 才是适合这种场景的解决方案

感兴趣可以看下我开源的 Saasfly 。 github.com/saasfly/saasfly

＃15 问题在于后台管理为什么就一定是 spa 。。而且 nextjs 的 DX 很好啊，什么都给配好了，无脑写就行。也没说用 nextjs 就一样要 ssr 啊。。我现在全部 dynamic import我反而认为后台就适合用 nextjs 来写，因为不需要什么高并发、中间件前后端一把梭了

Go 和 JS 两门语言切换不觉得会有心智负担吗？nextjs + trpc + prisma 一把梭不香吗？

一般 nextjs 不做数据库操作，都是做 bff 拼 rpc 请求的

github.com/yyong008/remix-antd-admin 也有用 remix 的不过 remix 不如 nextjs 生态强大

我日常就是这俩，说实话这俩语言其实切换没啥心智负担，目前唯一遇到的就是 switch 循环 go 不需要 break ，这个有时候会写错

不知道 next.js 的 ORM 怎么样

nextjs 写后台是没问题的,现在客户端导航 CSR , 非常完善, 纯 SPA 的优势在哪里我不知道...MPA 一样可以做到预读取,无缝渲染,路由权限也可以用 并行路由/条件路由来实现...

有人用 sveltekit 吗

还好，都学一点，发展看看能不能做全栈，哈哈哈哈

对 next.js 一无所知，弱弱的问一下如果我用 next.js 写一个带页面的后端服务给别人用，是不是就相当于把源代码都给了别人？

后台管理：页面性能要求不高，业务复杂难度高、交互复杂度高。前后端分离，vite+react博客官网：页面性能有要求，没啥业务难度。nestjs 一把梭。问题不是渲染或者路由方案的事，而是有的复杂业务问题没有解决方案，你可以在大部分情况用的很爽，但一个核心问题没有现成方案或者不支持就是致命的

bundle + minify 就好了

用 Next.js 写了自己的 SaaS 产品： ppresume.com ，大概 13k 代码左右。Go + Next.js 肯定是没有问题的。不过根据场景，也需要具体的技术选型。- 纯 SPA 程序？用 react 就行- 有搜索 SEO 需求？最好 next.js ，加上单独的后端 - 后端和 next.js 通信又有几种方式，可以采用 next.js 前端和 Go 直接通信，也可以 next.js 的前端 -> next.js server -> go server 通信如果有比如重的 content management 需求，或者需求一个 admin dashboard ，可以考虑采用一些 headless CMS ，如 strapi 这种直接生成后端，这就是非 Go 的后端方案了。

并不是的，next.js 的代码有一部分会在前端浏览器里运行，另一部分是在后端运行的，后端的就不用说了，前端的代码也是经过编译和混淆的，基本上也是不可读的状态。

前后端都用 JS/TS 还有一个好处，就是利用 npm/yarn workspace 这种功能，可以将部分前后端共享的代码抽出来共享，比如一些数据类型定义，一些 utility 等等（楼上也有人提到了 trpc 这种方案，我没有用过）。

多谢大佬解答！

我 go ts 切换 没负担

go+htmx 挺有趣的

相比前后端分离，效率并没有提高，反倒引入了更多复杂性，使用一个月后的观感

＃10 最近被 Next.js 的 abortIncoming 给弄得有点无奈了，时不时就自己退出程序了。现在感觉到，只用 Node.js 拿来做 serverless 的渲染层+Go 核心服务才是绝配，Nextjs 挂了就重新启动，不太建议把一些重活或者关键的程序放到 Next.js 上