D

RuntimeScope / 面试专题

后端面试 8 周冲刺

从中级知识点背诵,升级到高级 / 资深后端的系统表达能力。8 周内产出项目讲稿、系统设计题库、故障案例库、Go / 数据链路 / AI 工程问答。

8 周
冲刺节奏
110-130
算法题
6 套
系统设计
5-8
故障故事
2
核心项目讲稿
1 套
AI 工程问答
interview command center2026 backend
当前状态从中级复习方式切换到系统表达
本周动作题型复盘 + Go/数据链路快问快答
关键产物项目讲稿 / 系统设计 / 故障故事
高级信号取舍、稳定性、治理、AI 工程化

第一屏 · 这套路线解决什么

失败点通常不是不努力,而是仍用中级方式准备高级岗位

高级 / 资深面试看的是能不能把知识点放回系统、业务、故障和长期治理里。

中级准备方式

  • 背八股和定义,但说不出业务场景。
  • 刷题能过样例,但边界条件和复杂度解释不稳。
  • 项目只讲做了哪些接口,不会讲取舍、故障和治理。
  • 把 AI 当模型科普,不会讲成后端工程系统。

高级 / 资深准备方式

  • 能把系统复杂度、容量、压测、容灾放进同一条链路讲。
  • 能解释为什么选择 Redis、MQ、索引、限流和降级,也能解释为什么不用其他方案。
  • 能把线上故障按指标、日志、trace、止血、根因和长期机制复盘。
  • 能把 RAG、tool calling、eval、安全和成本讲成可观测、可回滚的后端系统。

第二屏 · 8 周路线总览

每周都有目标、学习内容、动作、产出和验收标准

这不是计划表,而是把学习动作和最终面试资产绑定的作战地图。

第 0 天:开工准备

day-0

先把复习资产和项目方向搭起来,避免 8 周里只输入不沉淀。当天要建立仓库、目录、题单、简历初版和错题清单。

学什么

backend-interview-2026 仓库8 个主题目录主项目方向简历 v1错题与不会答清单

Day 0 · 建立面试仓库和复盘系统

  • - 创建 backend-interview-2026,包含 algo/go/os/network/mysql/redis_mq/distributed/ai 目录。
  • - 准备算法题单、系统设计题库、故障故事模板、学习打卡表。
  • - 确定一个主项目和一个 AI 分支项目,写出业务目标、用户场景、核心链路。

产出什么

仓库与目录项目方向简历 v1学习打卡表错题和不会答清单

验收标准

能打开仓库看到 8 个目录能说清主项目题目有简历 v1 和打卡表

第 1 周:打地基

week-1

把基础题型、Go 基础、OS/网络入门和 AI 术语讲清楚,从什么都懂一点变成能说出机制和边界。

学什么

复杂度数组/双指针/滑动窗口/哈希/链表Go 基础进程线程协程HTTP/TCP/DNS/CDNLLM/token/context/embedding

工作日 · 基础输入和口述

  • - 每天 1 道新算法题 + 1 道旧题复盘
  • - 手写 Go slice/map/error/interface 小 demo
  • - 口述浏览器访问接口链路

周末 · 项目第一版定义

  • - 写需求、接口列表、数据表草图和整体架构图
  • - 整理 18-22 道算法题复盘

产出什么

基础题型模板Go 基础问答项目 v0 架构图AI 基础术语卡

验收标准

能判断基础题型能解释边界条件项目有第一版定义

第 2 周:Go 与树题入门

week-2

把栈、队列、树遍历和 Go 并发基础连起来,能解释 goroutine/channel/select/context 如何支撑服务并发。

学什么

栈/队列二叉树 DFS/BFS/层序/路径题goroutine/channel/selectWaitGroup/mutex/rwmutex/contextHTTP keep-alive/Linux 排查RAG 入门

前半周 · 树和并发基本功

  • - 刷树遍历和路径题
  • - 手写 worker goroutine + channel + WaitGroup demo
  • - 解释 channel 和 mutex 的适用场景

后半周 · 项目可运行

  • - 实现用户模块、登录注册、中间件、配置加载
  • - 写 RAG 是什么、prompt/few-shot/hallucination 的区别

产出什么

树题模板Go 并发 demo项目可运行版本RAG 入门说明

验收标准

goroutine/channel/select 会用项目能跑起来能解释 RAG 是什么

第 3 周:MySQL 数据库周

week-3

把 MySQL 从概念背诵升级为查询路径、事务可见性、锁范围和慢 SQL 排查闭环。

学什么

B+ 树索引聚簇索引/二级索引/回表/覆盖索引联合索引/最左前缀/explain/join事务/隔离级别/MVCC/ReadView二分/BSTembedding/semantic search

周一至周三 · 索引和事务

  • - 画出二级索引回表路径
  • - 用 explain 分析 3 条 SQL
  • - 口述 RC 和 RR 的 ReadView 创建时机

周四至周日 · 项目接入 MySQL

  • - 项目接入 MySQL
  • - 写慢 SQL 排查流程
  • - 补 Go context 取消传播、超时控制、panic/recover

产出什么

MySQL 深问答案explain 分析记录项目 MySQL 模块embedding 检索说明

验收标准

能解释聚簇索引和回表能解释联合索引命中能解释 MVCC 和 RR 解决什么问题

第 4 周:Redis + MQ + 中间件

week-4

把缓存和消息队列讲成工程链路:读路径、写路径、一致性、幂等、积压和止血方案。

学什么

Redis string/hash/list/set/zset过期策略/淘汰策略/RDB/AOF穿透/击穿/雪崩/热 key/大 key分布式锁MQ 削峰/解耦/异步重复消费/顺序消息/幂等/积压

缓存链路 · Redis 设计和排查

  • - 为项目加登录态缓存和热点数据缓存
  • - 写命中率下降排查流程
  • - 解释 RDB/AOF 取舍

消息链路 · MQ 可靠性

  • - 设计异步任务和幂等方案
  • - 写重复消费、死信、补偿答案
  • - 补 heap/TopK/BFS/DFS 综合题

产出什么

缓存设计说明MQ 幂等方案Redis/MQ 排障清单tool calling 基础问答

验收标准

能解释 Redis 为什么快能解释缓存击穿怎么解决能解释为什么需要 MQ 和重复消费如何处理

第 5 周:分布式与系统设计

week-5

把微服务、限流熔断降级、容量规划和一致性讲成高级面试需要的取舍表达。

学什么

微服务拆分RPC vs HTTP注册发现/负载均衡限流/熔断/降级/隔离CAP/BASE/分库分表/一致性 hash图论/并查集/拓扑排序RAG 完整链路

系统设计 · 6 套核心题起稿

  • - 按业务目标、规模预估、核心链路、数据模型、风险点写题库
  • - 重点演练秒杀和企业知识库问答

项目治理 · 稳定性方案

  • - 给项目补限流、熔断、降级说明
  • - 写高并发场景和容量估算
  • - 补 sync.Once/sync.Map/atomic/逃逸分析

产出什么

系统设计题库初稿项目高并发说明RAG 完整链路图Go 高级同步问答

验收标准

能讲秒杀系统怎么设计能讲 Redis+MQ+MySQL 如何配合能讲 RAG 为什么不是简单塞文档

第 6 周:AI 工程周

week-6

把 AI 相关内容按后端工程系统复习,覆盖 RAG、工具调用、Agent、eval、安全、成本和延迟。

学什么

chunk/topK/metadata filter/reranktool calling/function calling/tool schemaAgent state/loop/handoffEvalsprompt injection/越权工具调用/数据泄漏prompt caching/latency/token cost/fallback

RAG 系统 · 构建 AI 分支项目

  • - 实现文档上传、embedding、检索、回答、日志和 fallback
  • - 记录 retrieval hit rate、answer accuracy、latency、token cost

工具与安全 · 工具调用和防护

  • - 写 tool schema 和权限校验
  • - 设计 prompt injection 防护
  • - 说明 RAG vs fine-tuning

产出什么

AI 工程问答RAG demotool calling 流程eval 指标表安全边界清单

验收标准

能解释 embeddings能解释 tool calling 流程能解释 eval 为什么重要能解释 prompt caching 怎么优化成本

第 7 周:项目深挖

week-7

把项目从做了什么接口升级为业务背景、架构演进、核心取舍、线上问题、指标变化和后续治理。

学什么

业务背景/用户场景/架构图核心链路/为什么这么设计/方案对比Go GC/pprof/逃逸分析/内存分配线上问题故事高频 5 层追问技术债治理/跨团队推进

项目表达 · 3/8/15 分钟三版讲稿

  • - 写 3 分钟开场版
  • - 写 8 分钟深挖版
  • - 写 15 分钟高级/资深版

追问演练 · 连续追问和故障故事

  • - 演练为什么用 Redis/MQ、一致性怎么保证、下游挂了怎么办
  • - 写一个完整线上问题排查故事

产出什么

2 个项目讲稿5 层追问脚本故障故事 v1性能排查答案

验收标准

项目能讲 8 分钟不卡壳能顶住 5 层连续追问能讲完整线上问题排查故事

第 8 周:真面试冲刺

week-8

把算法、Go、数据库、系统设计、AI、HR 和项目表达组合成模拟面试节奏,最后沉淀可复用资产。

学什么

算法模拟Go/数据库/系统设计/AI 模拟HR+技术综合简历优化反问问题错题回看

模拟面试 · 按面试轮次压测

  • - medium 题限时 20-30 分钟
  • - 项目 3 分钟版和 8 分钟版各讲 2 次
  • - 高频八股快问快答

最终整理 · 沉淀面试资产

  • - 整理最终 mock 复盘表
  • - 更新简历
  • - 确认短板表和反问清单

产出什么

最终简历mock 复盘表短板表反问清单最终面试资产包

验收标准

medium 题 20-30 分钟可写高频八股能答 70%+AI 基础题不空白

第三屏 · 高级 / 资深能力地图

六条主线决定你能不能从会背升级到会设计、会排障、会治理

每条主线都要有核心知识点、高频问题、表达要求和最终产出。

系统设计

核心知识点

业务目标规模预估容量规划高并发下单秒杀/抢券搜索/推荐链路企业知识库问答

高频问题

如何防超卖?如何降级?如何估 QPS/P99/存储增长?旧架构为什么不行?

不要上来画 Redis 和 MySQL,先讲约束、核心链路、数据一致性和风险边界。

最终产出: 6+ 套系统设计题,每套都有规模、链路、数据模型、风险和扩展路径。

数据链路

核心知识点

MySQL 索引/MVCC/锁Redis 缓存MQ 幂等Outbox最终一致性

高频问题

联合索引顺序怎么排?回表怎么减少?缓存双写怎么保证?死信和补偿怎么做?

把查询路径、缓存命中、消息投递和一致性补偿放在同一条业务链路里讲。

最终产出: MySQL/Redis/MQ 深问答案和一套数据链路排障清单。

Go 工程

核心知识点

goroutinechannelmutexcontextpprofGC逃逸分析JSON 编解码成本

高频问题

goroutine 泄漏怎么查?channel 和 mutex 怎么选?RT 从 20ms 到 300ms 怎么排查?

从服务稳定运行出发,讲并发控制、取消传播、资源释放和性能证据。

最终产出: Go 高级问答、pprof 排查链路和性能优化方法论。

稳定性

核心知识点

指标日志trace告警分级限流熔断隔离降级重试边界

高频问题

高 RT 先看哪里?错误率上升如何缩小范围?大促前如何保障?

先止血,再定位根因,最后补长期治理;每一步都要有指标依据。

最终产出: 5-8 个故障故事和一套可观测性/告警/演练模板。

项目表达

核心知识点

业务背景系统规模职责架构演进方案对比技术债治理跨团队推进

高频问题

为什么不用别的方案?如何灰度?如何回滚?如果重做会怎么改?

把项目讲成业务价值、技术判断、线上反馈和长期演进,不是接口流水账。

最终产出: 2 个核心项目的 3 分钟、8 分钟、15 分钟讲稿。

AI 工程

核心知识点

RAGembeddingtool callingAgentevalprompt injectionprompt cachinglatency

高频问题

RAG 为什么会答错?RAG vs fine-tuning 怎么选?如何防止工具越权?

按后端系统讲:状态、权限、日志、评估、成本、超时、重试和 fallback。

最终产出: 1 套 AI 工程化问答和一个可演示的 RAG/工具调用项目。

第四屏 · 知识正文

每个主题都按面试目标、核心解释、追问、回答骨架和项目落地点整理

内部链接只作为配套 Lab,不替代正文。打开这一页就能站内复习。

算法

算法

算法题型地图与复盘方法

展开正文

算法不是逐题背答案,而是建立题型地图。二分解决有序或答案单调空间里的范围收缩,滑动窗口解决连续区间约束,回溯解决选择树枚举,DP 解决有重叠子问题的最优或计数。面试时先说搜索空间、状态、转移或指针含义,再写代码。

面试要会什么

  • - 能用 110-130 题覆盖主流题型,并把至少 40 题重复复盘到能口述。
  • - 能判断题型、写模板、解释复杂度和边界条件。

高频追问

  • - 这题为什么是滑动窗口而不是双指针?
  • - 二分的 l <= r 和 l < r 怎么选?
  • - DP 状态怎么定义?
  • - 图题怎么判断 BFS、DFS、拓扑排序或并查集?

标准回答骨架

  • - 先判断输入结构和目标:连续区间、树/图、组合枚举、最优子结构。
  • - 再给模板:指针移动、队列/栈、递归回溯、dp 数组或堆。
  • - 最后讲复杂度、边界条件、代表题和错题复盘。

项目落地点

  • - 算法复盘记录用 Go 手写,保留失败样例和边界样例。
  • - 项目中把 TopK、图依赖、队列消费和限流窗口当作业务算法场景讲。

覆盖知识点

时间复杂度空间复杂度数组双指针滑动窗口哈希表链表队列二叉树BFSDFS回溯二分堆 / TopK图论并查集拓扑排序动态规划 DP110-130 题复盘题 40+

Go

Go

Go 并发、context 与服务稳定运行

展开正文

goroutine 是轻量并发执行单元,不等于线程。channel 更适合表达任务流、数据流、生产消费和事件通知;mutex 更适合保护共享状态,不要为了用 channel 而用 channel。context 用于请求级取消、超时、截止时间和链路传递,父 context 取消后子链路也应该停止,否则容易形成 goroutine 泄漏。

面试要会什么

  • - 能解释 Go 服务为什么稳定运行,不是只会写语法。
  • - 能说清 goroutine/channel/mutex/context 的选择和泄漏风险。

高频追问

  • - goroutine/channel/mutex 怎么选?
  • - context 父子取消怎么传播?
  • - goroutine 泄漏场景有哪些?
  • - Go memory model 说的可靠观察条件是什么?

标准回答骨架

  • - 并发选择先看数据是流动还是共享:流动用 channel,共享状态用 mutex/rwmutex/atomic。
  • - 所有下游 HTTP/RPC/DB 请求接收 context,超时后释放资源。
  • - 用 WaitGroup 管生命周期,用 select 监听退出,用 profile 查泄漏。

项目落地点

  • - 项目异步任务用 worker pool 控制并发量。
  • - 请求链路用 context 贯穿 DB、Redis、MQ 和下游调用。
  • - 共享缓存统计用 mutex 或 atomic,不把 channel 当万能锁。

覆盖知识点

slicearraymapstructmethodinterfaceerror 处理goroutinechannelselectsync.WaitGroupmutexrwmutexcontextGo memory modelgoroutine 泄漏worker pool并发任务控制优雅退出单元测试panic / recoversync.Oncesync.Mapatomic

Go

Go 性能排查:RT 从 20ms 涨到 300ms

展开正文

pprof 不是最后贴图,而是性能排查证据。CPU profile 看 CPU 时间花在哪里,heap profile 看内存分配热点,goroutine profile 看数量、阻塞位置和泄漏风险,block/mutex profile 辅助定位阻塞和锁竞争。GC 会影响延迟,短命对象、大对象、频繁分配和 JSON 编解码都会增加 GC 压力。

面试要会什么

  • - 能用指标和 pprof 证明性能问题,而不是先猜原因。
  • - 能解释 GC、内存分配、逃逸分析和 JSON 编解码成本。

高频追问

  • - Go 接口 RT 从 20ms 涨到 300ms 怎么排查?
  • - CPU profile 和 heap profile 分别看什么?
  • - GC 问题为什么不能只说自动回收?
  • - slice 扩容和逃逸分析怎么影响性能?

标准回答骨架

  • - 看入口指标:RT、QPS、错误率、P99,确认是否发布后出现。
  • - 看 CPU、内存、GC、goroutine、锁竞争和连接池。
  • - 看 DB/Redis/MQ/下游、日志和 trace,再用 pprof 验证,最后给止血和长期治理。

项目落地点

  • - 为核心接口建立压测基线。
  • - 保存一次 pprof 分析记录和优化前后 P99 指标。
  • - 把 JSON 编解码、连接池、锁竞争作为项目追问素材。

覆盖知识点

pprofCPU profileheap profilegoroutine profileblock profilemutex profileGC内存分配逃逸分析slice 扩容JSON 编解码成本RTP99连接池

OS / 网络

OS / 网络

OS 与网络:一次接口访问发生了什么

展开正文

后端网络题不要写成百科。浏览器访问接口时先做 URL 解析和 DNS 解析,再建立 TCP 连接、TLS 握手、发送 HTTP 请求,经过 CDN、反向代理、网关/负载均衡到后端服务,服务再访问 DB/Redis/MQ/下游并返回响应。排障时要看 DNS 是否慢、连接是否复用、TLS 握手是否过多、Go HTTP 连接池是否打满、下游是否超时。

面试要会什么

  • - 能把浏览器访问接口的全链路讲清楚。
  • - 能从网络角度排查后端接口 RT 变高。

高频追问

  • - 浏览器访问一个接口发生了什么?
  • - HTTP keep-alive、TCP keepalive、连接池有什么区别?
  • - cookie/session/token 怎么选?
  • - 网络角度如何排查 RT 变高?

标准回答骨架

  • - 按 URL/DNS/TCP/TLS/HTTP/代理/服务/依赖/响应顺序讲链路。
  • - 鉴权先分清 cookie 是存储机制、session 是服务端状态、token 常用于无状态鉴权。
  • - 排障按 DNS、连接复用、TLS、连接池、丢包抖动、反向代理、网关和下游超时收敛。

项目落地点

  • - 项目接口说明里补充网关、反向代理、鉴权和连接池配置。
  • - 为压测和线上排障准备网络层 checklist。

覆盖知识点

进程线程协程用户态内核态Linux 常见命令文件权限进程查看网络排查HTTP 请求流程HTTP 状态码HTTP keep-alivecookiesessiontokenTCP 三次握手TCP 四次挥手DNSCDN反向代理TLS 证书链Go HTTP 连接池

分布式

分布式

分布式与系统设计取舍

展开正文

微服务拆分不是越细越好,要按业务边界、团队边界、数据边界和变更频率拆。RPC 更适合服务间调用和治理,HTTP 更通用、生态广、跨语言调试方便。限流控制入口流量,熔断在下游异常时快速失败,降级牺牲非核心功能保核心链路,隔离避免一个模块拖垮全局。CAP 不是背 C/A/P,而是在网络分区不可避免时说明一致性和可用性的取舍。

面试要会什么

  • - 能把分布式概念放进业务约束和风险边界。
  • - 能讲容量规划、容灾、多机房和技术债治理。

高频追问

  • - 为什么现在要拆微服务,为什么不是一开始就拆?
  • - RPC vs HTTP 怎么选?
  • - 限流/熔断/降级/隔离有什么区别?
  • - 容量规划怎么做?
  • - 容灾和多机房怎么讲?

标准回答骨架

  • - 先讲业务约束和规模,再讲服务边界、数据边界和治理成本。
  • - 一致性题用 CAP/BASE、状态机、幂等、重试和补偿回答。
  • - 容量题估 QPS、峰值、P99、存储增长、连接数、队列长度,再讲压测和冗余水位。

项目落地点

  • - 项目讲稿里加入容量预估、限流降级、容灾演练和技术债治理。
  • - 系统设计题都要写成本与复杂度,不能只画组件。

覆盖知识点

微服务拆分RPC vs HTTP服务注册发现负载均衡限流熔断降级隔离幂等重试补偿CAPBASE分布式锁分库分表一致性 hash容量规划压测容灾多机房技术债治理跨团队推进水位线资源冗余故障域单点多副本

稳定性

稳定性

稳定性、可观测性与故障排查

展开正文

可观测性三件套里,指标看趋势和异常,日志看具体错误和上下文,trace 看链路耗时和依赖调用。高 RT 排查先看全局还是单接口、P50/P90/P99、QPS、错误率、发布记录和 trace 中耗时最高节点,再看 DB/Redis/MQ/下游、CPU/内存/GC/goroutine 和连接池。处理顺序是先止血,再定位根因,再长期治理。

面试要会什么

  • - 能按指标、日志、trace 缩小故障范围。
  • - 能把高 RT、高错误率和大促保障讲成闭环。

高频追问

  • - RT 变高先看哪里?
  • - 错误率上升如何缩小范围?
  • - 发布后错误率上升怎么办?
  • - 大促前如何保障?

标准回答骨架

  • - 先分级:P0 核心链路不可用,P1 核心指标异常,P2 局部功能异常,P3 风险提示。
  • - 高错误率看错误码、接口、机器/机房/版本、日志、下游和重试放大。
  • - 大促前做容量评估、压测、限流、熔断、降级、预热、监控大盘、值班、回滚和演练。

项目落地点

  • - 每个核心项目至少准备一个 P99 或错误率优化故事。
  • - 把监控指标、日志字段、trace 关键 span 写进讲稿。

覆盖知识点

指标日志trace告警分级高 RT 排查高错误率排查CPU 飙高内存上涨连接池打满goroutine 暴涨DB 慢Redis 抖动MQ 堵塞下游超时发布后错误率上升大促前保障P0P1P2P3监控大盘回滚方案应急预案演练

AI

AI

AI 工程:RAG、embedding 与 eval

展开正文

embedding 是文本、图片等内容的向量表示,向量距离可以表示语义相似度,常用于搜索、推荐、聚类和 RAG 检索,但 embedding 不是答案生成。RAG 链路包括文档上传、解析、chunk 切分、embedding、向量库、问题 embedding、向量检索、metadata filter、rerank、拼上下文、LLM 生成、引用、日志、eval 和持续优化。

面试要会什么

  • - 能把 RAG 讲成后端系统,不是模型科普。
  • - 能解释 RAG 为什么会答错以及如何评估。

高频追问

  • - RAG 为什么会答错?
  • - RAG vs fine-tuning 怎么选?
  • - chunk 大小和 topK 怎么定?
  • - 没召回或召回错了怎么办?
  • - eval 为什么重要?

标准回答骨架

  • - RAG 先讲完整链路,再讲错误来源:切分差、没召回、噪音、topK、filter、rerank、prompt、幻觉、权限、上下文过长。
  • - RAG 解决外部知识检索,fine-tuning 主要解决风格、格式和行为一致性。
  • - eval 要有测试集、ground truth 或评分规则,看 retrieval hit rate、answer accuracy、latency、token cost 和失败率。

项目落地点

  • - AI 分支项目要有上传、检索、回答、引用、日志和 fallback。
  • - 每次 prompt/模型/检索策略变化后做回归测试。

覆盖知识点

LLMtokencontextembeddingsemantic searchRAGchunktopKmetadata filterrerank拼上下文RAG 为什么会答错RAG vs fine-tuningevalanswer accuracyretrieval hit ratelatencytoken costfallback

AI

AI 工程:tool calling、Agent、安全与成本

展开正文

模型自己不真正执行外部动作。tool calling/function calling 是让模型按 tool schema 选择工具并生成调用参数,后端负责执行工具、校验权限、处理结果、审计日志和失败处理,再把结果返回给模型。Agent 包含目标、状态、工具、循环、记忆、handoff 和评估。prompt caching 依赖精确前缀匹配,静态内容放前面、动态内容放后面,可以降低延迟和成本。

面试要会什么

  • - 能解释模型、后端工具执行和权限边界的分工。
  • - 能把 Agent 讲成状态机和可观测系统。

高频追问

  • - tool calling 和普通 prompt 的区别?
  • - 如何防 prompt injection?
  • - 工具越权和数据泄漏怎么防?
  • - Agent 和简单 prompt 的区别?
  • - prompt caching 怎么优化成本?

标准回答骨架

  • - 工具调用按 schema、模型选择、后端执行、权限校验、结果回填、失败处理和审计日志讲。
  • - 安全上把文档内容当数据不当指令,工具最小权限,敏感操作二次确认,输出过滤。
  • - 成本上裁剪 RAG 结果,共享静态前缀,控制超时、重试和 fallback。

项目落地点

  • - 为 AI 项目写 tool schema、权限边界、审计日志和失败处理。
  • - 把 prompt injection 案例加入安全问答。

覆盖知识点

tool callingfunction callingtool schematool 选择tool 返回结果怎么喂回模型stateloophandoffAgentprompt injection越权工具调用数据泄漏权限边界prompt caching静态前缀前置动态内容后置RAG 结果裁剪超时重试fallback审计隔离

项目

项目

项目表达:3 分钟、8 分钟、15 分钟

展开正文

项目表达不是接口清单,而是业务背景、用户场景、系统规模、你的职责、架构图、核心链路、为什么这样设计、方案对比、技术取舍、核心难点、线上问题、排查过程、优化结果、指标变化和后续演进。高级/资深还要讲旧架构为什么不行、为什么当时必须改、如何平滑迁移、容量规划、技术债治理和跨团队推进。

面试要会什么

  • - 能把项目讲成高级/资深面试模板。
  • - 能顶住为什么、怎么保证、如果重做的连续追问。

高频追问

  • - 为什么用 Redis?
  • - 为什么用 MQ?
  • - 一致性怎么保证?
  • - 下游挂了怎么办?
  • - 流量暴涨怎么办?
  • - 如何灰度和回滚?
  • - 为什么不用别的方案?
  • - 如果现在重做你会怎么改?

标准回答骨架

  • - 3 分钟版:业务背景、系统目标、我的职责、核心设计、最有价值结果。
  • - 8 分钟版:业务规模、架构设计、核心链路、难点、取舍、线上问题、优化结果、后续演进。
  • - 15 分钟版:旧方案问题、约束、新方案、替代方案、灰度迁移、稳定性、数据结果和技术判断。

项目落地点

  • - 每个项目讲稿都要附指标变化和一个故障故事。
  • - 把高频追问写成问答卡,每周至少讲 1 次项目。

覆盖知识点

业务背景用户场景系统规模你的职责架构图核心链路为什么这么设计方案对比技术取舍核心难点遇到的问题排查过程优化结果指标变化后续演进Mock 冲刺3 分钟版8 分钟版15 分钟版容量规划灰度回滚

系统设计题库

每套题都按业务目标、规模预估、核心链路、数据模型、一致性和风险追问组织

高级面试看的是约束下的取舍,而不是把组件名堆满画布。

高并发下单 / 秒杀 / 抢券系统

系统设计

在短时间高峰中完成商品详情展示、限购、防刷、库存扣减、订单创建和支付超时关闭,核心目标是不超卖、可降级、可恢复。

规模预估

  • - 估 QPS、峰值、P99、库存规模、订单写入量、Redis 和 MQ 水位。
  • - 区分详情页读流量和下单写流量,秒杀入口单独限流。

核心链路

  • - 商品详情缓存和库存预热
  • - 用户限购和幂等下单
  • - Redis 扣减库存后写订单
  • - MQ 异步削峰
  • - 支付超时关闭和库存回补

数据模型

  • - 商品表、库存表、订单表、支付单、限购记录、幂等键表。

缓存设计

  • - 商品详情多级缓存
  • - 热点库存预热
  • - 热点商品本地缓存和限流保护。

一致性设计

  • - 库存以 MySQL 为最终事实,Redis 承担高峰扣减前置;失败通过 MQ、补偿和对账修正。

异步化设计

  • - 订单创建、支付超时、库存回补、通知用 MQ 异步处理。

风险点

  • - 超卖
  • - 重复点击
  • - 热点 key
  • - MQ 丢失
  • - 下游支付慢
  • - 秒杀链路被刷

扩展路径

  • - 从单体同步下单演进到缓存预热、队列削峰、异步补偿和对账机制。

成本与复杂度

  • - 强一致会牺牲吞吐;完全依赖 Redis 会增加恢复和对账成本。

高频追问

如何防止超卖?Redis 扣库存后 MySQL 失败怎么办?MQ 消息丢了怎么办?热点商品怎么处理?秒杀链路如何降级?

通知 / 消息中心

系统设计

统一站内信、短信、邮件和 push,保证模板可管理、发送可追踪、失败可重试、用户不被骚扰。

规模预估

  • - 估日发送量、峰值触发量、渠道吞吐、失败率和重试堆积。

核心链路

  • - 业务创建发送请求
  • - 模板渲染
  • - 用户订阅偏好过滤
  • - MQ 投递
  • - 多渠道发送
  • - 状态回写

数据模型

  • - 模板表、用户偏好表、发送任务表、发送记录表、渠道回执表。

缓存设计

  • - 模板和用户偏好缓存
  • - 限频计数器
  • - 渠道配置缓存。

一致性设计

  • - 发送记录用幂等键去重,渠道回执异步修正状态。

异步化设计

  • - MQ 异步发送、失败重试、死信队列和补偿任务。

风险点

  • - 重复发送
  • - 服务商故障
  • - 重试风暴
  • - 骚扰用户
  • - 状态不可追踪

扩展路径

  • - 从业务直调短信演进为统一消息平台和多渠道治理。

成本与复杂度

  • - 同步发送体验确定但拖慢主链路;异步发送需要幂等和状态追踪。

高频追问

如何保证消息不重复发送?短信服务商挂了怎么办?如何避免骚扰用户?如何做消息状态追踪?

用户中心 / 鉴权 / 权限系统

系统设计

支持注册、登录、多端登录、token/session、refresh token、RBAC、OAuth/SSO 和接口级权限校验。

规模预估

  • - 估登录 QPS、活跃会话数、权限校验 QPS、token 刷新峰值。

核心链路

  • - 登录认证
  • - 签发 token/session
  • - 登录态缓存
  • - RBAC 权限校验
  • - 风险控制
  • - 权限变更生效

数据模型

  • - 用户表、账号凭证表、角色表、权限表、用户角色关系、refresh token 表、登录设备表。

缓存设计

  • - 登录态缓存
  • - 权限缓存
  • - 风控计数器
  • - token 黑名单。

一致性设计

  • - 权限变更通过版本号、缓存失效和短 token 生命周期保证及时生效。

异步化设计

  • - 登录日志、风控事件、通知和审计异步化。

风险点

  • - token 泄漏
  • - 权限缓存不一致
  • - 多端踢下线
  • - 密码安全
  • - 接口级权限遗漏

扩展路径

  • - 从简单登录演进为 RBAC、SSO、多端设备和审计系统。

成本与复杂度

  • - session 易失效控制但需要存状态;token 适合分布式但吊销和泄漏治理更复杂。

高频追问

token 泄漏怎么办?session 和 token 怎么选?RBAC 怎么设计表?权限变更后如何实时生效?

内容发布与异步处理系统

系统设计

让内容创建、草稿、发布、审核、索引构建、Feed 分发和图片/视频处理可异步、可补偿、可追踪。

规模预估

  • - 估发布 QPS、审核耗时、媒体处理耗时、索引延迟和 Feed 分发规模。

核心链路

  • - 内容创建
  • - 草稿保存
  • - 发布申请
  • - 审核
  • - 状态机推进
  • - 异步构建搜索索引和 Feed
  • - 失败补偿

数据模型

  • - 内容表、草稿表、审核记录、状态流转表、媒体任务表、索引同步任务。

缓存设计

  • - 内容详情缓存
  • - 作者内容列表缓存
  • - 审核状态短缓存。

一致性设计

  • - 用状态机表达发布中、审核中、已发布、失败和回滚,避免布尔状态混乱。

异步化设计

  • - 媒体处理、搜索同步、Feed 分发和通知通过 MQ 异步。

风险点

  • - 同步动作过多拖慢发布
  • - 审核失败回滚
  • - 索引同步失败
  • - 用户看到不一致状态

扩展路径

  • - 从同步发布演进为状态机 + MQ + 补偿任务。

成本与复杂度

  • - 强实时发布成本高;异步发布要明确用户可见状态和补偿机制。

高频追问

内容发布后为什么不能所有动作同步做?搜索索引同步失败怎么办?状态机怎么设计?

搜索 / 推荐链路

系统设计

支持内容入库、索引构建、搜索召回、排序过滤、推荐召回、粗排、精排、缓存、实时性和可观测性。

规模预估

  • - 估搜索 QPS、索引数据量、召回候选数、排序耗时和缓存命中率。

核心链路

  • - 内容入库
  • - 索引构建
  • - 查询召回
  • - 排序过滤
  • - 推荐特征
  • - 粗排精排
  • - 降级返回

数据模型

  • - 内容表、倒排索引、特征表、用户行为表、召回日志、排序实验记录。

缓存设计

  • - 热门搜索结果缓存
  • - 推荐候选缓存
  • - 特征缓存。

一致性设计

  • - 索引允许短暂延迟,核心是可观测和补偿重建。

异步化设计

  • - 内容变更异步同步索引和特征,推荐链路可异步预计算。

风险点

  • - 搜索结果延迟更新
  • - 召回异常
  • - 推荐耗时高
  • - 冷启动
  • - 降级质量差

扩展路径

  • - 从关键词搜索演进到多路召回、排序、特征和实验平台。

成本与复杂度

  • - 实时性越高成本越大;缓存越强实时性越弱。

高频追问

搜索结果延迟更新怎么办?推荐链路耗时高怎么优化?如何排查召回异常?如何处理冷启动?

结算 / 对账系统

系统设计

保证订单、支付、退款、账单和三方渠道金额一致,异常可发现、可冻结、可补偿。

规模预估

  • - 估日交易量、支付回调峰值、账单规模、对账窗口和异常比例。

核心链路

  • - 支付回调
  • - 订单状态更新
  • - 账务流水
  • - 日终对账
  • - 差异识别
  • - 补偿或人工处理

数据模型

  • - 订单表、支付流水、退款流水、账务流水、对账批次、差异单。

缓存设计

  • - 核心金额不依赖缓存决策,缓存只做查询和状态展示。

一致性设计

  • - 金额链路优先强约束和幂等,跨系统通过最终一致、对账和补偿兜底。

异步化设计

  • - 回调处理、账务入账、对账任务和通知异步化。

风险点

  • - 重复回调
  • - 金额不一致
  • - 三方延迟
  • - 补偿失败
  • - 并发退款

扩展路径

  • - 从支付回调直改订单演进到流水、状态机、对账和差异治理。

成本与复杂度

  • - 强一致链路成本高;最终一致必须有对账和冻结机制。

高频追问

支付回调重复怎么办?订单和支付状态不一致怎么办?对账差异怎么处理?

企业知识库问答系统

系统设计

让企业文档可上传、解析、检索、回答、引用、控权、评估和审计,而不是只做一个聊天框。

规模预估

  • - 估文档数量、总 token、chunk 数、检索 QPS、模型延迟、向量库成本和权限过滤成本。

核心链路

  • - 文档上传
  • - 文档解析
  • - chunk 切分
  • - embedding
  • - 向量检索
  • - metadata filter
  • - rerank
  • - prompt 拼接
  • - LLM 生成
  • - 引用来源

数据模型

  • - 文档表、chunk 表、向量索引、权限 ACL、问答日志、eval 样本。

缓存设计

  • - 静态系统提示词缓存
  • - 热门问题结果缓存
  • - 权限上下文短缓存。

一致性设计

  • - 权限过滤必须在检索前后都校验,删除文档后向量索引要最终一致清理。

异步化设计

  • - 文档解析、embedding、索引构建和 eval 任务异步化。

风险点

  • - 没召回
  • - 召回噪音
  • - 越权访问
  • - prompt injection
  • - token 成本高
  • - 回答无引用

扩展路径

  • - 从单轮 RAG 演进到权限过滤、rerank、eval、日志审计和 fallback。

成本与复杂度

  • - topK 过大会增加噪音和成本;过小会漏召回。高实时索引会增加异步复杂度。

高频追问

RAG 和 fine-tuning 怎么选?chunk 大小怎么定?如何评估回答质量?如何防止越权访问文档?如何做 fallback?

故障案例库

故障故事必须按背景、现象、指标、排查、根因、止血、长期治理和结果讲

这部分用来证明你不只是会背机制,还能把线上问题变成长期机制。

背景现象指标排查根因止血长期治理最终结果

慢 SQL 导致接口 RT 升高

核心列表接口上线新筛选条件后,业务高峰期响应变慢。

现象

  • - 接口 RT 升高,trace 显示 DB 耗时占比最高。

指标

  • - P99 从 80ms 升到 600ms
  • - 慢查询数量上升
  • - rows 扫描过大

排查

  • - 确认慢 SQL 和影响接口
  • - explain 发现未命中合适联合索引
  • - Extra 出现 filesort/temporary
  • - 检查分页深度和数据倾斜

根因

  • - 新筛选和排序条件没有对应联合索引,导致扫描行数过大并回表。

止血

  • - 临时收窄查询条件
  • - 加缓存和限流
  • - 补联合索引或改写 SQL

长期治理

  • - 慢 SQL 告警
  • - 索引评审机制
  • - 上线前 explain 记录
  • - 核心查询压测

最终结果

  • - 优化后 P99 回落,并建立慢查询评审和告警闭环。

Go 接口 RT 从 20ms 涨到 300ms

一次版本发布后,核心接口尾延迟明显升高。

现象

  • - P99 升高但错误率不高,用户反馈接口慢。

指标

  • - P99 20ms -> 300ms
  • - CPU 或 GC 指标异常
  • - goroutine/锁等待可能升高

排查

  • - 看发布记录
  • - 看 CPU/内存/GC/goroutine
  • - 用 pprof 查 CPU/heap/goroutine
  • - trace 检查下游耗时
  • - 检查连接池和锁竞争

根因

  • - JSON 编解码分配增加或共享锁竞争放大,也可能叠加下游变慢。

止血

  • - 临时回滚或降级
  • - 减少非核心计算
  • - 扩容或放宽连接池

长期治理

  • - 性能测试基线
  • - pprof 例行采样
  • - 减少临时对象
  • - 锁粒度治理

最终结果

  • - 定位证据来自 pprof 和 trace,而不是猜测;修复后补压测基线。

Redis 命中率下降

热点接口 DB 压力突然升高,缓存命中率下降。

现象

  • - Redis 命中率下降,DB QPS 和 RT 同步升高。

指标

  • - 命中率下降是全局还是局部
  • - DB 连接数升高
  • - Redis latency 或错误率

排查

  • - 检查是否发布过 key 规则变更
  • - 看热点 key 是否失效
  • - 看容量和淘汰
  • - 看穿透请求
  • - 看过期时间是否集中

根因

  • - 可能是热点 key 失效、过期策略变化、容量不足淘汰或大量穿透。

止血

  • - 热点预热
  • - 限流降级
  • - 本地缓存
  • - 空值缓存

长期治理

  • - key 设计评审
  • - 过期时间随机化
  • - 命中率告警
  • - 容量评估

最终结果

  • - 恢复缓存命中率后,把 key 规则和容量纳入发布检查。

MQ 积压

异步消费链路在高峰期出现消息堆积。

现象

  • - 消息积压增长,业务状态延迟更新。

指标

  • - 生产速度升高
  • - 消费速度下降
  • - 单条处理耗时升高
  • - 重试量增加

排查

  • - 看生产速度是否突增
  • - 看消费者是否报错
  • - 看下游依赖是否变慢
  • - 看热点分区和重试风暴

根因

  • - 下游接口变慢或单分区热点导致消费速度下降,重试进一步放大积压。

止血

  • - 扩容消费者
  • - 暂停非核心消费逻辑
  • - 限流下游
  • - 死信隔离异常消息

长期治理

  • - 消费耗时监控
  • - 积压告警
  • - 批量消费
  • - 分区扩容
  • - 死信处理机制

最终结果

  • - 积压下降后,补分区和消费耗时监控,避免下游慢导致重试风暴。

下游超时导致错误率升高

核心接口依赖一个外部或内部下游服务。

现象

  • - 下游超时,入口错误率上升,重试放大流量。

指标

  • - 错误码集中在某接口
  • - trace 显示下游 span 超时
  • - 重试次数升高

排查

  • - 看是否集中在某版本/机器/机房
  • - 检查下游错误和超时
  • - 检查重试是否无退避
  • - 看熔断和隔离是否生效

根因

  • - 下游服务异常叠加无边界重试,导致入口流量被放大。

止血

  • - 熔断
  • - 降级
  • - 限流
  • - 回滚
  • - 关闭非核心重试

长期治理

  • - 超时配置治理
  • - 指数退避
  • - 隔离池
  • - 降级预案
  • - 依赖健康告警

最终结果

  • - 通过熔断降级止血,再修复重试边界和依赖隔离。

AI 工程专题

把 RAG、tool calling、Agent、eval、安全和成本都讲成后端系统

面试里不要停在模型概念,要落到状态、权限、日志、评估、超时、重试和 fallback。

企业知识库问答优先 RAG,不要直接上来 fine-tuning。
RAG 质量要看 retrieval hit rate、answer accuracy、召回噪音、引用覆盖和权限过滤。
tool calling 必须由后端执行工具和做权限校验,模型只生成调用意图和参数。
Agent 工程要管理 state、loop、handoff、工具权限、错误恢复、成本和可观测性。
prompt caching 依赖精确前缀匹配,静态前缀前置、动态内容后置,并裁剪 RAG 结果。

每日 / 每周执行模板

固定节奏比临时兴奋更重要

每天有四段固定输入输出,每周必须做项目、系统设计、故障排查和快问快答。

算法 90 分钟

  • - 1 道新题
  • - 1 道旧题复盘
  • - 口述思路
  • - 手写 Go

Go / 基础 60 分钟

  • - 看 1 个主题
  • - 手写 20-30 行 demo
  • - 总结到笔记

数据库 / 网络 / OS / 分布式 60 分钟

  • - 只学 1 个主题
  • - 记录概念、场景、问题、解决方案

项目 / AI / 复盘 45 分钟

  • - 写项目或补 AI demo
  • - 口述面试题
  • - 记录 3 个不会点

每周固定动作

  • - 讲 1 次项目
  • - 讲 1 次系统设计
  • - 讲 1 次故障排查
  • - 做 1 次 Go / 数据链路快问快答
  • - 写 1 次周复盘:最弱 3 点、最能拉开差距 3 点、下周最该补 3 点、哪个答案还像中级

最终面试资产

8 周结束后,应该拿到能直接用于面试的资产包

高级 / 资深筛选的不是知识点背诵量,而是复杂系统、技术取舍、稳定性经验和长期治理能力。

资产 checklist

  • 2 个核心项目讲稿
  • 6 套系统设计题
  • 5-8 个故障故事
  • 1 套 Go 高级问答
  • 1 套 MySQL / Redis / MQ 深问答案
  • 1 套 AI 工程化问答
  • 1 份个人短板表
  • 1 份最终 mock 复盘表

高级 / 资深信号

  • 有没有扛过复杂系统
  • 会不会做技术取舍
  • 能不能把问题讲成机制
  • 有没有线上稳定性经验
  • 有没有系统长期治理能力
  • 能不能把 AI 工程讲成后端系统

资料来源与可信度

优先使用官方资料,站内正文负责把资料整理成面试可讲答案

Go、MySQL、Redis、OpenAI 资料均记录来源;外部链接用于可信度,不替代站内正文。