BIGO 一面：C++ 后端与系统方向面经复盘

一、面试概况

本次面试约 65 分钟，整体流程是：

自我介绍和项目经历；
追问 JSONCpp 开源项目中的 Bug；
追问 AI Agent 编排和工具路由项目；
追问协程 RPC、异步 I/O、服务注册和配置同步；
C++ 智能指针、左右值引用和移动构造；
TCP 建联与断联、Linux epoll；
物理内存、虚拟内存、用户态和内核态；
屏幕手写 LRU Cache；
近期学习方向和反问。

面试官的提问基本围绕简历中主动写出的内容展开。面试中的一个重要教训是：简历上写出的技术名词，都要能继续解释设计动机、执行流程、异常情况和测试方式。

二、自我介绍与项目追问

自我介绍中提到了上一段实习的云盘类系统、服务器性能监控、AI Agent 编排服务、RPC 项目，以及对 JSONCpp 和百度 BRPC 的开源代码学习。

实习项目主要包括：

采集服务器 CPU 使用率、系统负载和内存占用；
根据多个指标计算服务器权重；
让后端根据权重进行负载分配。

校园项目主要包括：

AI 应用中的 Agent 编排服务；
使用 RAG-MCP 思路减少全量工具描述带来的 Token 消耗；
参考 MIT 6.824 实现 RPC 和一致性相关功能；
阅读 JSONCpp、BRPC 等开源项目。

自我介绍的不足是技术名词较多，但项目边界、数据流和个人实际贡献说得不够紧。更好的项目介绍结构是：

项目背景 → 我的职责 → 技术方案 → 遇到的问题 → 解决方式 → 验证结果

三、JSONCpp 开源 Bug

面试问题

面试官围绕 JSONCpp 询问：

你修复了什么问题？
无符号整数和 int 比较时为什么会出错？
Bug 是如何发现的？
修复后如何验证？
是否补充测试并通过 CI？

问题本质

有符号整数和无符号整数比较时，会发生整型提升和通常算术转换。例如：

int a = -1;
unsigned int b = 1;

if (a < b) {
    // a 可能先转换为 unsigned int
}

当 int 和 unsigned int 参与比较时，a 可能转换为一个很大的无符号数，结果就与直觉不同。JSON 库中常见的数组下标、长度和整数值都可能触发这种问题。

更严谨的修复方式是先检查符号和范围，再进行显式转换：

int index = getIndex();
if (index >= 0 && static_cast<std::size_t>(index) < values.size()) {
    // index 已确认非负，再与 size_t 比较
}

不能把问题简单描述成“把无符号数强转成 int”。需要说明具体转换发生在哪一侧、哪一个边界值导致结果错误，以及为什么修复不会影响正常范围内的数据。

测试和验证

面试官特别关注修复验证。正确的回答应包括：

添加最小复现用例；
覆盖 INT_MIN、INT_MAX、UINT_MAX 和跨符号比较；
覆盖数组下标、长度和 JSON 数值等实际调用路径；
修复前确认用例失败，修复后确认通过；
运行完整单元测试；
通过项目 CI，检查没有引入回归。

本次回答提到了通过 AI 辅助审查、增加测试和运行 CI，但没有清楚说出边界用例和测试结果，这是后续需要补强的地方。

四、AI Agent、Intent 与工具路由

面试问题

面试官询问：

Intent 是什么？
项目主要解决什么问题？
为什么需要工具调用路由？
主 Agent、子 Agent 和 MCP 工具如何协作？

项目流程

根据面试中的描述，项目链路大致是：

客户端请求
    ↓
gRPC / RPC 接入
    ↓
主 Agent 或主模型识别意图
    ↓
筛选与当前请求相关的工具
    ↓
路由到对应子 Agent
    ↓
通过 MCP 调用具体工具
    ↓
统一返回结果

项目的主要动机是避免把大量工具的完整描述一次性放入 Prompt：

减少 Prompt 长度；
降低 Token 消耗；
减少模型选择工具的负担；
缩短请求延迟；
让工具数量扩展时仍然可维护。

更准确的回答应该区分几个概念：

Intent：用户请求背后的意图或任务类别；
Agent：能够根据上下文进行决策并执行任务的主体；
MCP：连接模型与外部工具、资源的协议或工具接入层；
Tool Router：根据请求和工具元数据选择候选工具的路由模块。

面试中把这些概念都说成“给大模型调用的工具”会显得边界不清。回答时应先给出一句定义，再用一个具体请求说明完整链路。

五、协程 RPC 与异步 I/O

面试问题

面试官追问：

协程如何切换？
RPC 遇到 I/O 等待时发生什么？
协程如何保存和恢复上下文？
如何避免一个 I/O 请求阻塞整个线程？

六、服务注册、配置同步和插件加载

面试官询问插件或子服务在加载、卸载时如何保持一致性。回答中提到了主服务、RPC 子服务、预加载、加载完成、ZooKeeper 注册中心以及配置变更通知。

这类系统设计题需要覆盖：

服务注册和发现；
心跳与临时节点；
配置版本号；
预加载和正式切换；
请求排空和优雅下线；
正在处理请求的生命周期；
更新失败时的回滚；
重试、幂等和消息顺序；
主服务与子服务的状态确认。

一个更完整的热加载方案可以是：

读取新配置
    ↓
子服务预加载并校验
    ↓
子服务报告 ready + version
    ↓
主服务原子切换版本
    ↓
停止新请求进入旧实例
    ↓
等待旧请求完成
    ↓
卸载旧实例

只说“通过 RPC 通知子服务”还不够，需要说明通知失败怎么办、重复通知是否安全，以及如何保证切换过程中不会访问已经卸载的对象。

七、智能指针和引用

1. 智能指针

面试官让你比较裸指针、shared_ptr、weak_ptr 和 unique_ptr。

类型	所有权语义	关键特点
裸指针	通常表示观察关系	不自动管理生命周期，不代表所有权
`unique_ptr`	独占所有权	不能复制，可以移动，开销低
`shared_ptr`	共享所有权	控制块维护引用计数，计数归零时销毁对象
`weak_ptr`	非拥有观察关系	不增加强引用计数，可避免循环引用

std::weak_ptr<Node> weak = shared;
if (auto locked = weak.lock()) {
    // 对象仍然存在，locked 临时拥有一个 shared_ptr
}

weak_ptr 本身不能直接解引用，必须先通过 lock() 获得临时的 shared_ptr。shared_ptr 的控制块计数操作通常是线程安全的，但被管理对象的成员读写并不会因此自动线程安全。

2. 左值引用、右值引用和移动构造

左值引用通常是已有对象的别名：

int value = 1;
int& ref = value;
ref = 2; // 修改 value

右值引用可以绑定临时对象或将亡值，常用于移动构造和完美转发：

std::string makeName();
std::string name = makeName();

移动构造的核心是转移资源所有权，例如转移字符串缓冲区指针，而不是简单地逐个复制字符。需要注意：右值引用本身不等于“延长所有临时对象生命周期”；典型的生命周期延长规则主要与 const T& 绑定临时对象有关。

八、TCP 建联和断联

1. 三次握手

面试官询问 TCP 建联和断联分别解决什么问题。标准三次握手是：

客户端 → 服务端：SYN
服务端 → 客户端：SYN + ACK
客户端 → 服务端：ACK

三次握手用于：

确认双方的发送和接收能力；
同步双方的初始序列号；
防止旧连接请求误建立新连接；
协商部分连接参数。

服务端收到 SYN 后会进入半连接队列，完成握手后才进入已连接队列，应用层通过 accept 获取连接。

2. 四次挥手

TCP 的两个方向可以独立关闭，因此通常需要四个报文：

主动关闭方 → 被动关闭方：FIN
被动关闭方 → 主动关闭方：ACK
被动关闭方 → 主动关闭方：FIN
主动关闭方 → 被动关闭方：ACK

发送 FIN 只表示这一方向不再发送数据，并不代表另一方向立即关闭。主动关闭方可能进入 TIME_WAIT，等待旧报文在网络中失效，并确保最后一个 ACK 丢失时可以重传。

本次回答说出了 FIN、ACK 和双方分别关闭，但没有完整解释序列号、半关闭和 TIME_WAIT，并且把 FIN 识别成了类似“F1”，正式面试中需要使用准确术语。

九、Linux `epoll` I/O 多路复用

典型流程如下：

int epfd = epoll_create1(0);

epoll_event event{};
event.events = EPOLLIN;
event.data.fd = socketFd;
epoll_ctl(epfd, EPOLL_CTL_ADD, socketFd, &event);

epoll_event events[128];
int count = epoll_wait(epfd, events, 128, timeoutMs);

事件循环一般是：

创建 epoll 实例；
将非阻塞 socket 注册进去；
调用 epoll_wait 等待就绪事件；
处理 EPOLLIN、EPOLLOUT、EPOLLERR、EPOLLRDHUP；
ET 模式下循环读写直到返回 EAGAIN；
根据连接状态增加、删除或修改关注事件。

需要能区分：

LT（水平触发）：只要仍然就绪，就会继续通知；
ET（边沿触发）：状态从未就绪变为就绪时通知，通常要求非阻塞并一次处理到 EAGAIN。

本次回答提到了注册事件、epoll_wait 和回调，但没有充分展开 LT/ET、非阻塞和错误事件处理。

十、物理内存、虚拟内存和用户态/内核态

1. 虚拟内存

每个进程拥有独立的虚拟地址空间。CPU 访问虚拟地址时，MMU 根据页表将其映射到物理页。访问尚未建立映射的页面时，可能触发缺页异常，由内核完成分配、加载或建立映射。

虚拟地址空间大小不等于物理内存大小，具体取决于 CPU 架构、操作系统和进程模型。64 位系统也不一定使用完整 64 位地址，常见实现会使用 48 位或 57 位有效虚拟地址。

mmap 可以把文件或匿名内存映射到进程的虚拟地址空间，但映射成功不代表所有页面已经立刻加载到物理内存。

2. 用户态和内核态通信

典型系统调用流程是：

用户程序调用 read/write/open 等接口
    ↓
执行系统调用指令
    ↓
CPU 从用户态切换到内核态
    ↓
内核检查参数并执行特权操作
    ↓
返回结果并切换回用户态

常见交互方式包括系统调用、ioctl、mmap、信号、管道、Socket 和共享内存。

需要区分两个概念：

虚拟内存和页表主要解决地址转换、隔离和访问权限；
系统调用主要解决用户程序请求内核提供服务。

本次面试中这一部分回答较弱，混淆了虚拟内存映射和用户态/内核态通信。后续应重点复习页表、缺页异常、系统调用入口以及用户缓冲区和内核缓冲区之间的数据复制。

十一、LRU Cache 手写题

面试后半段进行了现场编程，题目是实现 LRU 缓存。题目中出现了双向链表、左右哨兵节点、查询、插入、容量满时移除节点等要求。

标准数据结构是：

unordered_map<key, list node>
双向链表头部：最近使用
双向链表尾部：最久未使用

操作复杂度应达到平均 O(1)：

get：哈希表查找并把节点移动到头部；
put：已有键更新并移动到头部；
新键插入头部；
容量超限时删除尾部节点并从哈希表移除。

使用哨兵节点可以减少头部、尾部边界判断：

struct Node {
    int key;
    int value;
    Node* prev;
    Node* next;
};

本次手写题的主要问题是代码没有成功编译运行。说明算法思路基本知道，但在现场实现时存在：

变量和函数命名不稳定；
链表指针操作容易写错；
辅助函数没有先单独验证；
写完代码后没有立即编译；
边界条件没有明确列出。

复习时应至少手写并运行以下测试：

容量为 0
容量为 1
重复 put 同一个 key
get 后顺序改变
容量满后淘汰最久未使用节点
查询不存在的 key

十二、面试表现总结

优点

项目覆盖 C++、Linux、网络、RPC 和 AI 应用，技术面较广；
能说明工具路由降低 Prompt 和 Token 成本的业务动机；
shared_ptr、weak_ptr、unique_ptr 的基础概念基本掌握；
对 TCP、协程和 epoll 有学习或实践经历；
遇到虚拟内存等不熟悉的问题时没有继续编造细节；
面试官认可学习主动性和对技术细节的兴趣。

主要短板

技术名词偶尔表达不准确，容易把概念边界说混；
项目介绍偏“堆技术名词”，缺少清晰的数据流和个人贡献；
协程、epoll 和服务加载只说到了大致流程，缺少关键状态转换；
TCP 三次握手、四次挥手没有完整展开；
虚拟内存和用户态/内核态的回答较弱；
左值引用、右值引用、生命周期和移动语义还需细化；
LRU 思路正确，但现场代码未编译通过；
回答中“然后”“其实”“应该是”等口头填充较多，重点不够突出。

十三、优先复习清单

完整手写可运行的 LRU Cache，并熟练解释每个指针操作。
复习 TCP 三次握手、四次挥手、半关闭和 TIME_WAIT。
画出 epoll 事件循环，掌握 LT、ET、非阻塞和 EAGAIN。
理解系统调用、用户态/内核态切换、页表和缺页异常。
区分 shared_ptr 控制块、引用计数、weak_ptr::lock 和循环引用。
掌握左值、右值、将亡值、移动构造和完美转发。
能完整讲清协程挂起、恢复句柄、事件循环和调度器关系。
用边界测试说明 JSONCpp 有符号/无符号比较 Bug 的修复。
把每个项目整理成“背景—职责—方案—问题—验证—结果”六句话。

十四、面试回答模板

遇到项目问题时，可以按下面的结构回答：

这个问题发生在什么场景？
我负责哪一部分？
原实现的问题是什么？
我选择了什么方案，为什么？
边界条件和失败情况如何处理？
通过哪些测试、监控或 CI 验证？
最终带来了什么结果？

这场面试暴露出的核心问题不是完全没有接触过相关技术，而是知识点之间的连接还不够牢固。下一步应把每个简历项目都落实到可运行代码、流程图和边界测试上，尤其要保证手写题能够编译、运行并解释复杂度。

十五、追问逐题标准回答

下面按照面试中的实际顺序，把追问改写成可以直接练习的完整回答。回答时应先给结论，再补原理、实现和验证，避免只说几个技术名词。

问题 1：请介绍你在 JSONCpp 中修复的 Bug

标准回答：

这个问题出现在 JSON 数值或数组下标比较路径中。原实现让有符号整数和无符号整数直接参与比较，触发了 C++ 的整型提升和通常算术转换。当无符号类型的范围覆盖不了有符号类型时，有符号值会被转换成无符号值。例如 -1 转成 unsigned int 后会变成一个很大的正数，导致比较结果与业务预期不一致。

我先写了最小复现用例，确认问题发生在比较前的类型转换，而不是 JSON 解析本身。修复时先判断有符号值是否为负、是否超出目标类型范围，只有在范围安全时才进行显式转换；对于数组下标，则先确认下标非负，再与 size() 返回的无符号类型比较。最后补充边界测试，并运行完整单元测试和 CI，确认大数比较修复后普通数值路径没有回归。

问题 2：这个 Bug 是怎么发现的？为什么相信修复是正确的？

标准回答：

我在逐步阅读和调用项目代码时发现了异常行为，也使用 AI 做了初步代码审查，但 AI 只作为辅助定位工具，最终结论是通过源码、标准转换规则和可复现测试共同确认的。验证分三层：第一层是最小复现，覆盖负数、INT_MAX、UINT_MAX 和跨符号比较；第二层是 JSON 数值、数组长度和下标等真实调用路径；第三层是完整测试和 CI。修复前测试必须失败，修复后必须通过，这样才能证明修复确实覆盖了原问题。

问题 3：Intent 在你的项目中是什么？

标准回答：

Intent 表示用户请求背后的任务意图或目标，例如“查询订单”“计算数学表达式”“读取某个系统指标”。它不是一个具体工具，也不等于一个大模型，而是路由系统用于理解请求、选择 Agent 或工具的中间语义。系统先识别 Intent，再根据意图和参数选择合适的 Agent 及工具，最后把结果转换成客户端可以理解的响应。

问题 4：Intent 或 Agent 编排项目主要解决什么问题？

标准回答：

项目主要解决大模型工具数量增加后，所有工具描述都塞进一次 Prompt 带来的问题。全量注入会增加上下文长度和 Token 消耗，降低模型选择准确率，也会增加延迟。我的方案把工具元数据建立索引，先根据用户请求筛选候选工具，再把相关描述交给主 Agent。这样可以减少 Prompt 体积和调用成本，同时让工具扩展不必修改所有业务 Prompt。

问题 5：为什么要做工具调用路由，而不是把所有工具直接交给模型？

标准回答：

工具数量少时可以全量提供，但工具达到几十或几百个后，全量描述会造成三个问题：上下文和 Token 成本变高，模型需要在大量无关工具中做选择，调用延迟和误选概率也会上升。工具路由层先对工具名称、描述、参数和标签做索引，再将用户请求编码后召回候选工具，最后只把 Top-K 工具交给主模型。召回阶段追求覆盖率，模型最终选择阶段追求准确率，二者可以分别监控和优化。

问题 6：请说明 Agent、MCP、RPC 和工具之间的调用链路

标准回答：

客户端先通过 gRPC 或其他 RPC 接口发送请求，接入层完成鉴权、参数校验和请求编号。主 Agent 根据请求识别 Intent，并调用工具路由模块筛选候选工具。如果任务需要专门能力，就把结构化任务交给对应子 Agent。子 Agent 根据 MCP 暴露的工具描述生成工具调用，MCP 适配层负责连接外部服务、传递参数、处理超时和返回错误。结果经过主 Agent 汇总后，由 RPC 层统一返回客户端。

客户端 → RPC 接入层 → 主 Agent → Intent/工具路由
       → 子 Agent → MCP 工具适配层 → 外部服务
       ← 结果归一化 ← 主 Agent ←

问题 7：RPC 遇到 I/O 等待时，协程是如何切换的？

标准回答：

Socket 先设置为非阻塞模式。协程调用 read 或 write 时，如果数据暂时没有准备好，系统调用返回 EAGAIN，协程通过 co_await 挂起，并保存自己的局部状态和恢复句柄；文件描述符和需要关注的事件被注册到 epoll。当前线程此时可以运行其他协程。事件循环收到可读或可写通知后，根据事件中保存的句柄恢复原协程，协程从挂起点继续执行。

协程切换不是创建新线程，而是用户态的执行状态切换。调度器负责保存、排队和恢复协程，线程数量与协程数量不必相同。

问题 8：协程如何保存上下文，I/O 完成后如何恢复？

标准回答：

编译器会把协程函数转换成状态机，局部变量和当前执行位置保存在协程帧中。co_await 的 awaiter 决定是否立即继续；如果需要等待，它会把恢复操作登记到事件循环并返回挂起状态。epoll_wait 返回后，事件循环找到对应的协程句柄，调用 resume()，状态机根据保存的状态从原来的 co_await 后面继续执行。恢复时还要处理读写结果、错误码、超时和取消。

问题 9：插件或子服务加载、卸载时如何保证一致性？

标准回答：

加载不能直接替换正在使用的对象。我会分为预加载、校验、发布和切换四个阶段：先加载新版本并校验配置、依赖和接口，再让子服务报告 ready 及版本号；主服务确认所有依赖就绪后原子切换路由，新请求不再进入旧实例；等待旧请求排空后再卸载旧实例。如果加载失败，继续使用旧版本并记录错误。卸载需要处理并发请求、引用计数、超时、重复通知和回滚，保证任何线程都不会访问已释放的代码或数据。

问题 10：ZooKeeper 或注册中心在这里做什么？

标准回答：

注册中心保存服务实例地址、版本、健康状态和配置版本。服务启动时注册临时节点并定期发送心跳，异常退出后临时节点可以被清理；主服务通过监听机制感知实例增加、删除和配置变化。配置更新需要携带单调递增版本号，子服务只接受合法的新版本，并在加载成功后回报确认。真正的请求切换仍应由主服务控制，注册中心负责发现和通知，不能把它当成业务数据的一致性数据库。

问题 11：`shared_ptr`、`weak_ptr` 和 `unique_ptr` 有什么区别？

标准回答：

unique_ptr 表示独占所有权，不能复制，只能移动，适合作为默认的资源管理类型。shared_ptr 表示共享所有权，控制块维护强引用计数，最后一个强引用销毁时释放对象；它的额外成本包括控制块、引用计数和可能的原子操作。weak_ptr 不拥有对象，不增加强引用计数，使用 lock() 临时获得 shared_ptr，常用于观察对象和打破循环引用。裸指针通常表达非拥有观察关系，不能单凭类型推断生命周期。

std::weak_ptr<Node> weak = shared;
if (auto owner = weak.lock()) {
    // owner 存在期间对象不会被释放
}

shared_ptr 的控制块计数操作通常是线程安全的，但被管理对象内部的数据并不会因此自动线程安全。

问题 12：左值引用和右值引用分别是什么？

标准回答：

左值引用是已有对象的别名，可以修改对象，也可以用 const T& 只读绑定。右值引用主要绑定临时对象和将亡值，常用于移动构造、移动赋值和完美转发。移动构造通常转移动态资源的所有权，源对象仍然必须处于有效但未指定的状态。右值引用本身不等于延长所有临时对象的生命周期；const T& 绑定临时对象时才有典型的生命周期延长规则。

问题 13：TCP 三次握手解决什么问题？

标准回答：

三次握手既确认双方的发送和接收能力，也同步双方的初始序列号，并避免旧的连接请求误建立新连接。流程是：客户端发送 SYN，服务端回复 SYN + ACK，客户端再回复 ACK。服务端收到第一个 SYN 后会把连接放入半连接队列，握手完成后进入已连接队列，应用通过 accept 取得连接。握手包中的序列号和确认号还用于后续可靠传输。

问题 14：TCP 四次挥手为什么通常需要四个报文？

标准回答：

TCP 的发送和接收方向可以独立关闭，所以主动关闭方先发送 FIN 表示自己不再发送数据，被动方回复 ACK；被动方处理完剩余数据后再发送自己的 FIN，主动方回复最后一个 ACK。收到 FIN 只代表对方的一个发送方向关闭，本端仍可能继续发送数据，这就是半关闭。主动关闭方通常进入 TIME_WAIT，等待旧报文过期，并保证最后 ACK 丢失时可以重传。

问题 15：`epoll` 的基本工作流程是什么？

标准回答：

首先调用 epoll_create1 创建实例，把非阻塞 socket 通过 epoll_ctl(ADD) 注册，并设置关注的 EPOLLIN、EPOLLOUT、EPOLLERR 或 EPOLLRDHUP 事件。事件循环调用 epoll_wait 阻塞等待就绪事件，返回后遍历事件数组，根据 data 中保存的连接对象执行读、写、错误和关闭处理。ET 模式下必须持续读写直到 EAGAIN，否则可能因为没有新的边沿通知而留下未处理数据。

LT 模式只要状态仍然就绪就会重复通知，使用简单；ET 模式只在状态变化时通知，减少重复唤醒，但要求非阻塞并一次处理干净。

问题 16：物理内存和虚拟内存是什么关系？虚拟内存一般多大？

标准回答：

每个进程看到的是独立的虚拟地址空间。CPU 产生虚拟地址后，MMU 通过多级页表将其转换为物理页，页表项同时记录读写执行权限和是否存在。访问未映射页面会触发缺页异常，由内核建立映射、分配物理页或从文件加载数据。mmap 建立的是虚拟地址映射，不保证所有页面已经驻留物理内存。

虚拟地址空间大小不是固定的，取决于 CPU 架构、操作系统、进程位数和实际配置。64 位系统通常只使用部分有效地址位，例如常见实现是 48 位或 57 位；32 位进程的用户空间则通常明显小于 4 GB。虚拟内存大小也不等于机器物理内存大小。

问题 17：用户空间和内核空间如何通信？

标准回答：

最常见方式是系统调用。用户程序调用 read、write、open、mmap 或 ioctl 等接口，通过系统调用指令进入内核态；内核验证用户传入的地址和权限，执行特权操作，再把结果复制或映射回用户空间并返回。除此之外，还可以使用信号、管道、Socket、共享内存和事件文件描述符进行进程间通信。

虚拟内存和页表解决的是地址转换、隔离和权限问题；系统调用解决的是用户程序请求内核服务，二者不能混为一谈。

问题 18：你最近学习了什么？有没有真正做实践？

标准回答：

最近主要学习 AI 应用编排、MCP 工具接入、BRPC 和 JSONCpp 的源码，同时自己搭建了一个基于 C++ Web 框架的博客。学习不是只看文档：我会先阅读源码，再做最小可运行实验，最后通过测试、日志和实际请求验证理解。对于开源项目，我会围绕一个具体问题建立复现用例，记录修改前后行为，并尽量提交测试或补丁。

问题 19：请现场实现一个 LRU Cache

标准回答：

我会使用哈希表加双向链表。哈希表把 key 映射到链表节点，链表从头到尾表示从最近使用到最久未使用。get 找到节点后移动到头部；put 如果 key 已存在就更新并移动到头部，否则创建节点插入头部；容量超过上限时删除尾部节点，并从哈希表删除对应 key。通过左右哨兵节点可以避免空链表、头尾节点的特殊分支。查找、移动、插入和删除的平均复杂度都是 O(1)。

写完后我会立即编译，并测试容量为 0 和 1、重复更新、访问改变顺序、容量满时淘汰、查询不存在 key 等边界情况。现场题首先保证正确性，再说明复杂度和可扩展方向。

问题 20：程序没有运行或出现编译错误怎么办？

标准回答：

我会先停止继续解释未经验证的结果，读取第一条编译错误，定位到最小代码范围。先修复语法、类型、头文件和生命周期问题，再重新编译；通过后运行最小测试，最后补充边界测试。对于 LRU，我会优先验证链表的 remove、insert_front 和 move_to_front 三个辅助函数，再组合成 get 和 put。这样可以把现场调试从“大段代码一起排查”拆成几个可验证的小步骤。

问题 21：你对后台还是客户端方向更感兴趣？

标准回答：

我目前更偏向后台和网络服务开发，原因是已有服务器监控、RPC、C++ 网络编程和 Linux 学习经历，也更熟悉服务端的并发、性能和稳定性问题。客户端方向我接触过 Qt 和 Windows 开发，如果岗位需要，我也愿意补齐界面、线程模型和平台 API。无论方向如何，我会先明确岗位的核心业务，再把已有的 C++ 和系统能力迁移到具体模块中。

十六、逐题回答的统一方法

这场面试的追问大多可以用下面的顺序组织：

先给一句定义
→ 说明问题或目标
→ 描述执行流程
→ 解释边界和失败情况
→ 给出测试、监控或验证方式
→ 说明复杂度、成本和取舍

例如回答 epoll，不能只说“注册事件然后回调”，还要说明非阻塞、epoll_wait、LT/ET、EAGAIN 和错误处理；回答 JSONCpp Bug，不能只说“类型强转有问题”，还要说明整型提升、边界测试和 CI 结果；回答 LRU，不能只说“哈希表加链表”，还要现场编译并验证边界。

BIGO 一面：C++ 后端与系统方向面经复盘

一、面试概况

二、自我介绍与项目追问

三、JSONCpp 开源 Bug

面试问题

问题本质

测试和验证

四、AI Agent、Intent 与工具路由

面试问题

项目流程

五、协程 RPC 与异步 I/O

面试问题

推荐回答流程

六、服务注册、配置同步和插件加载

七、智能指针和引用

1. 智能指针

2. 左值引用、右值引用和移动构造

八、TCP 建联和断联

1. 三次握手

2. 四次挥手

九、Linux epoll I/O 多路复用

十、物理内存、虚拟内存和用户态/内核态

1. 虚拟内存

2. 用户态和内核态通信

十一、LRU Cache 手写题

十二、面试表现总结

优点

主要短板

十三、优先复习清单

十四、面试回答模板

十五、追问逐题标准回答

问题 1：请介绍你在 JSONCpp 中修复的 Bug

问题 2：这个 Bug 是怎么发现的？为什么相信修复是正确的？

问题 3：Intent 在你的项目中是什么？

问题 4：Intent 或 Agent 编排项目主要解决什么问题？

问题 5：为什么要做工具调用路由，而不是把所有工具直接交给模型？

问题 6：请说明 Agent、MCP、RPC 和工具之间的调用链路

问题 7：RPC 遇到 I/O 等待时，协程是如何切换的？

问题 8：协程如何保存上下文，I/O 完成后如何恢复？

问题 9：插件或子服务加载、卸载时如何保证一致性？

问题 10：ZooKeeper 或注册中心在这里做什么？

问题 11：shared_ptr、weak_ptr 和 unique_ptr 有什么区别？

问题 12：左值引用和右值引用分别是什么？

问题 13：TCP 三次握手解决什么问题？

问题 14：TCP 四次挥手为什么通常需要四个报文？

问题 15：epoll 的基本工作流程是什么？

问题 16：物理内存和虚拟内存是什么关系？虚拟内存一般多大？

问题 17：用户空间和内核空间如何通信？

问题 18：你最近学习了什么？有没有真正做实践？

问题 19：请现场实现一个 LRU Cache

问题 20：程序没有运行或出现编译错误怎么办？

问题 21：你对后台还是客户端方向更感兴趣？

十六、逐题回答的统一方法

继续阅读

C++ 软牛科技一面复盘：从类型转换到链接模型

C++20 协程如何简化 Web 服务

用 Drogon 构建一个 Git 驱动的博客

九、Linux `epoll` I/O 多路复用

问题 11：`shared_ptr`、`weak_ptr` 和 `unique_ptr` 有什么区别？

问题 15：`epoll` 的基本工作流程是什么？