AI + 全栈技术栈速查知识图谱

用途：面试前快速回忆、项目复盘和日常排障。每个技术栈都按“知识图谱 → 常用命令 → 核心机制 → 常见易错点 → 面试关注点”组织。

前端主线：React + TypeScript + Next.js。后端主线：Node.js、Python/FastAPI、Go、Java SE。AI 主线：LLM → RAG → Agent/协议 → 微调 → 推理部署。

命令说明：命令按常见 CLI 和 Windows PowerShell 使用方式整理；具体项目应以仓库的 package.json、Makefile、pyproject.toml、Taskfile 或 CI 配置为准。带 $... 的位置是占位符，不要直接复制成真实密钥。

0. 全栈学习路线总图
1. HTML、CSS、浏览器与 Web 性能
2. JavaScript 与 TypeScript
3. React
4. Next.js
5. Node.js
6. Python 与 FastAPI
7. Go
8. Java SE
9. HTTP、认证授权、安全、异步与并发
10. MySQL、PostgreSQL、SQLite 与 SQL
11. Redis 与向量数据库
12. Git 与 Linux
13. Docker、测试、CI/CD 与可观测性
14. LLM、Transformer、Prompt、Tool Calling 与结构化输出
15. RAG：解析、切分、召回、Rerank、引用与评测
16. Agent、LangGraph、Memory、MCP、A2A 与多 Agent
17. LoRA、QLoRA、LLaMA-Factory 与模型部署
18. AI 全栈系统设计与项目落地
19. 算法与数据结构
20. 面试前快速复盘清单

0. 全栈学习路线总图

flowchart LR
    A[浏览器基础] --> B[JavaScript / TypeScript]
    B --> C[React]
    C --> D[Next.js]
    D --> E[Node.js API]
    E --> F[Python / FastAPI]
    E --> G[Go / Java SE]
    F --> H[HTTP / 安全 / 并发]
    G --> H
    H --> I[SQL 数据库]
    I --> J[Redis / 向量数据库]
    J --> K[Git / Linux / Docker / CI]
    K --> L[LLM 应用层]
    L --> M[RAG]
    M --> N[Agent / MCP / A2A]
    N --> O[LoRA / QLoRA / 推理部署]
    O --> P[系统设计 / 评测 / 可观测性]

一句话理解整条路线

浏览器负责呈现 → React 管理交互 → Next.js 组织全栈页面
→ 后端提供可靠 API → 数据库保存事实 → Redis 加速与协调
→ LLM 负责生成与决策 → RAG 提供可检索知识 → Agent 调度工具
→ 工程化保证上线、监控、回滚和持续评测

每层要解决的问题

层次	核心问题	面试时要能说明
浏览器	页面怎么加载、渲染和交互	网络链路、事件循环、性能和可访问性
React/Next.js	如何组织 UI、状态和服务端渲染	render/commit、数据获取、缓存和边界
后端	如何稳定提供业务能力	校验、权限、幂等、超时、错误与并发
数据层	如何保存、查询、加速和恢复	索引、事务、缓存、一致性和迁移
工程化	如何可靠交付	测试、镜像、CI/CD、日志、指标、追踪
AI 应用	如何让模型回答和行动	上下文、RAG、工具、评测、安全和成本

1. HTML、CSS、浏览器与 Web 性能

1.1 知识图谱

HTML 语义结构
  ├─ DOM：节点、属性、事件
  ├─ 可访问性：语义标签、键盘、ARIA、焦点
  └─ SEO：标题、描述、结构化内容

CSS 样式系统
  ├─ Cascade：来源、层级、优先级、继承
  ├─ Layout：正常流、Flex、Grid、定位
  ├─ Paint：颜色、边框、阴影、字体
  └─ Composite：transform、opacity、图层

浏览器运行链路
  ├─ URL → DNS → TCP/TLS → HTTP
  ├─ HTML → DOM；CSS → CSSOM
  ├─ Render Tree → Layout → Paint → Composite
  └─ JS：调用栈 → 事件循环 → DOM/网络副作用

1.2 常用命令与工具

Ctrl + Shift + I                 # 打开 DevTools
Ctrl + Shift + P → Lighthouse    # 运行性能、可访问性、SEO 检查
Ctrl + Shift + P → Disable cache # 仅在 DevTools 打开时禁用缓存，便于排查缓存问题

在 DevTools 中重点看：Network 的 waterfall、Timing、缓存命中、请求大小；Performance 的 Long Task、Layout、Paint；Accessibility 的语义树、名称和键盘焦点。

1.3 核心机制

**语义 HTML：**优先使用 button、nav、main、label 等语义元素；不要用一堆 div 模拟按钮而忘记键盘和读屏行为。
**盒模型：**content-box 和 border-box 会影响实际尺寸；全局样式通常会设置 box-sizing: border-box，但仍要知道它改变了什么。
**Flex 与 Grid：**Flex 更适合一维排列和空间分配；Grid 更适合二维布局。理解主轴、交叉轴、最小尺寸和 min-width: 0 比背属性更重要。
**层叠：**同一属性最终由来源、层级、选择器优先级、源码顺序共同决定；!important 经常只是把样式债务推迟。
**渲染性能：**布局变化可能触发重排，视觉变化可能触发重绘，某些属性只需重新合成。读写布局属性交替执行容易造成强制同步布局。
**资源加载：**preload、prefetch、懒加载和资源优先级要按首屏关键路径使用；不是所有资源都应该提前加载。
**存储：**Cookie 会随请求发送，localStorage 同步且容量有限，IndexedDB 适合更结构化的客户端数据；敏感凭证不能随意放在可被脚本读取的位置。

1.4 常见易错点

z-index 只在相应 stacking context 中比较；元素层级高不代表一定盖住另一个 stacking context。
position: fixed 不一定相对于视口，某些祖先的 transform 会改变包含块。
图片没有尺寸占位会造成 CLS；字体切换、动态广告和异步内容也会造成布局跳动。
CORS 是浏览器策略，不是后端服务之间的通用网络权限机制。
Lighthouse 分数不是业务体验的全部；要结合真实用户的 LCP、INP、CLS 和错误率。

1.5 面试关注点

输入 URL 后到首屏显示的完整链路。
重排、重绘、合成和如何用 Performance 面板定位。
事件冒泡、捕获、事件委托和默认行为。
缓存、CORS、Cookie、Service Worker 的关系。
可访问性不是额外加分项，而是可用性和工程质量的一部分。

2. JavaScript 与 TypeScript

2.1 知识图谱

JavaScript
  ├─ 词法作用域 → 闭包 → 模块
  ├─ 对象模型 → 原型链 → class 语法
  ├─ 执行模型 → 调用栈 → 事件循环 → Promise
  ├─ 数据与内存 → 引用、可变性、垃圾回收
  └─ Web API → DOM、Fetch、Storage、AbortController

TypeScript
  ├─ 类型推断、结构化类型
  ├─ 联合/交叉、泛型、条件类型
  ├─ 类型缩小、类型守卫、穷尽性检查
  └─ 编译期类型 + 运行时 schema 校验

2.2 常用命令

node --version                 # 查看 Node.js 版本，确认项目运行时
npm install                    # 按 package.json 安装依赖；团队项目应优先使用 npm ci
npm ci                         # 按 lock 文件还原，适合 CI 或干净环境
npx tsc --noEmit               # 只做 TypeScript 类型检查，不输出编译文件
npm run build                  # 执行项目定义的生产构建脚本
node --inspect server.js       # 开启调试端口，再用 DevTools 连接排查 Node 代码

2.3 核心机制

**闭包：**函数保存对外层词法环境的引用，适合封装状态，但长期闭包可能持有大对象。
**this：**普通函数由调用方式决定，箭头函数捕获外层 this；不要仅凭函数定义位置判断普通函数的 this。
**原型链：**对象属性查找先看自身，再沿原型向上；class 主要是原型继承的语法糖。
**事件循环：**同步调用栈完成后，微任务通常优先于下一宏任务；无边界微任务可能延迟渲染。
**Promise：**表示未来结果，不自动取消底层操作；网络请求要配合 AbortController 或业务取消机制。
**可变性：**React 和状态管理常依赖引用比较；直接修改对象/数组会让变化不可见或难以追踪。
**TypeScript：**采用结构化类型系统；any 放弃检查，unknown 要先缩小，never 可做穷尽性检查。
**运行时校验：**类型声明会在编译后消失，外部 JSON、用户输入、环境变量仍需要 schema 校验。

2.4 推荐的类型表达方式

// 通过判别字段让 TypeScript 可以在分支内自动缩小类型。
type Result<T> =
  | { ok: true; data: T }
  | { ok: false; code: string; message: string };

function readMessage<T>(result: Result<T>): T | null {
  // ok 是判别字段；进入分支后，data/message 的可用性会被正确推断。
  if (result.ok) return result.data;
  return null;
}

2.5 常见易错点

把 setTimeout(fn, 0) 当成“立刻执行”。
在异步回调中使用旧闭包值，却没有函数式更新或正确同步机制。
用类型断言把不可信数据强行当成目标类型，跳过真正校验。
把 null、undefined、空字符串和缺失字段当成同一种业务状态。
Promise.all 失败时不会自动取消其他已启动任务。
只看 TypeScript 编译通过，就误以为接口数据运行时一定符合类型。

2.6 面试关注点

宏任务/微任务输出顺序。
闭包和循环变量捕获。
原型链、this、call/apply/bind。
Promise 并发、超时、取消、重试。
any/unknown/never、联合类型和运行时校验。

3. React

3.1 知识图谱

React UI
  ├─ JSX → React Element
  ├─ Props / State / Context
  ├─ Render → Reconciliation → Commit
  ├─ Hooks：useState、useEffect、useMemo、useCallback、useRef
  ├─ 状态边界：组件状态 → Context → Zustand/Redux Toolkit
  ├─ 服务端数据：TanStack Query / Server Actions 等
  └─ 性能：memo、代码分割、虚拟列表、缓存、Profiler

3.2 创建、开发与检查

npm create vite@latest web -- --template react-ts  # 创建 React + TypeScript 项目
cd web
npm install                                        # 安装依赖
npm run dev                                        # 启动开发服务器
npm run build                                      # 构建生产产物
npm run lint                                       # 执行项目已配置的 lint 脚本

3.3 核心机制

**组件函数：**输入 props 和可访问状态，返回描述 UI 的 element tree；组件函数执行不是 DOM 更新本身。
**Render/Commit：**render 计算下一棵树，reconciliation 判断节点复用，commit 才把变更提交到 DOM 并处理副作用阶段。
**State：**状态更新会排队并可能批处理；依赖前一个值时用函数式更新，复杂状态可用 reducer。
**Effect：**用于同步外部系统，不要把所有派生计算都放入 effect；清理订阅、定时器和请求。
**Key：**稳定且唯一的业务 ID 决定列表节点身份；随机 key 会让节点每次重建。
**状态管理：**状态应尽量靠近使用它的组件；跨页面服务端数据与本地 UI 状态要分开治理。
**性能：**先用 Profiler 找热点，再选择 memo、稳定引用、虚拟化、懒加载或拆分状态；优化要有指标。
**错误边界：**渲染阶段错误可由 Error Boundary 兜底；网络、事件处理和异步任务需要自己的错误处理。

3.4 Hook 选择速记

Hook	主要用途	不适合做什么
useState	简单局部状态	复杂状态流转和跨层共享
useReducer	有明确事件和状态转移的逻辑	只是一个简单布尔值
useEffect	同步外部系统	计算派生值、替代所有生命周期
useMemo	缓存昂贵计算结果	让普通计算看起来更专业
useCallback	在需要时稳定函数引用	解决所有重新渲染
useRef	DOM、句柄、跨渲染可变值	需要驱动 UI 的状态

3.5 常见易错点

在 effect 中请求数据却没有取消旧请求，导致搜索结果乱序覆盖。
依赖数组漏项，形成 stale closure；或者依赖不稳定对象，造成无限执行。
直接修改 state 对象/数组，引用不变导致更新不可靠。
所有组件都包 memo，但 props 每次都创建新对象/新函数，实际没有收益。
把服务端缓存、表单状态、弹窗状态和全局用户信息混进同一个 store。

3.6 面试关注点

state 批处理和函数式更新。
useEffect 依赖、清理和旧闭包。
reconciliation、key、render/commit。
Context、Zustand/Redux Toolkit、TanStack Query 的边界。
长列表、表单、流式回答和高频输入的性能设计。

4. Next.js

4.1 知识图谱

Next.js
  ├─ App Router / 路由段 / Layout / Loading / Error
  ├─ Server Component ↔ Client Component
  ├─ 渲染：CSR / SSR / SSG / ISR
  ├─ 数据：fetch/cache/revalidate/invalidate
  ├─ Route Handler / Middleware / Server Action
  ├─ SEO：metadata、结构化内容、静态生成
  └─ 部署：Node、容器、边缘运行时、CDN

4.2 常用命令

npx create-next-app@latest app --ts --eslint  # 创建 Next.js + TypeScript 项目
cd app
npm run dev                                   # 开发模式
npm run build                                 # 生产构建，尽早发现服务端/客户端边界问题
npm start                                     # 启动已构建的生产服务
npm run lint                                  # 依赖项目脚本；若项目未配置则不要直接假设存在

4.3 核心机制

**Server/Client 边界：**服务器侧适合数据获取、减少下发 JS 和保护服务端凭证；客户端侧需要事件、浏览器 API、交互状态。
**渲染选择：**静态内容优先 SSG/ISR；必须实时且可服务端生成时用 SSR；强交互、个性化或浏览器依赖的区域可 CSR。
**缓存：**要区分浏览器缓存、CDN 缓存、框架数据缓存和数据库缓存；重新验证策略要和数据更新事件对应。
**路由与错误：**Loading、Error、Not Found 边界应按路由段设计；错误信息对用户稳定，对日志详细。
**API：**Route Handler 适合同一应用内的轻量 API，但长任务、队列消费和模型推理不要无边界塞进页面请求。
**部署：**Node 运行时、边缘运行时和容器环境支持的 API 不同；文件系统、连接复用、环境变量和流式代理都要验证。

4.4 常见易错点

把服务端密钥通过客户端 bundle 或可公开环境变量暴露。
在 Server Component 里使用浏览器 API，或在 Client Component 中无必要地把大数据和依赖下发。
误以为 fetch 总是实时；缓存与 revalidate 要在项目版本和配置下验证。
只在前端做权限判断，服务端页面、API 和数据层没有再次鉴权。
SSE 被代理缓冲，前端看不到实时 token；需要检查响应头、代理和超时。

4.5 面试关注点

CSR/SSR/SSG/ISR 的取舍。
Server/Client Component 的边界。
数据缓存、失效和个性化内容。
首屏性能、SEO、流式渲染和部署限制。

5. Node.js

5.1 知识图谱

Node.js
  ├─ V8：JavaScript 执行与垃圾回收
  ├─ Event Loop：timer / poll / check 等阶段
  ├─ libuv：异步 I/O 与线程池
  ├─ HTTP：request/response、middleware、stream
  ├─ 模块：ESM / CommonJS
  ├─ 进程：cluster、child_process、worker_threads
  └─ 工程：package lock、环境配置、日志、优雅退出

5.2 常用命令

npm init -y                         # 创建 package.json
npm install express                 # 安装运行时依赖，实际项目按框架选择
npm install -D typescript           # 安装开发依赖
node --watch src/server.js          # 开发时监听文件变化；版本不支持时使用项目脚本
node --inspect src/server.js        # 开启调试器
npm audit                           # 查看依赖风险，结果需要人工判断是否可升级

5.3 核心机制

**事件循环：**适合大量 I/O 等待；同步 CPU 计算会阻塞所有连接。
**Stream：**大文件、上传下载和模型流式输出应使用流，避免一次性读入内存；要处理 backpressure。
**错误：**区分同步异常、Promise rejection、请求级错误和进程级致命错误；统一错误中间件不能吞掉所有异常。
**优雅退出：**收到终止信号后停止接收新请求，等待在途请求和消息确认，关闭数据库/Redis/HTTP 客户端，超时后退出。
**Worker：**CPU 密集型任务可用 Worker Threads 或任务队列；不要为了普通 I/O 随意增加线程。
**连接复用：**HTTP keep-alive、数据库连接池和 SDK client 应复用，但要设连接和请求超时。

5.4 常见易错点

async 函数里调用同步文件 API 或大 JSON 序列化。
只设置 socket timeout，没有设置整体请求 deadline。
把未处理 rejection 当成可以忽略的日志问题。
进程重启后内存队列和定时任务丢失，却没有持久化或补偿。
流式响应没有在客户端取消时中止上游模型请求。

5.5 面试关注点

事件循环、微任务、libuv 线程池。
非阻塞 I/O 与 CPU 密集型任务的处理。
Stream/backpressure。
中间件、错误处理、连接池和优雅退出。

6. Python 与 FastAPI

6.1 知识图谱

Python
  ├─ 解释器 / GIL / 引用计数与垃圾回收
  ├─ 模块、包、虚拟环境、类型标注
  ├─ asyncio：event loop、Task、Future
  └─ 数据处理：JSON、文件、HTTP、数据库

FastAPI
  ├─ 路由与 OpenAPI
  ├─ Pydantic：输入/输出 schema
  ├─ Depends：依赖注入与资源生命周期
  ├─ Middleware / Exception Handler
  └─ async I/O / Background Task / 外部队列

6.2 常用命令（PowerShell）

python -m venv .venv                         # 为项目创建隔离环境
\.venv\Scripts\Activate.ps1                 # PowerShell 激活虚拟环境
python -m pip install -U pip                  # 升级当前环境的 pip
python -m pip install fastapi uvicorn         # 安装示例依赖，实际以项目锁文件为准
uvicorn app.main:app --reload                 # 本地开发启动 FastAPI
pytest -q                                     # 运行测试并减少冗余输出
ruff check .                                  # 若项目使用 Ruff，执行静态检查

6.3 核心机制

**虚拟环境：**隔离项目依赖和系统 Python；生产环境需要锁定依赖和可复现安装。
**Pydantic：**在边界进行解析、类型转换和约束；输出 schema 也要定义，避免返回内部对象或敏感字段。
**依赖注入：**适合数据库会话、当前用户、配置、权限和可测试替换的服务。
**async：**只有等待异步 I/O 时才释放事件循环；同步驱动要放线程池或改用异步驱动。
**BackgroundTasks：**适合短小、与当前进程生命周期绑定的任务；可靠长任务应使用队列和持久化状态。
**并发模型：**多 worker 可以提高 CPU 利用，但每个 worker 都可能建立独立连接池和内存，需按数据库承载能力配置。

6.4 常见易错点

在 async def 中直接调用同步 HTTP/数据库客户端。
依赖注入返回的数据库 session 没有在请求结束后释放。
把用户输入直接拼到 SQL、shell 或文件路径。
只捕获 Exception 并返回 200，导致监控看不到真实错误。
Pydantic 模型只用于文档，没有意识到输入转换和额外字段策略会影响安全。

6.5 面试关注点

async/await、事件循环和阻塞边界。
Pydantic schema 与依赖注入。
数据库 session 生命周期、事务和连接池。
Background task 与可靠消息队列的区别。

7. Go

7.1 知识图谱

Go
  ├─ package / module / go.sum
  ├─ struct / interface / composition
  ├─ goroutine / channel / select
  ├─ context：取消、deadline、请求范围
  ├─ error：显式错误、wrap、sentinel
  ├─ net/http：handler、middleware、server
  └─ race detector / test / benchmark / pprof

7.2 常用命令

go version                         # 查看 Go 版本
go mod init example.com/app         # 初始化模块；模块路径按项目真实地址填写
go mod tidy                         # 清理并补齐 go.mod/go.sum 依赖
go run ./cmd/api                    # 运行指定入口
go test ./...                       # 运行所有包测试
go test -race ./...                 # 检测常见数据竞争，成本更高但很有价值
go vet ./...                        # 做静态分析
go build ./cmd/api                  # 构建服务

7.3 核心机制

**goroutine：**轻量但不是无限资源；每个 goroutine 都要有退出路径。
**channel：**适合传递所有权和同步；无缓冲 channel 更强调同步，有缓冲 channel 允许有限排队。
**select：**在多个 channel 操作或取消信号之间选择，常用于超时和退出。
**context：**传递 deadline 和 cancel；不要把 context 存进长期对象，也不要用它传递业务必需参数。
**interface：**隐式满足接口，强调小接口和依赖倒置；接口值还要理解 nil interface 与 typed nil 的区别。
**error：**错误是返回值，使用 wrap 保留上下文；边界层要统一映射 HTTP 错误和内部错误。
**性能工具：**race、benchmark、pprof 用于不同问题；先测量再优化。

7.4 常见易错点

channel 未关闭或消费者永远等待，造成 goroutine 泄漏。
共享 map 并发写没有锁或同步结构。
捕获了 context 取消，却仍继续进行外部副作用。
只用 panic 处理普通业务错误。
把一个大接口传给所有服务，导致实现和测试困难。

7.5 面试关注点

goroutine/channel/select/context。
数据竞争、锁、内存逃逸的基本理解。
HTTP handler、超时、优雅退出。
error wrap、接口设计和测试。

8. Java SE

8.1 知识图谱

Java SE
  ├─ OOP：封装、继承、多态、接口
  ├─ 类型：基本类型、包装类、泛型、类型擦除
  ├─ 集合：List / Set / Map / Queue
  ├─ 异常：checked / unchecked / 自定义异常
  ├─ 并发：Thread / Executor / Future / Lock / volatile
  ├─ JVM：类加载、堆、栈、GC、JIT
  └─ 工具：javac、jar、Maven/Gradle、jstack/jmap/jstat

8.2 常用命令

java -version                  # 查看运行时版本
javac -version                 # 查看编译器版本
javac -d out src\Main.java    # 编译并把 class 输出到 out 目录
java -cp out Main              # 指定 classpath 运行
jar --create --file app.jar -C out .  # 将编译产物打包成 jar
mvn test                       # Maven 项目运行测试
mvn package                    # Maven 项目打包；以项目插件配置为准

8.3 核心机制

**equals/hashCode：**相等对象必须有相等 hash；作为 HashMap key 的对象不要在放入后修改参与计算的字段。
**集合：**ArrayList 随机访问好，LinkedList 并不自动适合所有插入；HashMap 依赖 hash 分布，TreeMap 维护有序。
**泛型：**主要是编译期约束，运行时存在类型擦除；通配符要区分生产者和消费者。
**异常：**异常分层应表达可恢复性；不要用异常作为普通分支，也不要捕获后静默吞掉。
**线程池：**需要明确队列、最大线程数、拒绝策略、任务超时和关闭方式；线程数不是越大越好。
**JMM：**可见性、原子性和有序性是不同问题；volatile 提供部分可见性/有序性，不提供复合操作原子性。
**JVM：**堆存放对象，栈与线程调用相关；GC、类加载和 JIT 会影响延迟与吞吐，排查要看实际指标。

8.4 常见易错点

用 == 比较对象内容。
只知道 HashMap 平均 O(1)，却忽略 hash 冲突、扩容和并发安全。
把 volatile count++ 当成线程安全自增。
线程池没有上限、队列无限增长，最终造成内存或延迟问题。
修改公共 API 的异常语义，却没有兼容调用方。

8.5 面试关注点

集合选型、equals/hashCode、泛型擦除。
线程池、锁、volatile、并发容器。
JVM 内存区域、GC 和线上排查思路。
异常边界与接口设计。

9. HTTP、认证授权、安全、异步与并发

9.1 知识图谱

网络与 API
  ├─ DNS → TCP → TLS → HTTP
  ├─ 方法 / 状态码 / Header / Body
  ├─ REST / RPC / SSE / WebSocket
  ├─ Cache / CORS / Cookie / Compression
  └─ Timeout / Retry / Circuit Breaker / Backpressure

身份安全
  ├─ Authentication：确认是谁
  ├─ Authorization：允许做什么
  ├─ Session / JWT / OAuth2 / Refresh Token
  ├─ RBAC / ABAC / Resource Ownership
  └─ XSS / CSRF / SQLi / SSRF / Injection

9.2 常用命令

curl.exe -I https://example.com                 # 只查看响应头，检查缓存、重定向和安全头
curl.exe -v https://example.com/api/health       # 查看请求/响应细节，排查 TLS、连接和状态码
curl.exe -N https://example.com/api/stream       # 尝试不缓冲读取 SSE；具体参数取决于服务端
Test-NetConnection example.com -Port 443         # Windows 检查 TCP 端口是否可达
openssl s_client -connect example.com:443       # 查看 TLS 握手和证书；本机需安装 OpenSSL

9.3 核心机制

**幂等：**相同请求重复执行不改变最终状态；创建、支付、任务提交要使用幂等键、唯一约束和状态机。
**超时：**连接超时、读取超时和整体 deadline 不同；每层都要有预算，不能让重试把总耗时无限放大。
**重试：**只重试临时错误，采用指数退避和抖动；写操作必须确认幂等。
**限流：**按用户、租户、IP、API key 或资源维度限制；要区分突发容量和长期平均速率。
**认证授权：**登录后仍要做资源归属和动作权限检查；前端隐藏按钮不是授权。
**Cookie/CSRF：**浏览器自动带 Cookie 的场景要评估 CSRF；SameSite、CSRF token 和 Origin 校验要组合使用。
**SSE/WebSocket：**要处理心跳、重连、消息 ID、顺序、客户端取消、连接上限和代理配置。
**并发：**并发任务需要取消、超时、背压和最大并行度，避免异步变成无限放大。

9.4 常见易错点

把 HTTP 401 和 403 混用：前者通常表示未认证，后者通常表示已认证但无权。
把 CORS 当成服务端到服务端的安全边界。
把 JWT payload 当成加密数据，放入密码、密钥或敏感信息。
无限重试 5xx 或限流错误，造成雪崩。
GET 接口产生写副作用，却没有幂等和 CSRF 设计。

9.5 面试关注点

HTTP 方法、状态码、缓存和幂等性。
JWT、Session、refresh token 和注销。
CORS、CSRF、XSS、SQL 注入、SSRF。
SSE/WebSocket 和流式接口。
超时、重试、限流、熔断和并发上限。

10. MySQL、PostgreSQL、SQLite 与 SQL

10.1 知识图谱

关系型数据库
  ├─ 表 / 行 / 列 / 主键 / 外键 / 约束
  ├─ SQL：SELECT / JOIN / GROUP / ORDER / Window
  ├─ 索引：B+Tree / Hash / GIN 等
  ├─ 事务：ACID / 隔离级别 / MVCC / 锁
  ├─ 性能：EXPLAIN / 慢日志 / 连接池 / 分页
  └─ 运维：备份 / 恢复 / 迁移 / 读写分离 / 分区

选型
  ├─ MySQL：成熟通用 OLTP
  ├─ PostgreSQL：复杂查询、扩展、类型和一致性能力
  └─ SQLite：嵌入式、单文件、开发/测试/本地场景

10.2 常用命令

mysql -h $DB_HOST -u $DB_USER -p                         # 连接 MySQL；密码不要写在命令行历史里
psql -h $DB_HOST -U $DB_USER -d $DB_NAME                 # 连接 PostgreSQL
sqlite3 app.db                                           # 打开 SQLite 文件

# SQL：先查看执行计划，再决定是否改索引或改写查询。
EXPLAIN SELECT id, title FROM documents
WHERE tenant_id = 42 AND created_at >= '2026-01-01'
ORDER BY created_at DESC LIMIT 20;

10.3 核心机制

**约束优先：**主键、唯一、非空、外键和检查约束把业务不变量下沉到数据库，应用校验不能完全替代约束。
**B+Tree：**适合等值、范围和排序；联合索引要关注最左匹配、列顺序、选择性和覆盖查询。
**事务：**事务边界要尽量小；大事务会持锁、占日志、增加回滚成本。
**隔离：**不同数据库实现细节不同；回答隔离级别时要结合 MVCC、锁和快照，不要只背四个名字。
**EXPLAIN：**关注访问类型、估算/实际行数、索引、排序、临时表、回表和连接顺序。
**分页：**深分页用游标或基于稳定排序的 keyset pagination；返回结果要有上限。
**迁移：**数据库迁移要可重复、可审计、向前兼容；字段新增、双写、回填、切读和删除应分阶段。
**连接池：**连接数受数据库资源、查询耗时和应用并发共同约束；连接池过大不是性能优化。

10.4 常见易错点

给低选择性字段单独建很多索引，却没有结合真实查询。
在索引列上使用函数或隐式类型转换，导致无法有效使用索引。
只查到命中了索引，却没有检查回表、排序和实际扫描行数。
把数据库事务和消息队列/缓存更新当成天然原子操作。
线上直接执行不可逆的大表 DDL，没有锁影响和回滚预案。

10.5 面试关注点

B+Tree、联合索引和最左匹配。
ACID、隔离级别、MVCC、锁。
慢查询和执行计划排查。
深分页、N+1、大事务和连接池。
MySQL/PostgreSQL/SQLite 的场景选型。

11. Redis 与向量数据库

11.1 知识图谱

Redis
  ├─ String / Hash / List / Set / Sorted Set / Stream
  ├─ TTL / Eviction / Persistence
  ├─ Cache Aside / Write Through / Write Behind
  ├─ Counter / Rate Limit / Lock / Queue
  └─ Hot Key / Big Key / Penetration / Breakdown / Avalanche

向量数据库
  ├─ Document → Chunk → Embedding
  ├─ Distance：cosine / dot product / Euclidean
  ├─ ANN：HNSW / IVF / PQ
  ├─ Metadata Filter / Tenant / Version
  ├─ Hybrid Search / Rerank
  └─ Upsert / Delete / Rebuild / Recall Evaluation

11.2 常用命令

redis-cli ping                                      # 检查 Redis 是否可用
redis-cli SET demo:key "value" EX 60               # 写入并设置 60 秒 TTL；避免永久缓存
redis-cli GET demo:key                              # 读取字符串值
redis-cli TTL demo:key                              # 查看剩余过期时间
redis-cli SCAN 0 MATCH "user:*" COUNT 100          # 分批扫描；不要在线上用 KEYS * 阻塞实例
redis-cli INFO memory                               # 查看内存概况

如果使用 PostgreSQL + pgvector，可用类似 SQL 验证向量能力（距离运算符随实现和索引配置而定）：

-- 只展示思路：真实项目需要确认 vector 维度、索引类型和距离定义。
SELECT id, content
FROM chunks
WHERE tenant_id = 42
ORDER BY embedding <=> :query_embedding
LIMIT 10;

11.3 核心机制

**Cache Aside：**读时先查缓存，未命中查数据库并回填；写时通常先写数据库再删除/更新缓存。
**TTL：**缓存必须有过期策略；热点 key 可采用逻辑过期、预热和互斥重建。
**分布式锁：**要有唯一 token、过期和安全释放；长任务要考虑续期和 fencing token。
**Stream：**适合带消费组的消息流，但仍要处理 pending、重试、幂等和积压。
**向量距离：**模型训练目标和查询距离要一致；不同 embedding 模型的向量空间不能直接混用。
**HNSW：**通过图结构换取近似搜索速度；构建/查询参数影响召回、内存和延迟。
**Metadata：**租户、权限、版本、语言和时间过滤必须进入检索条件，而不是事后再过滤。
**混合检索：**关键词保证精确词命中，向量负责语义召回，再通过融合和 Rerank 提升候选质量。

11.4 常见易错点

用 KEYS 扫描生产 Redis，造成阻塞。
不设置 TTL，缓存逐渐变成第二个数据库。
value 过大、集合过大，形成 big key；热 key 让单实例成为瓶颈。
删除文档后只删业务库，向量索引仍能召回旧内容。
不记录 embedding 模型/版本，升级后把不同向量空间混在一起。
先全库召回再做租户过滤，带来数据泄漏风险。

11.5 面试关注点

Redis 数据结构和使用场景。
缓存穿透、击穿、雪崩。
TTL、淘汰、热 key、big key。
分布式锁与一致性边界。
向量、ANN、metadata filter、混合召回和 Rerank。

12. Git 与 Linux

12.1 知识图谱

Git
  ├─ 工作区 → 暂存区 → 本地提交 → 远程分支
  ├─ branch / switch / merge / rebase
  ├─ log / diff / bisect / stash
  ├─ revert / reset / cherry-pick
  └─ tag / release / hook / CI

Linux 排障
  ├─ 进程：ps / top / tasklist
  ├─ 网络：ss / curl / Test-NetConnection
  ├─ 磁盘：df / du / Get-PSDrive
  ├─ 日志：journalctl / tail / rg
  └─ 权限与文件：ls / chmod / find / Get-ChildItem

12.2 Git 常用命令

git status                                      # 先确认当前分支、修改和未跟踪文件
git switch -c feature/ai-search                 # 基于当前提交创建并切换新分支
git diff                                        # 查看工作区未暂存差异
git diff --cached                                # 查看已加入暂存区的差异
git add path/to/file                             # 只暂存确认过的文件
git commit -m "feat: add retrieval pipeline"    # 提交一个意图清晰的变更
git log --oneline --graph --decorate -20         # 快速查看提交拓扑
git fetch --prune                                # 更新远端引用并清理失效分支
git rebase origin/main                           # 个人分支同步基线；共享分支前先确认协作规则
git revert <commit>                              # 为公共历史创建反向提交
git show <commit>                                # 查看特定提交内容

12.3 Linux/PowerShell 排障命令

Get-ChildItem -Force                              # 查看当前目录（含隐藏项）
Get-ChildItem -Recurse -File | Select-Object FullName  # 查找文件；大目录要缩小范围
Get-Process                                       # 查看进程
Get-NetTCPConnection -State Listen                # 查看监听端口
Get-PSDrive                                       # 查看磁盘空间
Select-String -Path .\logs\app.log -Pattern "ERROR|timeout"  # 搜索关键日志
curl.exe -v http://localhost:8000/health          # 从当前机器验证接口

12.4 核心机制与易错点

Git 的提交是快照，分支是指向提交的引用；理解指针比背命令更重要。
rebase 会改写提交 ID，不要未经确认改写公共分支。
revert 通常适合已推送历史；reset 要先确认是否会丢工作区或提交。
排障先固定时间范围、服务实例和请求 ID，再看日志；不要直接把所有日志全量复制出来。
df 看文件系统剩余空间，du 看目录占用；空间不足还要排查日志、临时文件和已删除但仍被进程打开的文件。
任何删除、移动或批量修改前先确认精确路径，避免把工作区或用户目录当成目标。

12.5 面试关注点

工作区、暂存区、本地分支和远程分支的关系。
merge/rebase、reset/revert/cherry-pick 的适用场景。
如何用进程、端口、磁盘、日志和请求 ID 排查服务。

13. Docker、测试、CI/CD 与可观测性

13.1 知识图谱

交付链路
  ├─ 代码 → 格式/lint → 单元测试 → 集成测试 → E2E
  ├─ 依赖锁定 → 构建镜像 → 安全扫描
  ├─ 灰度/滚动发布 → 健康检查 → 分批放量
  └─ 指标/日志/追踪 → 告警 → 回滚/复盘

Docker
  ├─ Dockerfile → Image → Container
  ├─ Volume：持久化
  ├─ Network：服务发现
  ├─ Compose：本地/简单编排
  └─ Registry：版本化产物

13.2 Docker 常用命令

docker build -t ai-api:dev .                    # 根据 Dockerfile 构建镜像
docker images                                     # 查看本地镜像
docker run --rm -p 8000:8000 ai-api:dev          # 临时启动容器；-p 映射端口
docker ps                                         # 查看运行中的容器
docker logs -f <container>                        # 跟随容器日志
docker exec -it <container> sh                   # 进入容器排查；生产镜像可能没有 bash
docker compose up -d                             # 启动 compose 定义的服务
docker compose ps                                # 查看服务状态
docker compose logs -f api                       # 只跟随 api 服务日志
docker compose down                              # 停止并移除本次 compose 创建的容器和网络

13.3 测试命令速查

npm test                                         # 前端/Node：以项目脚本为准
pytest -q                                        # Python
go test ./...                                    # Go
mvn test                                         # Java/Maven

13.4 核心机制

**镜像不可变：**运行时配置通过环境或 secret 注入；不要把密钥、日志和数据库数据写进镜像层。
**多阶段构建：**编译镜像和运行镜像分开，减小体积和攻击面；最终镜像尽量使用非 root 用户。
**测试分层：**单元测试验证逻辑，集成测试验证真实依赖适配，E2E 验证关键用户路径；契约测试适合稳定 API 边界。
**CI/CD：**依赖锁定、静态检查、测试、构建、安全扫描、部署、健康检查和回滚应自动化。
**健康检查：**liveness 判断进程是否活着，readiness 判断是否可以接流量；依赖暂时不可用时不要让探针造成重启风暴。
**三类可观测性：**日志回答“发生了什么”，指标回答“是否正在变坏”，追踪回答“请求在哪里变慢/失败”。
**AI 专属观测：**模型版本、Prompt 版本、token、检索候选、Rerank、工具调用、结构化校验和人工反馈要能关联到 trace。

13.5 常见易错点

使用 latest 镜像标签导致无法复现和回滚。
把 secrets 写到 Dockerfile、前端环境变量或 CI 日志。
只测成功路径，不测超时、空结果、部分失败、重试和取消。
指标没有版本、租户、接口或模型维度，出了问题无法切片。
只看平均耗时，忽略 P95/P99、队列等待和首 token 延迟。

13.6 面试关注点

Docker 镜像/容器/Volume/Network。
测试金字塔和 Mock 边界。
CI/CD、灰度、健康检查和回滚。
日志/指标/追踪以及 AI 质量指标如何接入。

14. LLM、Transformer、Prompt、Tool Calling 与结构化输出

14.1 知识图谱

用户请求
  ├─ Tokenizer → token 序列
  ├─ Prompt 编排：系统约束 / 用户输入 / 外部数据
  ├─ Transformer：Embedding → Attention → FFN → logits
  ├─ Decoding：temperature / top-p / stop / max tokens
  └─ 输出
      ├─ 文本
      ├─ JSON Schema
      ├─ Tool Call → 服务端校验 → 工具执行 → 结果回传
      └─ Stream Event → SSE/WebSocket → 前端

14.2 常用命令与调用检查

python -m pip install tiktoken                    # 仅示例：不同模型需使用匹配 tokenizer
python -c "print('check runtime')"               # 快速确认 Python 运行环境

# OpenAI-compatible API 的通用形状；endpoint、模型名和字段以实际供应商文档为准。
curl.exe -X POST "$env:LLM_BASE_URL/v1/chat/completions" -H "Authorization: Bearer $env:LLM_API_KEY" -H "Content-Type: application/json" -d '{"model":"$env:LLM_MODEL","messages":[{"role":"user","content":"hello"}],"stream":true}'

上面的命令只用于说明调用形状：不要把真实 API key 写进脚本、仓库、前端 bundle 或截图。

14.3 核心机制

**Token 与上下文：**成本、延迟和窗口按 token 计算；中文、代码、JSON 的 token 分布可能不同，不能只按字符估算。
**Attention：**Query/Key/Value 计算 token 间相关性；多头、残差、归一化和位置编码共同构成 Transformer 的核心。
**解码：**temperature/top-p 影响采样随机性；低温度不等于事实正确，高温度也不等于更有创造力就适合业务。
**Prompt 分层：**稳定指令与动态数据分开；文档、网页和工具结果应标记为不可信数据，不能直接当系统指令。
**结构化输出：**schema 约束、服务端二次校验、有限重试和降级共同保证可靠性。
**Tool Calling：**模型提出调用意图，服务端负责鉴权、参数校验、限流、幂等、执行和结果回传。
**流式：**事件需要区分 token、工具调用、引用、错误、完成和 usage；半个 JSON、代理缓冲和客户端取消都要处理。
**质量/成本/延迟：**模型路由、上下文压缩、缓存、并发、输出上限和降级要一起设计。

14.4 常见易错点

把模型输出当成事实数据库，不做检索、工具查询或引用校验。
把 JSON mode 当成业务 schema 校验，忽略字段缺失、类型错误和枚举非法。
重试写工具调用，导致重复扣款、重复发信或重复创建任务。
缓存 key 没有包含模型版本、Prompt 版本、权限和租户维度。
只统计总响应时间，不统计首 token 延迟、生成耗时和队列等待。

14.5 面试关注点

token、logits、采样参数和上下文窗口。
Attention 与 Transformer 的直观机制。
结构化输出、工具调用和流式协议。
Prompt Injection、成本、延迟、评测和降级。

15. RAG：解析、切分、召回、Rerank、引用与评测

15.1 知识图谱

离线索引链路
  ├─ 文件接入 → 类型识别 → 解析/OCR
  ├─ 清洗 → 结构化 → 标题/页码/权限/版本元数据
  ├─ Semantic Chunking → Embedding
  └─ Vector Index + Keyword Index

在线查询链路
  ├─ 原始问题 → 改写/分解/过滤
  ├─ Keyword Recall + Vector Recall
  ├─ Fusion → Rerank → Top-K
  ├─ 权限与版本校验 → Context Budget
  ├─ LLM 生成 → 引用校验 → 流式返回
  └─ 评测：Retrieval / Generation / System

15.2 常用命令与操作

RAG 没有跨所有向量数据库通用的一套 CLI，最常用的是通过项目脚本和数据库控制台验证各阶段：

python scripts/ingest.py --source .\docs --version v1       # 批量解析并建立指定版本索引
python scripts/retrieve.py --query "退款规则" --top-k 20    # 查看原始召回候选
python scripts/evaluate.py --dataset .\eval\rag.jsonl      # 运行离线评测集
docker compose logs -f indexer                              # 查看异步索引任务日志

15.3 核心机制

**解析：**PDF、扫描件、表格、代码和网页需要不同解析器；解析错误会在后续所有阶段放大。
**切分：**优先按标题、段落、列表和代码块等语义边界，再控制 token 上限和 overlap；要保留来源位置。
**Embedding：**用自己的查询—文档标注集评估 Recall@K、MRR、nDCG 和跨语言表现；模型升级要版本化。
**混合召回：**关键词擅长精确术语和编号，向量擅长语义近似；融合后再 Rerank，不能只看单一分数。
**权限过滤：**租户、用户、文档版本和有效期要在检索层生效；应用层事后过滤可能已经造成泄漏。
**上下文编排：**去重、排序、压缩、预算和冲突文档处理比塞更多文本更重要。
**引用：**chunk 携带文档 ID、版本、页码/段落和权限；生成后检查引用是否存在且支持陈述。
**评测：**拆分检索质量、生成 groundedness、答案相关性、引用准确性、延迟、成本和安全性。
**更新：**新版本索引构建完成后再切换；删除要可靠，不能只删业务表不删向量。

15.4 RAG 排障顺序

1. 文件是否被正确解析？
2. chunk 是否保留了必要标题、表格和上下文？
3. 查询是否命中正确租户、版本和权限范围？
4. 关键词/向量召回是否覆盖答案证据？
5. Rerank 是否把关键证据排到前面？
6. Context 是否被截断、去重或冲突文档污染？
7. Prompt 是否要求基于证据回答和正确引用？
8. 模型、缓存、索引和 Prompt 版本是否发生变化？

15.5 常见易错点

只用固定字符数切文档，切断标题、表格、代码或步骤关系。
只看向量相似度，不看真实召回覆盖率和权限过滤。
把 Rerank 当作召回不够的万能修复；候选集没有证据时 Rerank 也救不了。
让模型自由生成引用编号，不校验编号与原文证据。
评测集只包含简单问题，线上难例和拒答样本一来质量马上下降。

15.6 面试关注点

完整 RAG 链路和每环的观测数据。
chunk、embedding、混合召回、Rerank。
metadata filter、版本、删除和多租户隔离。
引用可靠性、Lost in the Middle 和分层评测。

16. Agent、LangGraph、Memory、MCP、A2A 与多 Agent

16.1 知识图谱

Agent 系统
  ├─ 输入理解 → 计划/决策 → 工具调用 → 观察结果
  ├─ 状态：messages / task / artifacts / errors / budget
  ├─ 控制：State Graph / 条件边 / 最大步数 / 超时
  ├─ 记忆：短期上下文 / 摘要 / 长期事实 / 用户偏好
  ├─ 可靠性：checkpoint / retry / idempotency / human approval
  ├─ MCP：Agent ↔ 外部工具/资源/提示的协议化连接
  ├─ A2A：Agent ↔ Agent 的能力发现、委派与任务交付
  └─ 多 Agent：分工 / 并行 / 汇总 / 冲突处理 / 终止条件

16.2 常见操作与调试资料

python -m pip install langgraph                  # 仅示例；项目应按锁文件安装
python scripts/run_agent.py --trace-id demo-1    # 用固定 trace 运行一次，便于回放
docker compose logs -f agent                    # 查看 Agent 运行日志
curl.exe http://localhost:8000/health            # 检查 Agent 服务是否就绪

工具 schema 示例：

{
  "name": "search_documents",
  "description": "在当前用户有权访问的文档范围内检索信息",
  "input_schema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "minLength": 1 },
      "top_k": { "type": "integer", "minimum": 1, "maximum": 20 }
    },
    "required": ["query"]
  }
}

16.3 核心机制

**Workflow vs Agent：**步骤固定、分支可枚举时优先 Workflow；开放式任务才让模型动态选择。
**状态图：**节点做一类责任，边表达条件和转移；状态 schema 要明确，不能把所有内容放到无约束消息列表。
**Checkpoint：**保存可恢复状态和版本，支持暂停、人工审批、重放和审计；恢复时要避免重复副作用。
**短期记忆：**当前任务消息、工具结果、进度和摘要；要有 token 预算和过期策略。
**长期记忆：**有价值、可解释、可删除的用户事实或偏好；写入要经过敏感性、权限和冲突判断。
**MCP：**协议化暴露 tools/resources/prompts，解决集成标准化；执行安全仍由服务端负责。
**A2A：**强调 Agent 能力发现、任务委派、状态和结果交付；要定义身份、超时、取消和验证。
**多 Agent：**只在角色/工具/上下文确实不同且可以并行时使用；要控制通信次数和总预算。
**工具可靠性：**schema、鉴权、参数白名单、超时、重试、幂等、审计和人工确认缺一不可。

16.4 常见易错点

把无限 while 循环包装成 Agent，却没有最大步数和总预算。
工具返回的网页/文档内容被模型当成高优先级指令。
Agent 恢复时重复执行发送邮件、写数据库等副作用。
长期记忆没有删除、纠错、过期和租户隔离机制。
多 Agent 只是增加角色名称，没有清晰任务契约和汇总规则。
MCP/A2A 协议接通后，误以为权限、审计和网络隔离已经自动解决。

16.5 面试关注点

Agent 和确定性 Workflow 的边界。
状态图、checkpoint、人工介入和重放。
短期/长期记忆与 token 控制。
MCP、A2A 的定位及其不负责的安全问题。
工具调用的幂等、重试、超时、审计和沙箱。

17. LoRA、QLoRA、LLaMA-Factory 与模型部署

17.1 知识图谱

模型适配决策
  ├─ Prompt：规则、格式、少量行为调整
  ├─ RAG：实时知识、权限检索、引用
  └─ Fine-tune：稳定风格、格式、行为或领域模式

训练链路
  ├─ 数据清洗/去重/脱敏/划分
  ├─ SFT 或偏好数据
  ├─ LoRA：低秩 adapter
  ├─ QLoRA：量化基础模型 + LoRA
  ├─ 验证集评测 → 安全回归 → adapter/模型版本
  └─ 合并/量化/服务化/灰度/回滚

推理服务
  ├─ tokenizer / weights / quantization
  ├─ batching / KV cache / GPU memory
  ├─ streaming / timeout / concurrency
  └─ TTFT / TPOT / throughput / P95 / cost

17.2 常用命令（按安装版本调整）

llamafactory-cli train path\to\lora_sft.yaml      # 使用配置文件启动 LoRA/QLoRA 训练
llamafactory-cli export path\to\merge_lora.yaml  # 合并 adapter 或导出部署格式
vllm serve <model-path> --served-model-name ai-model --max-model-len 8192  # 启动示例

训练和部署命令高度依赖 GPU、量化后端、CUDA、模型格式和框架版本。面试时应说明：命令是入口，实际还要根据显存、上下文长度和服务指标调参。

17.3 核心机制

**LoRA：**冻结基础模型，在目标层学习低秩更新，训练参数和显存显著减少。
**QLoRA：**低比特加载基础模型，再训练 LoRA adapter，进一步降低显存，但依赖量化实现和硬件兼容性。
**数据：**真实分布、难例、拒答、格式一致性、去重、脱敏、独立验证集比盲目调参更重要。
**量化：**降低显存和带宽，但可能影响长上下文、工具调用、中文和边界任务；要用任务集验证。
**合并：**adapter 可运行时加载或合并到基础模型；合并后要校验权重、tokenizer、版本和许可证。
**推理：**预填充处理输入，解码逐 token 生成；KV cache、连续批处理和并发队列影响吞吐和延迟。
**指标：**首 token 延迟（TTFT）、每 token 延迟（TPOT）、总延迟、吞吐、GPU 利用率、队列等待、显存和成本。
**发布：**模型、adapter、tokenizer、Prompt、评测集和运行参数都要版本化，支持灰度和回滚。

17.4 常见易错点

用训练集评测，误以为模型提升；没有独立验证集和回归集。
只看 loss，不看任务准确性、格式遵循、拒答和工具成功率。
忽略最大序列长度、padding、梯度累积和显存峰值。
量化后没有验证真实业务数据和长上下文。
推理服务把并发拉高，却没有控制队列、超时和单租户公平性。

17.5 面试关注点

Prompt/RAG/Fine-tune 的选型边界。
LoRA 与 QLoRA 的原理和显存取舍。
训练数据、评测污染、过拟合和回归。
量化、KV cache、batching、TTFT/TPOT 和部署回滚。

18. AI 全栈系统设计与项目落地

18.1 通用 AI 应用架构图

flowchart TB
    U[React / Next.js] --> G[API Gateway]
    G --> A[Auth / Tenant / Rate Limit]
    A --> Q[Query Orchestrator]
    Q --> R[Hybrid Retrieval]
    R --> V[(Vector DB)]
    R --> S[(SQL / Metadata)]
    Q --> M[Model Router]
    M --> L[LLM / Self-hosted Model]
    L --> T[Tool Executor]
    T --> X[(External Systems)]
    Q --> E[Evaluation / Citation / Guardrail]
    E --> O[Stream Response]
    O --> U
    G --> OBS[Logs / Metrics / Traces]
    Q --> JOB[Queue / Indexing Workers]
    JOB --> V

18.2 设计时固定回答的 10 个问题

用户是谁，租户边界和权限从哪里来？
请求是同步短任务，还是异步长任务？
哪些数据必须实时，哪些可以最终一致？
关键链路的 P95 延迟和成本预算是多少？
模型失败、限流、超时和输出非法时怎么降级？
工具是只读还是写操作？写操作怎样幂等和审批？
RAG 证据怎样被过滤、排序、引用和更新？
日志是否包含敏感信息？怎样脱敏和审计？
如何做离线评测、线上反馈和版本回归？
发布失败后怎样止损、回滚和补偿？

18.3 常见系统设计模式

企业知识库问答

上传 → 解析/OCR → 清洗 → 结构化切分 → embedding/index
查询 → 鉴权/租户过滤 → 混合召回 → Rerank → 上下文预算
生成 → 引用校验 → SSE 流式返回 → 反馈/评测/追踪

流式 Agent 任务

创建 task → 返回 task_id
→ 状态机执行：计划/工具/等待审批/恢复/完成
→ 事件总线推送进度
→ checkpoint 支持断点恢复
→ 最终结果持久化并可重放

多租户隔离

身份 claims → tenant_id
→ API 权限 → 数据库条件 → 缓存 key → 向量 filter
→ 对象存储路径 → 异步任务 → 日志与评测数据

18.4 项目表达模板

背景：谁遇到什么问题，原流程的成本/延迟/错误是什么？
目标：要优化哪些可量化指标？
架构：数据从哪里来，经过哪些服务和存储？
难点：最难的一个问题是什么，为什么不能直接套模板？
贡献：我负责了哪些设计、编码、排障和验证？
结果：质量、性能、成本、稳定性分别有什么变化？
复盘：现在重做会改变什么，下一步如何演进？

18.5 常见易错点

只画“前端—后端—大模型”三层，没有权限、索引、队列、缓存、错误和观测。
只谈模型效果，不谈 token 成本、延迟、并发、失败和回滚。
把多租户只做在 UI，不做在数据库、缓存、向量和异步任务。
把 Agent 的动态性当成系统设计的全部，忽略固定流程和状态机更可控。
介绍项目时只讲技术名词，没有个人贡献和可验证结果。

18.6 面试关注点

端到端链路是否闭环。
权限、幂等、重试、超时和最终一致性。
AI 质量、成本、延迟、可观测性和安全。
方案取舍和未来扩展，而不是技术堆砌。

19. 算法与数据结构

19.1 知识图谱

数组/字符串
  ├─ 双指针、滑动窗口、前缀和、差分
  └─ 二分查找、排序、哈希
链表/队列/栈
  ├─ 反转、快慢指针、单调栈
  └─ LRU、BFS
树/图
  ├─ DFS、BFS、拓扑排序
  ├─ 二叉搜索树、堆、并查集
  └─ 最短路、连通性
动态规划
  ├─ 状态定义
  ├─ 转移方程
  ├─ 初始化/遍历顺序
  └─ 空间压缩

19.2 复杂度速查

结构/模式	常见时间	常见空间	关键前提
哈希表查找	平均 O(1)	O(n)	哈希分布和容量合理
二分查找	O(log n)	O(1)	有序或满足单调性
滑动窗口	O(n)	O(k)	窗口不变量可增量维护
堆 Top-K	O(n log k)	O(k)	只保留 K 个候选
BFS/DFS	O(V+E)	O(V)	图或树遍历
归并排序	O(n log n)	O(n)	稳定、适合外部归并
LRU	平均 O(1)	O(capacity)	哈希表 + 双向链表

19.3 常见易错点

没有先定义区间、窗口或 DP 状态的含义。
二分边界和循环不变量前后不一致。
BFS 忘记何时标记 visited，导致重复入队。
递归深度、栈空间和输入规模不匹配。
只说“大概 O(n)”，没有说明排序、哈希、堆或额外空间成本。

19.4 面试关注点

两数之和、频次统计、Top-K。
二分查找、旋转数组、边界定位。
滑动窗口、最长子串、最小覆盖。
链表反转、环、合并、LRU。
二叉树遍历、岛屿/连通分量、BFS 最短步数。
经典动态规划的状态、转移和空间压缩。

20. 面试前快速复盘清单

20 分钟版

5 分钟：React render/commit、useEffect、Next.js 渲染模式。
5 分钟：HTTP/JWT/权限/幂等/限流/SSE。
5 分钟：索引/事务/Redis 缓存/RAG 混合召回。
5 分钟：Tool Calling、Agent 状态、成本、评测和项目数字。

60 分钟版

浏览器与 JS：URL 链路、事件循环、Promise、TypeScript 运行时校验。
React/Next.js：状态边界、数据缓存、服务端/客户端边界、性能。
后端：超时、重试、并发、资源池、错误码、优雅退出。
数据：索引、事务、缓存一致性、向量版本和权限过滤。
工程：Docker、测试、CI/CD、日志/指标/追踪和回滚。
AI：LLM 上下文、结构化输出、RAG、Agent、微调、模型服务。

最后自问

我能否把每个技术名词放回完整请求链路？
我能否说出它的边界、失败模式和监控指标？
我能否解释为什么选择 React，而不是把所有状态都塞进一个全局方案？
我能否解释为什么某个问题用 RAG、工具或固定 Workflow，而不是直接微调或上 Agent？
我能否把项目经历说成“问题—决策—实现—验证—结果”？

返回顶部