ibudao

是的，源头过载，各路渠道都限流，CC 是最近几天才明显感受到影响。

你的需求是要 SSR ，nextjs SSR 是需要在 nextjs runtime 里，但你现在 backend 是 nestjs ，肯定不能直接用 nextjs SSR 。如果只是读数据库，单独开一个 nextjs backend 来 SSR 渲染即可。

一手掏 JI ，一手掏 JI 。

@Nutlee 当你调用 readFile 函数，实际上最终完成功能的是系统调用 read/fcntl 之类的函数。这类函数可以让你的 readFile 立刻返回，并且当读完数据后可以通过某种机制通知 JS 来回调你的 callback 。这个异步是 IO 的异步，想更深入了解 IO 异步原理，可以看看 APUE 的第三章和第十四章。

我也有过类似的困惑，读过一些 Promise 实现后清晰了很多，试着回答一下。

当我们编写异步代码时主要跟两个东西打交道：异步 API 和回调函数。当你的程序只有一个异步调用时，你肯定可以轻松应对。但当你的程序有 N 多个异步调用，并且相互直接有着复杂的关系（多个异步调用同时发出？顺序发出？有一个失败了其它的怎么处理？）时，你的代码将充斥大量的控制变量，你感觉你已经进入了 callback hell 。更恐怖的当有人读你的代码的时候，他会感觉像吃屎一样难受。

这个问题大部分语言都存在，只不过 JS 更受关注，人多嘛，再加上 WEB 程序天生就面对大量异步网络请求。

所以， Promise 只是一个解决异步相关问题的“框架”，它帮你梳理异步操作模型。用它写出来的代码可读性高，容易理解，仅此而已。

@mengzhuo 前后端分离跟服务端渲染（即你说的 Nodejs 渲染）好像是两码事吧，前后端分离是指业务数据跟展现的分离， UI 渲染是展现层的部件，这块按需求即可以放在用户前端做，也可以放在服务端来做。这种服务端渲染虽然也是在服务端，但是跟以前的概念不一样吧

渲染是有 CPU 和内存开销的，在大量渲染场景中，你觉得这个开销是放在服务端自己维护，还是利用现在越来越高性能的终端设备呢？

手写的解析器，还是用的解析器生成器？

这个语法设计有点意思