名词解释教学工作区 · 课程 0013 · 形态 体系图 · 约 6 分钟 · 前置:无需预备课 · 相关:0014 · Kubernetes · 0016 · 静态部署与其它部署 · 2026-10-01

前端、后端、接口、数据库:四层各站哪一格,谁跟谁说话

1 | 定义

这条链上四个词,从最外面到最里面各占一格。每一格先给一句正式说法,再给一句生活里的说法:

• ① 前端 front-end跑在访客自己的浏览器 browser 里,把数据渲染成画面、把点击接成事件 event 的那一半;送出去的代码谁都看得到、改得了。就像你手里那本菜单:摆在你面前、你翻得动,每道菜长什么样看得一清二楚;也正因为在手里,别人照样能照抄一份带走。
• ② 后端 back-end跑在别人的服务器 server 上,校验身份、执行规则、做计算的那一半;访客看不到它的代码,也直接碰不到它。就像后厨:你进不去,也改不了里面怎么做菜,规矩和账都在那儿算。
• ③ 接口 API(Application Programming Interface,应用编程接口)前后两端之间那份约定 —— 能问什么、答成什么形状。常见做法是用 HTTP 请求一个网址、拿回一段 JSON(JavaScript Object Notation)数据;HTTP(Hypertext Transfer Protocol,超文本传输协议)是浏览器问、服务器答的那套规则,见 MDN 词条。风格上常叫 REST(Representational State Transfer)。就像点单的规矩:你只能按「报哪个菜名、要几分熟」这套说法点,店员也只按它下单;换个说法他就不认。
• ④ 数据库 database负责把记录存下来、按条件取出来的那一格,例如 PostgreSQL、MySQL、SQLite;它认语句不认人,不替谁做业务判断。就像库房:只管把东西放进去、按你说的取出来,不问你为什么拿,也不判断你该不该拿。

串起来一句话:前端管画面,接口管怎么说话,后端管规则,数据库管存。

2 | 这张网

顺着看,是谁求谁:

前端 画面与交互 --HTTP 请求--> 接口 约定问什么、答什么 --转交--> 后端 校验与计算 --SQL 查询--> 数据库 只存记录

反过来看,两处「谁不认谁」才是这条链真正硬的地方:

前端 --不直接查--> 数据库
数据库 --不直连--> 浏览器

把网走一遍。打开一个电商站:浏览器里的前端渲染商品列表 → 你点「下单」时前端用 fetch(浏览器自带的取数函数,见 MDN 词条)调接口 → 后端校验库存与身份 → 写进数据库 → 接口把结果交回前端,前端只改画面上那个数字。同一份接口还能被手机 App、命令行脚本、以及调用大语言模型的应用(课 0022 大语言模型)一起用,爬虫(课 0021 爬虫)拿的往往也是它 —— 前端只是接口的一种访客,不是唯一用户。

3 | 它解决什么麻烦

一块网页要同时干两件事,而这两件事的要求正好相反:

• ① 让人操作:画面必须出现在访客自己的机器上 —— 就在他眼前,点了要立刻有反应。这台机器归他管,代码他能改,数据他能看。
• ② 可信地算账:规则与数据必须放在访客看不到、也改不了的地方 —— 别人的机器上,才谈得上「谁该看到什么、谁准做这件事」。
• ③ 各用各的工具:画画面最顺手的是浏览器里的那套 HTML、CSS、JavaScript;算账与并发最顺手的是服务器上的语言和数据库。硬塞在一起,谁都别扭。
• ④ 各扩各的:访问量涨上来时,要加机器的是后端,要优化的常是前端;数据库又是最该少动的那一块。分开才谈得上给某一段单独加人加机器。

四件事合起来,答案就是把「画面」和「规则」拆到两台机器上,再给它们定一份说话的约定 —— 拆开的落点就是接口。

4 | 每一层怎么工作

• ① 前端:把画面和数据接起来。浏览器把 HTML(超文本标记语言)、CSS(层叠样式表)和 JavaScript 渲染成一棵页面结构,再监听事件;要数据时用 fetch(或老的 XMLHttpRequest)按接口约好的地址发一次请求,拿回 JSON 后只改页面里那一小块,不刷新整页。
• ② 接口:定形状、看门口、管版本。它约好请求方法(GET 查、POST 提交)、地址与参数,以及返回的状态码和 JSON 结构;请求进来先在门口做鉴权 authentication(先认出你是谁)与限流 rate limiting(挡住过密的请求),再转给后端。形状一改,就得靠版本(如 /api/v2/)容下还没升级的老客户端。
• ③ 后端:跑业务规则。拿到请求后先复核身份与参数(不信任前端送来的任何东西),再执行规则,需要动数据时开一个事务 transaction 去读写数据库,算好结果交给接口。热点数据放缓存 cache,免得每次都压到数据库。这套算账代码常用 Node.js(课 0004 Node.js、npm、pnpm)、Java 或 Go 这类运行时跑在服务器上。
• ④ 数据库:存与取。数据落在表 table 里、按行 row 存;建索引 index 让常用查询快起来;用事务保证一组改动要么全成、要么全不成。它只回答「存什么、取出什么」,不回答「该不该」。上面的电商站,走的就是这四步。

5 | 每一层的代价

• ① 前端:首屏与兼容性。页面要等 JavaScript 下载、执行完才出现,首屏容易白一下(提前把整页生成好、让浏览器直接拿到成品 —— 静态站点生成,见课 0017 SSG,就能省掉这一下);同一份代码在不同浏览器、不同尺寸的屏幕上表现还不一致,兼容这道题躲不掉;打包、压缩、按需拆包这条发布流水线还得单独养(一般挂在 CI/CD 上,见课 0008 CI、CD)。
• ② 接口:多一层约定,多一份维护。前后端得同时盯着这份约定,改结构要顾着老客户端;门口还要配鉴权、限流,并处理跨域 CORS(Cross-Origin Resource Sharing,见 MDN 词条)这类只在浏览器里才有的规矩。
• ③ 后端:要养机器、要扛流量。部署、监控、扩容(容器编排那套 Kubernetes,见课 0014 Kubernetes)都归它,人力和机器成本都在这一层;它一挂,整站就不通。
• ④ 数据库:最难迁,最怕写坏。搬家要导出再导入、往往还得停机;一条写错的 UPDATE 就可能改坏生产数据,所以备份与回滚必须先备好。

6 | 边界会移动的地方

分层不是画在地上的线,它会挪。四种常见情形里,边界看着消失了,其实只是换了位置站:

• ① 同机部署:距离没了,地盘还在。前端和后端都跑在你自己这一台机器上,一个命令起两个进程,看着像一层。可前端那份代码照样要送进浏览器,后端那份照样在本地进程里跑 —— 分的是地盘,不是距离。
• ② 后端直接渲染页面(SSR,Server-Side Rendering):接口没了,规则还在里层。后端把数据填进模板,一次返回整页 HTML,浏览器只管显示,中间那层独立接口不见了。这是课 0016 静态部署与其它部署里讲的一种渲染方式,也是课 0017 SSG的反面:拼画面这件事已经被挪到服务器做,而算规则仍然在后端,该在里层的校验一步没少。
• ③ 无服务器函数(serverless function):机器不是你的,机器上的活还是你的。后端拆成一个个按请求才跑的小函数 —— 平时不占机器,请求来了平台才起一个、跑完就停,起停与扩容都由平台管,你只管那段代码(它和云函数是同一类东西,见课 0001 边缘计算与云函数的定位)。少掉的是「维护机器」,不是「在别人的机器上校验与计算」。
• ④ 前端直连数据库(Supabase、Firebase 这类后端即服务 BaaS,Backend as a Service:把数据库、鉴权、存储做成开箱即用的云服务):后端的人不见了,规则搬进了平台的权限策略。前端拿一把 SDK(Software Development Kit,现成的客户端工具箱,见 MDN 词条)直接读写数据库,看着四层只剩两层。但「哪一行谁能动」这条规则并没有消失,它被写成数据库侧的权限策略,由平台在你每次请求时执行 —— 只是写规则的人从后端工程师换成了配置的人。这类「把后端能力当服务卖」的形态和 SaaS 是同一族 —— 区别只在你管到哪一层。

四种情形合起来一句话:你看到的「少了一层」,都是边界换了个位置站,不是它不存在了。定位时先问「这件事在哪个时刻、哪台机器上发生」,别照着图上的格子数。

7 | 常见误解

• ① 「前端就是美工。」不是。它管状态、交互、性能与可访问性(见课 0007 UI 与 UX),复杂页面的前端代码量常常超过后端;美工只是它的一部分输入。
• ② 「接口就是服务器。」不是。接口只是那份约定,它可能由一层网关(gateway,专门转发请求的入口程序)单独实现,也可能就长在后端进程里;同一份约定还能被手机 App、脚本一起用。
• ③ 「前端校验过就够了。」不是。前端校验只是早一点提示,绕开页面直接发请求就跳过了;真正的规则必须落在后端,因为它看得见数据、也拒绝得了请求。
• ④ 「用 WordPress 就不算分层。」不是。WordPress 只是把后端与数据库打包成一套现成的,层还在原地;你调它的主题改的是前端,装插件改的是后端。

8 | 练习

三题自测,每题只有一个正确选项;选完立刻看到解释。