大厂C++后端开发核心要求是Linux实战、高并发处理、系统资源对接和工程代码可维护性；需掌握gdb调试、strace抓包、cmake高级用法、非阻塞网络编程、中间件底层原理及系统级设计直觉。
进大厂做 C++ 后端开发，不是“会写 std::vector 和 std::shared_ptr”就够的——腾讯、百度、字节等公司对 C++ 后端岗的真实要求，集中在四个硬核维度：能跑在 Linux 上、能扛住并发、能对接系统级资源、能写出可维护的工程代码。其他都是锦上添花。
Linux 下的 C++ 实战能力是门槛底线
所有大厂 C++ 后端岗位 JD 第一条基本都是“熟悉 Linux 环境下 C++ 开发”。这不是指你会用 g++ -o main main.cpp 编译，而是：
- 能用
gdb看懂 core dump 的栈帧，定位到std::map::operator[]触发的 double-free 或std::string的 small string 优化失效问题 - 知道
strace和ltrace区别，能用strace -p $PID -e trace=recvfrom,sendto抓包验证 UDP 丢包是否发生在内核收包队列溢出 -
cmake不只是写add_executable，要能写条件编译逻辑（比如if(CMAKE_SYSTEM_NAME STREQUAL "Linux")）、控制 symbol visibility、导出pkg-config文件供他人链接 - 清楚
LD_LIBRARY_PATH和RPATH的优先级关系，遇到libstdc++.so.6: version `GLIBCXX_3.4.29' not found能立刻判断是 GCC 版本不一致还是 runtime library 没打包全
网络编程不能只懂 socket() + epoll()
校招可能考 select/poll/epoll 区别，但真实业务里，你得能马上接手一个已有的异步服务框架（比如基于 libevent 或自研 ntyco 协程库的项目）：
- 理解
epoll_wait()返回后，为什么不能直接遍历所有就绪 fd 做阻塞读写——必须配合非阻塞 socket + 循环recv()直到EAGAIN - 知道
SO_REUSEADDR解决的是 TIME_WAIT 端口占用问题，而SO_REUSEPORT才能真正让多进程/线程共享同一个监听端口（避免惊群） - HTTP 服务里，
Content-Length和Transfer-Encoding: chunked的解析逻辑必须自己写过一遍，不能全靠curl测试；否则上线后遇到分块传输中断，连日志都打不出来 - TCP 粘包不是理论问题：用
telnet手动发两个GET / HTTP/1.1\r\n\r\n，看服务端是否误判为一条请求——没处理好就等于线上事故
组件与中间件不是“会用 API”，而是“知道它怎么崩”
简历写“熟悉 Redis”，大厂面试官会立刻问：redis-cli --bigkeys 扫描时为什么主从同步会卡顿？答案不是“因为慢”，而是“因为 scan 是渐进式但 KEYS * 会阻塞主线程，而 --bigkeys 底层调的是 SCAN + TYPE + STRLEN，其中 STRLEN 对 big value 是 O(1)，但 HLEN 对 hash 是 O(N)”——这种粒度才是真实水位。
立即学习“C++免费学习笔记（深入）”；
- MySQL 连接池里，
mysql_ping()检活不能只在取连接时调一次，得配合空闲连接定时ping，否则网络闪断后连接池里一堆 stale connection - 写内存池时，如果用
malloc分配大块内存再切分，必须madvise(..., MADV_DONTDUMP)，否则 coredump 动辄几十 GB - 用
std::atomic<int></int>做计数器？小心 ABA 问题——高并发下compare_exchange_weak失败率陡增，得换std::atomic<uint64_t></uint64_t>存版本号 - 日志组件若用
log4cpp，得关掉LogAppender::setImmediateFlush(true)，否则每条日志都fsync，QPS 直接砍半
系统设计题暴露的是底层直觉
面“设计一个千万级在线聊天服务”，考察点根本不在画 UML 图，而在你能否本能反应出几个关键约束：
- 单机 TCP 连接数上限不是由内存决定，而是
/proc/sys/net/core/somaxconn和/proc/sys/net/core/netdev_max_backlog共同掐住的 - 消息广播不能用“每个用户一个
epoll事件”，得用epoll+eventfd做跨线程通知，或用无锁 ring buffer 避免锁竞争 - 用户状态同步若用 Redis Pub/Sub，得意识到 message 丢失不可补，必须加一层 Kafka 或 Pulsar 做可靠投递
- 压测时
TIME_WAIT占满本地端口？不是调net.ipv4.tcp_tw_reuse就完事——得确认客户端是否用了短连接，以及服务端是否正确设置了SO_LINGER
这些细节没有标准答案，但错一个，就说明你没在真实高并发服务里踩过坑。大厂筛人，筛的就是这种肌肉记忆级别的经验。
