1
❌ 不好的设计：
2
GET  /api/getUserList
3
POST /api/deleteUser?id=1
4
GET  /api/user/query?id=1
5

6
✅ RESTful 设计：
7
GET    /api/users          # 获取用户列表
8
GET    /api/users/1        # 获取单个用户
9
POST   /api/users          # 创建用户
10
PUT    /api/users/1        # 全量更新用户
11
PATCH  /api/users/1        # 部分更新用户
12
DELETE /api/users/1        # 删除用户
13
GET    /api/users/1/orders # 获取用户的订单（嵌套资源）

1
{
2
  "code": 200,
3
  "message": "success",
4
  "data": {
5
    "id": 1,
6
    "name": "Tom"
7
  }
8
}

1
GET /api/users?page=1&pageSize=10        # 分页
2
GET /api/users?status=active             # 过滤
3
GET /api/users?sort=-createdAt,name      # 排序（- 表示降序）
4
GET /api/users?fields=id,name,email      # 字段筛选

1
// PUT /users/1  —— 全量替换
2
{ "name": "Tom", "age": 20, "email": "tom@x.com" }
3

4
// PATCH /users/1  —— 只更新 name
5
{ "name": "Tom" }

1
// 401 vs 403 是高频追问点
2
// 401：你是谁？（未认证）→ 前端应跳转登录页
3
// 403：我知道你是谁，但你不能这么做（未授权）→ 前端应提示无权限
4

5
// axios 拦截器典型处理
6
axios.interceptors.response.use(
7
  res => res,
8
  err => {
9
    const status = err.response?.status;
10
    if (status === 401) {
11
      // token 过期，清除登录态并跳转
12
      clearAuth();
13
      router.push('/login');
14
    } else if (status === 403) {
15
      message.error('无权限访问');
16
    }
17
    return Promise.reject(err);
18
  }
19
);

1
JWT = Header.Payload.Signature
2

3
Header:    { "alg": "HS256", "typ": "JWT" }        → Base64URL 编码
4
Payload:   { "userId": 1, "exp": 1735689600 }      → Base64URL 编码
5
Signature: HMACSHA256(header + "." + payload, 密钥)
6

7
验证流程：
8
1. 服务端用密钥重新计算签名
9
2. 与 Token 中的签名比对 → 防篡改
10
3. 检查 exp 是否过期
11

12
注意：Payload 只是 Base64 编码，不是加密！
13
不要放密码等敏感信息。

1
// 前端典型用法
2
// 登录后存储 token
3
localStorage.setItem('token', res.data.token);
4

5
// 请求时携带
6
axios.interceptors.request.use(config => {
7
  const token = localStorage.getItem('token');
8
  if (token) config.headers.Authorization = `Bearer ${token}`;
9
  return config;
10
});

1
OAuth 2.0 角色：
2
- Resource Owner：用户
3
- Client：第三方应用
4
- Authorization Server：授权服务器
5
- Resource Server：资源服务器
6

7
四种授权模式：
8
┌──────────────────┬────────────────────────────────┐
9
│ 授权码模式        │ 最常用最安全（网站第三方登录）  │
10
│ (Authorization   │ 流程：跳转授权页 → 用户同意 →   │
11
│  Code)           │ 回调返回 code → 用 code 换 token│
12
├──────────────────┼────────────────────────────────┤
13
│ 简化模式          │ 已废弃（token 暴露在 URL）      │
14
│ (Implicit)       │                                │
15
├──────────────────┼────────────────────────────────┤
16
│ 密码模式          │ 高度信任的第一方应用            │
17
│ (Password)       │ 直接传用户名密码换 token        │
18
├──────────────────┼────────────────────────────────┤
19
│ 客户端模式        │ 服务间调用（无用户参与）        │
20
│ (Client          │                                │
21
│  Credentials)    │                                │
22
└──────────────────┴────────────────────────────────┘
23

24
授权码模式为什么安全？
25
- code 通过前端信道（浏览器重定向）传递，一次性且短时效
26
- token 通过后端信道（服务器间通信）换取，不暴露给浏览器
27
- 配合 PKCE 可防授权码拦截攻击

1
RBAC（Role-Based Access Control）基于角色的访问控制：
2

3
用户 ←→ 角色 ←→ 权限
4

5
用户不直接拥有权限，而是通过角色间接获得。
6
一个用户可有多个角色，一个角色可有多个权限。
7

8
表设计：
9
sys_user（用户表）
10
sys_role（角色表）
11
sys_menu/permission（权限表）
12
sys_user_role（用户-角色关联表）
13
sys_role_menu（角色-权限关联表）
14

15
前端配合：
16
1. 登录后获取用户角色和权限标识列表
17
2. 路由守卫：根据权限动态生成可访问路由
18
3. 按钮级权限：v-permission 指令控制显示

1
Node.js 事件循环（libuv）分阶段：
2

3
   ┌───────────────────────────┐
4
┌─>│           timers          │  setTimeout/setInterval
5
│  ├───────────────────────────┤
6
│  │     pending callbacks     │  系统级回调（如 TCP 错误）
7
│  ├───────────────────────────┤
8
│  │       idle, prepare       │  内部使用
9
│  ├───────────────────────────┤
10
│  │           poll            │  I/O 回调（文件、网络）
11
│  ├───────────────────────────┤
12
│  │           check           │  setImmediate
13
│  ├───────────────────────────┤
14
│  │      close callbacks      │  socket.on('close')
15
│  └───────────────────────────┘
16

17
与浏览器的差异：
18
1. 浏览器：微任务队列在每次宏任务后清空
19
2. Node 11 前：微任务在每【阶段】结束后清空
20
   Node 11+：与浏览器对齐，每个宏任务后清空微任务
21
3. Node 独有：setImmediate（check 阶段）vs setTimeout（timers 阶段）

1
// Node.js 经典输出题
2
setTimeout(() => console.log('timeout'), 0);
3
setImmediate(() => console.log('immediate'));
4
// 输出顺序不确定（主模块中），但在 I/O 回调中 immediate 总是先执行
5

6
// process.nextTick 优先级高于 Promise.then
7
Promise.resolve().then(() => console.log('promise'));
8
process.nextTick(() => console.log('nextTick'));
9
// 输出：nextTick → promise

1
// Node.js 单线程，CPU 密集任务会阻塞事件循环
2
// 解决方案：
3

4
// 1. Worker Threads（官方推荐，Node 12+）
5
const { Worker } = require('worker_threads');
6
const worker = new Worker('./heavy-task.js');
7
worker.postMessage({ data });
8
worker.on('message', result => console.log(result));
9

10
// 2. Child Process（fork 子进程）
11
const { fork } = require('child_process');
12
const child = fork('./heavy-task.js');
13
child.send({ data });
14
child.on('message', result => console.log(result));
15

16
// 3. Cluster（多进程负载均衡，利用多核 CPU）
17
const cluster = require('cluster');
18
const os = require('os');
19
if (cluster.isPrimary) {
20
  for (let i = 0; i < os.cpus().length; i++) cluster.fork();
21
} else {
22
  require('./server.js');  // 每个子进程运行服务
23
}
24

25
// 4. 任务拆分 + setImmediate（让出事件循环）
26
function processChunk(data, index) {
27
  if (index >= data.length) return;
28
  processItem(data[index]);           // 处理一小块
29
  setImmediate(() => processChunk(data, index + 1));  // 让出控制权
30
}
31

32
// 5. 使用 C++ 扩展 / WASM（如 sharp 图片处理）

1
// Koa 洋葱模型：请求进入时顺序执行，响应返回时逆序执行
2
app.use(async (ctx, next) => {
3
  console.log('1 进入');
4
  await next();       // 执行下游中间件
5
  console.log('4 返回');
6
});
7
app.use(async (ctx, next) => {
8
  console.log('2 进入');
9
  await next();
10
  console.log('3 返回');
11
});
12
// 输出：1进入 → 2进入 → 3返回 → 4返回
13
// 应用场景：日志统计耗时、事务回滚、响应统一包装

1
传统模式：
2
前端 → 后端微服务A、B、C（前端需调多个接口，聚合数据）
3

4
BFF 模式：
5
前端 → BFF 层（Node.js）→ 微服务A、B、C
6

7
BFF 的价值（前端主导的服务层）：
8
1. 接口聚合：多个微服务数据合并成一个接口
9
2. 数据裁剪：只返回前端需要的字段，减小体积
10
3. 适配多端：为 Web/App/小程序提供不同数据结构
11
4. 缓冲层：后端接口变更时，BFF 层消化差异
12
5. SSR：Node.js 天然适合服务端渲染
13

14
常见技术选型：NestJS / Egg.js / Express + GraphQL

1
@RestController          // = @Controller + @ResponseBody，返回 JSON
2
@RequestMapping("/users")  // 路由前缀（类似 Express Router）
3
@GetMapping("/{id}")     // GET 请求，@PathVariable 取路径参数
4
@PostMapping             // POST 请求
5
@RequestParam            // 查询参数 ?name=xxx（类似 req.query）
6
@RequestBody             // 请求体 JSON 自动反序列化（类似 req.body）
7
@Service                 // 业务逻辑层
8
@Repository / @Mapper    // 数据访问层（DAO）
9
@Autowired               // 依赖注入（类似 NestJS 构造函数注入）
10
@Transactional           // 声明式事务（类似 TypeORM 事务）

1
// 典型分层结构（与 NestJS 完全对应）
2
@RestController
3
@RequestMapping("/users")
4
public class UserController {
5
    @Autowired
6
    private UserService userService;   // Service 层
7

8
    @GetMapping("/{id}")
9
    public Result<UserVO> getById(@PathVariable Long id) {
10
        return Result.success(userService.getById(id));
11
    }
12
}
13

14
// Controller（接收请求）→ Service（业务逻辑）→ Mapper（数据库操作）
15
// 前端联调报错时看哪一层：
16
// 400：Controller 参数校验失败
17
// 500：Service/Mapper 抛异常，看后端日志的堆栈

1
// Java 常见校验注解（JSR-380 / Hibernate Validator）
2
@NotNull      // 非空（对象）
3
@NotBlank     // 非空字符串
4
@Size(min=1, max=20)   // 长度
5
@Min(0) @Max(100)      // 数值范围
6
@Email        // 邮箱格式
7
@Pattern(regexp="^1[3-9]\\d{9}$")  // 手机号正则

1
// 前端应做同样的校验（提升体验），但不能替代后端校验（安全）
2
// 规则保持一致，避免"前端通过、后端 400"的联调问题
3
const rules = {
4
  username: [
5
    { required: true, message: '用户名不能为空' },
6
    { min: 2, max: 20, message: '长度 2-20 个字符' },
7
  ],
8
  email: [{ type: 'email', message: '邮箱格式不正确' }],
9
};
10
// 收到 400 时，优先展示后端 message（后端规则更权威）

1
单体：
2
┌─────────────────────────┐
3
│  用户 + 订单 + 支付 + …  │ → 一个数据库
4
└─────────────────────────┘
5

6
微服务：
7
┌──────┐  ┌──────┐  ┌──────┐
8
│用户服务│  │订单服务│  │支付服务│
9
└──┬───┘  └──┬───┘  └──┬───┘
10
   ↓         ↓         ↓
11
 用户库    订单库    支付库
12

13
服务间通信：
14
- 同步：HTTP REST / RPC（Dubbo、gRPC）
15
- 异步：消息队列（RabbitMQ、Kafka、RocketMQ）

1
没有网关：前端要记住 N 个服务地址
2
前端 → 用户服务 :8001
3
前端 → 订单服务 :8002
4
前端 → 支付服务 :8003
5

6
有网关：统一入口
7
前端 → 网关 :8080 → 路由分发到各服务
8

9
网关的职责：
10
1. 路由转发（按路径/Header 分发）
11
2. 统一认证（在网关层校验 Token）
12
3. 限流熔断（保护后端服务）
13
4. 日志监控（统一记录请求日志）
14
5. 协议转换（外部 HTTP → 内部 RPC）
15
6. 跨域处理（统一配置 CORS）
16

17
常见实现：
18
- Nginx / OpenResty（轻量）
19
- Kong（基于 OpenResty，插件丰富）
20
- Spring Cloud Gateway（Java 生态）
21
- APISIX（国产，高性能）

1
消息队列（MQ）：异步通信的中间件
2
生产者 → MQ（队列）→ 消费者
3

4
三大作用：
5
1. 异步：下单后发短信/邮件不用同步等待
6
2. 解耦：订单服务不需要知道谁消费订单消息
7
3. 削峰：秒杀请求先入队，后端按能力消费
8

9
前端相关场景：
10
- WebSocket 推送：后端消费 MQ 消息后推送给前端
11
- 大文件处理：上传视频 → MQ → 转码服务 → 完成后通知前端
12
- 埋点上报：日志采集 → Kafka → 实时计算
13
- 订单状态轮询优化：MQ + WebSocket 替代轮询

1
幂等性：同一请求执行一次和执行多次，结果相同。
2

3
为什么重要？网络超时重试、用户连点、MQ 重复消费都可能导致重复请求。
4

5
场景：
6
- 支付接口重复调用 → 重复扣款！（必须幂等）
7
- 创建订单重复提交 → 重复订单！
8

9
后端方案：
10
1. 唯一索引（数据库层兜底）
11
2. Token 机制：先申请 token，提交时携带并删除（Redis）
12
3. 乐观锁：UPDATE ... SET stock=stock-1 WHERE id=1 AND version=1
13
4. 状态机：订单只能从"待支付"→"已支付"，不可逆
14

15
前端配合：
16
1. 按钮防连点：提交后 loading/disabled
17
2. 唯一请求 ID：生成 requestId 随请求发送
18
3. 防抖节流：搜索框等高频操作

1
// 前端防重复提交示例
2
const submitOrder = async () => {
3
  if (submitting.value) return;
4
  submitting.value = true;   // 立即锁定
5
  try {
6
    await api.createOrder({ ...form, requestId: uuid() });
7
    message.success('提交成功');
8
  } catch (e) {
9
    message.error(e.message);
10
  } finally {
11
    submitting.value = false;
12
  }
13
};

1
限流：控制单位时间的请求数，保护系统不被打垮。
2

3
常见算法：
4
┌────────────┬──────────────────────────────────┐
5
│ 固定窗口    │ 每分钟 N 个请求，简单但有临界问题 │
6
│ 滑动窗口    │ 窗口细分滚动，更平滑              │
7
│ 漏桶       │ 请求入桶匀速流出，强制恒定速率     │
8
│ 令牌桶      │ 匀速发令牌，有令牌才能请求，       │
9
│            │ 允许一定突发流量（最常用）         │
10
└────────────┴──────────────────────────────────┘
11

12
前端遇到 429 Too Many Requests 的处理：
13
1. 指数退避重试：1s → 2s → 4s → 8s
14
2. 读取 Retry-After 响应头
15
3. 请求合并/防抖，减少请求量
16
4. 提示用户稍后再试

1
# 前端 Docker 部署典型 Dockerfile（多阶段构建）
2
# 阶段1：构建
3
FROM node:18-alpine AS builder
4
WORKDIR /app
5
COPY package*.json ./
6
RUN npm ci
7
COPY . .
8
RUN npm run build
9

10
# 阶段2：运行（只拷贝 dist，镜像极小）
11
FROM nginx:alpine
12
COPY --from=builder /app/dist /usr/share/nginx/html
13
COPY nginx.conf /etc/nginx/conf.d/default.conf
14
EXPOSE 80

1
CI（持续集成）：代码提交后自动构建、测试
2
CD（持续部署/交付）：构建产物自动部署到环境
3

4
典型流水线（GitLab CI / GitHub Actions / Jenkins）：
5

6
git push → 触发流水线
7
  ├─ 1. 安装依赖（npm ci，利用缓存）
8
  ├─ 2. 代码检查（ESLint / Prettier / commitlint）
9
  ├─ 3. 单元测试（vitest / jest）
10
  ├─ 4. 构建（npm run build）
11
  ├─ 5. 产物上传（OSS / 镜像仓库）
12
  └─ 6. 部署（测试环境自动 / 生产环境手动审批）
13

14
分支策略配合：
15
- feature/* → 开发分支（自动部署测试环境）
16
- develop   → 集成测试
17
- master/main → 生产发布（打 tag，可回滚）
18

19
回滚方案：
20
1. 保留历史版本 dist 目录，Nginx 切换软链
21
2. Docker 镜像 tag 回退
22
3. CDN 刷新 + 版本回退