用户下载大文件常卡在99%或切后台后进度归零，甚至多任务时内存飙升、文件损坏；我重写了下载器，实现多线程分段拉取、本地持久化断点、统一调度并发任务；崩溃率从100%降至0，2GB文件平均下载提速3.2倍。
项目介绍别堆技术名词，先说清楚“你解决了什么实际问题”
面试官听项目不是为了查你的技术词典背得熟不熟，而是想确认你真动手做过、能讲清因果。比如你说“用 std::shared_ptr 管理资源”，不如先说：“用户上传大文件时频繁崩溃，定位到是多线程下裸指针释放错乱，后来改用 std::shared_ptr + 自定义删除器，崩溃率从 12% 降到 0。”
- 每段项目描述控制在 3 句内：场景 → 你干了啥 → 结果可衡量（响应快了 40%，内存泄漏减少 95%，上线后没再收到同类 bug）
- 避免出现“参与”“协助”“负责模块开发”这种模糊动词，换成“重写了
PacketDecoder类，支持断点续传协议解析” - 如果项目用了第三方库（比如
Boost.Asio），只提它帮你绕过了什么难题，不展开讲它怎么设计的
被问“为什么选这个方案”时，暴露你的权衡过程
这题本质是在考工程判断力。光说“因为 STL 容器好用”是无效回答；要说出你当时对比过什么、为什么排除了其他路。
- 例如实现一个高频日志缓冲区：你选了
std::vector<char></char>预分配 + 写指针偏移，而不是std::deque或环形缓冲区（boost::circular_buffer），就得说明：“测过 10w QPS 下std::deque的迭代器失效导致锁粒度变大，而自研缓冲区把加锁范围缩到 8 字节原子写，延迟稳定在 12μs 内” - 如果用了 C++17 的
std::optional替代返回-1错误码，要提：“老代码靠注释约定返回值含义，review 时发现三处没判-1导致越界，改用std::optional后编译期就报错” - 别怕说“当时没想到”，但得补一句“现在回头看，如果用
std::span封装输入参数，能提前捕获空指针”
遇到“项目里最难的点”别硬凑技术深度，聚焦真实卡点
很多人误以为“最难”等于“最炫技”，结果讲半天协程调度器却说不清为啥不用 std::thread。其实面试官想听的是：你面对模糊需求/线上事故/跨团队扯皮时，怎么拆解、验证、落地。
- 典型有效回答：“客户端和服务端时间戳对不齐，导致订单超时误判。我先用
std::chrono::system_clock::now()和steady_clock对比，发现系统时钟被 NTP 频繁回拨；最后改成只依赖steady_clock做超时计算，服务端用逻辑时钟同步业务事件顺序” - 如果重构了旧模块，重点说“怎么证明没引入新 bug”：比如加了
static_assert检查 ABI 兼容性、用valgrind --tool=memcheck扫描野指针、压测前后perf record -e cache-misses数据对比 - 警惕“伪难点”：不要说“第一次用 CMake”，除非你真的为解决
target_link_libraries循环依赖翻了官方 issue 并提交了 patch
被追问细节时，用代码片段锚定讨论范围
当面试官说“能写一下那段逻辑吗”，别现场从头撸完整函数。用最小可运行片段锁定焦点，同时暴露你对边界条件的思考。
立即学习“C++免费学习笔记（深入）”；
- 比如讲智能指针管理 socket，直接贴 5 行关键代码：
auto sock = std::make_shared<Socket>(fd); sock->set_close_handler([sock](int err) { if (err) log_error(err); sock.reset(); // 注意：这里 reset() 触发 close() }); - 如果对方问“线程安全怎么保证”，立刻指出哪行有风险（比如
sock.reset()在信号处理函数里调用），并给出改进：std::atomic<bool> closing{false}</bool>+ 双检锁 - 所有变量名、函数名、宏名必须和你项目里真实一致，别临时改名——面试官可能顺着名字继续深挖（比如看到
BufferPool::acquire()就问“池满时怎么 fallback？”）
