从浏览器到服务器，三层模型怎么来的
如果你正在开发一个 Web 应用，很可能你已经在用 B/S 架构——只是你未必这么叫它。浏览器发请求，服务器返回响应，这听起来简单，但背后有一套成熟的分层模型，让开发、部署、扩展都变得可控。
说白了，B/S（Browser/Server）架构就是把用户界面、业务逻辑、数据存储拆成独立的层，全部通过标准的 Web 浏览器访问，不用在用户设备上装任何专用客户端。一个现代浏览器就是唯一的入口。这种'零安装、即开即用'的特性，在互联网普及之后迅速成了主流。
典型组成：不止三层
教科书上常说三层模型，但实际部署时往往会多一个 Web 服务器挡在前面。整体上你可以这样看：
graph LR
subgraph Client
Browser[浏览器]
end
subgraph Server
WebServer[Web 服务器 Nginx]
AppServer[应用服务器]
DB[(数据库)]
end
Browser -->|HTTP/HTTPS| WebServer
WebServer -->|转发请求 | AppServer
AppServer -->|SQL| DB
表示层（浏览器） 负责画界面、处理用户输入、发起 HTTP 请求。技术栈以 HTML/CSS/JavaScript 为核心，React、Vue、Angular 这些框架让前端能搞复杂的单页应用。但浏览器依然被沙箱限制，没法直接碰本地文件系统或硬件，所有状态也需要靠 Cookie、Token 之类的手段维持——HTTP 本身是无状态的。
业务逻辑层（应用服务器） 是真正的核心。这里跑着 Java（Spring Boot）、Python（Django/FastAPI）、Node.js（Express/NestJS）或者 Go，处理路由、认证、事务、调用第三方服务，并对外暴露 RESTful 或 GraphQL API。在前后端分离的架构里，这层不再渲染 HTML，只返回 JSON。
数据访问层（数据库） 管持久化。关系型数据库（MySQL、PostgreSQL）适合强一致性需求的场景，非关系型（MongoDB、Redis）则在高并发和灵活 schema 下更有优势。实际项目里，缓存、分库分表、读写分离通常是标配。
挡在浏览器与应用服务器之间的 Web 服务器（如 Nginx） 主要当反向代理：扛住静态资源请求、做 SSL 终止、负载均衡，有时也负责限流和安全策略。
一个登录请求的完整旅程
为了更直观，看一下用户登录时发生了什么：
sequenceDiagram
participant User as 用户 (浏览器)
participant Nginx as Web 服务器
participant App as 应用服务器
participant DB as 数据库
User->>Nginx: GET /login
Nginx->>App: 转发请求
App->>User: 返回登录页面
User->>App: POST /login (账号 + 密码)
App->>DB: 查询用户凭证
DB-->>App: 返回用户数据
App->>App: 验证凭证
alt 凭证有效
App->>App: 设置 Session / 返回 JWT
App->>User: 重定向至 Dashboard
else 凭证无效
App->>User: 返回错误信息
end
整个过程里，浏览器只管把输入发出去，应用服务器做所有逻辑判断，数据库只存数据。这种清晰的分工让每一层可以独立演进，比如把 Python 后端换成 Go，只要 API 不变，前端完全无感。
历史拐弯时：B/S 架构是如何走到今天的
B/S 架构不是一成不变的。回想下九十年代，Web 全都是静态 HTML，通过 CGI 脚本生成页面已经是高级活了。后来 PHP、ASP 掀起动态网页浪潮，每次操作都要整页刷新。2005 年之后，Ajax 让局部刷新成为可能，用户终于不用盯着白屏等待。大约 2010 年起，SPA（单页应用）成为标配，React、Vue 让前端彻底脱离后端模板，体验接近原生。最近几年，PWA 和 WebAssembly 又打开了新的大门，连 VS Code、Figma 这种重度工具都能在浏览器跑得飞起。
| 时期 | 架构特征 | 代表技术 | 用户体验 |
|---|---|---|---|
| 1990s | 静态网页时代 | HTML + CGI | 极简，仅信息展示 |
