一、本来分得很清的那条线

前端与后端的分工，本来一句话能说清：

• 前端跑在用户的浏览器里——界面、交互、即时反馈都在这里。它拿不到服务器上的文件，也碰不到数据库。
• 后端跑在服务器上——数据、权限、密钥、跨用户共享的状态都在这里。它的代码用户看不到。

两者之间用 HTTP 说话：前端发一个请求，后端回一份数据。 这条线之所以存在，根本原因只有一个：保密。 凡是不能让用户看到的东西——数据库密码、第三方密钥、别人的数据——都必须待在线的那一头。

二、Node.js 做了什么：把语言搬到了另一头

JavaScript 原本只能跑在浏览器里，这是它出生时的设定。 Node.js 把它从浏览器里拿出来，装到了服务器上——语言没变，位置变了。

于是出现了一个新情况：同一个人可以用同一门语言写两端。 好处很实在——不用在两种语法之间来回切，前端的类型定义可以直接在后端复用。

它现在的地位，用数据看更清楚（State of JavaScript 2025）：

• 后端运行时份额：Node 90%，Bun 21%，Deno 11%。
• 开发者采用率 48.7%，在所有 Web 技术里排第一。
• npm 上的包约 210 万个，Node 每月下载 3.5 亿次以上。

在网站层面它小得多（W3Techs 里 Node.js 作为 Web 服务器只占 7.0%）， 但差距来自探测方式：它常常躲在反向代理后面，探不到。

三、那道线这几年往两边都挪过

边界并没有消失，只是位置换了几次。几种新写法可以看成它挪动的痕迹：

• SSR 服务端渲染——首次访问时，HTML 在服务器上生成，把首屏挪回了服务器一侧。之后才交给浏览器接管。
• RSC 服务端组件——组件本身留在服务器上跑，只把渲染结果发下去，代码不下发。
• BFF 专属后端——为前端单独加一层，专门替它把几个接口的数据拼好，前端少跑几趟。
• 边缘函数——把这一层算力推到离用户最近的节点上，同时缩短延迟。

这几种做法的共同点：它们都不是把逻辑搬过去，而是把【生成界面的那一步】搬过去。 真正保密的东西——密钥、权限判断、数据写入——一直留在后端，一步没挪。

四、怎么判断一段逻辑该放哪边

不用背术语，只问一个问题：

这段代码需要用到【不能让用户看到的东西】吗？

需要——放服务器。不需要——两边都行，那就看哪个更顺手。

用这个标准过一遍常见场景：

• 校验邮箱格式：两边都行，前端做是为了体验，后端做是为了安全。两边都写才是对的。
• 判断这个用户能不能看这条数据：只能在后端。前端的判断只是提示，不是防线。
• 调第三方支付接口：只能在后端，因为带密钥。
• 表格排序、翻页：前端做体验更好，但如果数据量大，就得后端分页。

最容易犯的错是把前端的校验当安全措施。 前端的任何校验都能被绕过——改一个请求就过去了。

五、动手 Demo：把运行时的份额差距算出来

Node 的位置到底有多稳，看它和第二名之间的距离就够了：

print("  后端运行时：Node 90% / Bun 21% / Deno 11%")
print("  Node 约是第二名的 %.1f 倍" % (90 / 21))

实跑输出：

--------------------------------------------------------------------
前后端的分界线，是被 Node.js 挪走的
--------------------------------------------------------------------
  前端和后端本来分得很清：前端在浏览器里跑，后端在服务器上跑。
  两者用 HTTP 说话，中间隔着一道线。
  Node.js 干的事情是：让 JavaScript 也能在服务器上跑，于是这道线模糊了。

  先看 Node.js 现在的位置（State of JavaScript 2025）：

  指标                数字
  ---------------------------------------------
  后端运行时份额      Node 90%
  第二名 Bun          21%
  第三名 Deno         11%
  开发者采用率        48.7%，全部 Web 技术第一
  npm 上的包          约 210 万个
  Node 每月下载量     3.5 亿次以上
  ---------------------------------------------
  如果只看【今年新起的项目】，格局略有不同，但顺序没变：

  运行时      新项目里的份额
  --------------------------------------------
  Node.js     70%~75%（企业、存量、复杂依赖）
  Bun         15%~20%（初创、高性能接口）
  Deno        5% 以内（边缘函数、强隔离）
  --------------------------------------------
  同一门语言，两端各干什么，是这一节最该记住的一张表：

  位置               拿手的事                         不擅长的事
  -------------------------------------------------------------------------
  浏览器（前端）     界面、交互、即时反馈             保密逻辑、直连数据库
  服务器（后端）     数据、权限、密钥、跨用户共享     实时响应每一次点击
  -------------------------------------------------------------------------
  那道线这几年往两边都挪过，于是多出几种新写法：

  写法               把什么挪到了哪边
  ------------------------------------------------------
  SSR 服务端渲染     把首屏的 HTML 生成挪回服务器
  RSC 服务端组件     组件本身留在服务器，只把结果发下去
  BFF 专属后端       为前端单独加一层，替它拼数据
  边缘函数           把这一层算力推到离用户最近的节点
  ------------------------------------------------------
  所以【前端越界】这个说法不太准。真实情况是：
  同一门语言把两头缝了起来，于是【写在哪个文件里】不再等于【跑在哪台机器上】。
  判断一个逻辑该放哪边，只看一个问题：
  这段代码需要用到【不能让用户看到的东西】吗？需要，就放服务器。

4.3 倍这个差距，说明这里不是一个竞争激烈的市场。 需要注意的是：这里比的是【用过它的人的比例】，同一个人可以三门都用。 所以 90% 加 21% 加 11% 没有意义——它们不是互斥的份额。

30 秒实验

1. 打开一个网站，按 F12 禁用 JavaScript 再刷新，看还有多少内容能显示——能显示的部分就是服务器端拼出来的。
2. 在地址栏访问一个 API 地址（比如各种公开接口），看它返回的是 HTML 还是一串 JSON。
3. 在自己的电脑上跑 node -v，看有没有装 Node.js。

常见误区

1. 错误：Node.js 是一门新语言。——纠正：它就是 JavaScript，只是换了个运行环境；语法一模一样。
2. 错误：前端做了校验，后端就不用做了。——纠正：前端校验只防手滑，不防攻击；任何前端校验都能被一条改过的请求绕过。
3. 错误：写了 Node.js 就等于全栈。——纠正：全栈的核心是能同时管好数据与界面，不是用同一门语言；语言统一只是省了切换成本。

• ☐ 下一节（8-7 Web系统中使用的数据格式：XML、JSON）

相关笔记

• 开发框架 —— 前端框架的另一条路线
• ASP.NET与JSP —— 服务器端拼装那一派的代表
• 将客户端与服务器分离 —— 这条边界最初是怎么划的
• 独立于浏览器之外的Web连接机制 —— 不经过浏览器的连接方式
• Web浏览器不仅仅是用来浏览网页的（Web应用） —— Web 应用是怎么长出来的
• 🕸️ Web技术原理 · 索引