lstz

@Amose2024

我用 Next.js 有一段时间，不算是大师哈，但踩的坑也不少，相对也懂一些，我在本贴提到的都是 [standalone] 模式的，关于其他默认模式的不在我探讨范围内。

之前写 middleware 的时候，引入了一些 npm 的库，按理来说是在 Node.js 上跑的应该都能编译，但 Next.js 就是不允许 middleware 上引用一些第三方的库，要不然就报错给你看。经过一些 issues 和官方人员的探讨和相关 workaround ，我才知道如果是 standalone 模式下要用 middleware ，你得配置如：

export const config = {
matcher: "/((?!api|static|.*\\..*|_next).*)",
runtime: "experimental-edge", // for Edge API Routes only
unstable_allowDynamic: [
"/node_modules/lodash/**",
"./node_modules/.pnpm/[email protected]/node_modules/lodash/lodash.js",
],
};


而这个又正好是实验性特性（正如你每次跑 dev 都会提示你的一样： ⚠ You are using an experimental edge runtime, the API might change.）

反正我就一个写代码的，懒得翻源码看，就这么先写着先，对于楼主和我的场景来说，Next.js 都不合适 :P

@Amose2024 一键部署指的是 vercel 那一套吗？确实是有，但我需要更高层次的定制，nextjs 满足不了(或者说场景不合适)

middleware 的 edge engine 确实是实验性质

@tianzx 可以的老哥，感谢建议哈哈哈

我是为了 seo 考虑和页面直出，所以用了 Next.js ，不过也确实到处都是 use client ，我到时候看看架构要不要调整下

@tianzx 对我来说好处就是 ssr+server action ，这些还是 OK 的，坏处就是定制型差，而且场景不太匹配就是说...

关于第二点 abortIncoming ，看了下 issue ，应该也是由 middleware 导致的

nextjs 最大特色是 ssr ，既然你不打算提供网页内容，为什么一定要用 next.js ？

一定想上的话，可以是可以，但我想 nextjs 对你要实现的功能来说，那样会有些重

我目前的开源项目 https://github.com/work7z/LafTools ，有一些后悔上了 Next.js ，主要原因如下:
- 要自行部署，得配 standalone 那套，感觉这 standalone 不是官方最倾向的，人家想你直接上 vercel
- 时不时会遇到 abortInComing 错误，从 12.x 到 14.x 都看到有这个错误抛出(官方为此 release 了几次但还是有)，这对于稳定性来说实在不太能接受(再怎么样也不能整个应用都 crash 了吧)
- 想给你的 header 或者所有 http 请求加点逻辑？拦截器或者中间件啥的？可以，写 middleware ，但那玩意是 experienmental feature ，每次用都心惊胆战的

我再来一次的话，会考虑别的 ssr 框架了。对于你的需求，我建议 express 加 typescript 就 OK 了，可以参考我这个项目的 modules/server2 ，开箱即用

@nenosyyan fyi ，这个是付费软件，且没有完全开源(开源了一些组件)

可行，就是不知道是不是 vim 风格的操作方式

没有工作条件就不要强行办公，不然公司有理由告你的