folly编译需手动配置依赖，推荐vcpkg统一安装；须安装系统级开发包、显式指定C++17标准；链接时-lfolly必须置于目标后并按依赖反序排列；Mac需禁用dwarf/unwind；生产环境需校验ABI兼容性及libc版本。

folly 库编译失败：找不到 glog 或 double-conversion

folly 依赖多个第三方库，不是 clone 下来就能直接 cmake 的。常见报错像 CMake Error: Could not find glog 或 double-conversion not found，本质是它默认不开自动下载，得手动配好依赖链。

• 推荐用 vcpkg 统一管理：vcpkg install folly:x64-linux（或 x64-windows），它会连带装好 glog、double-conversion、fmt、boost-context 等全部硬依赖
• 自己编译时，必须提前安装系统级依赖（如 Ubuntu）：sudo apt install libgflags-dev libgoogle-glog-dev libdouble-conversion-dev libssl-dev libsodium-dev，缺一个都可能卡在 configure 阶段
• 注意 folly 对 C++17 是强要求，cmake 里得显式加 -DCMAKE_CXX_STANDARD=17，否则编译器报一堆模板推导失败

链接时报 undefined reference to folly:: 符号

这是最常踩的坑：头文件能 include，但链接不过。folly 不是纯头文件库，大量实现放在 libfolly.so（或静态版 libfolly.a），而它的符号依赖极深，顺序和选项稍错就炸。

• 链接命令里，-lfolly 必须放在所有业务目标之后，且要按依赖拓扑反序排 —— 比如你用了 folly::json，就得确保 -lfolly -ldouble-conversion -lglog -lgflags -lssl -lcrypto 这串完整跟在你的 main.o 后面
• 用 CMake 时别只写 target_link_libraries(myapp PRIVATE folly)，得先 find_package(folly REQUIRED)，再确认 folly::folly target 是否带全了 INTERFACE_LINK_LIBRARIES（vcpkg 装的通常没问题，源码编译的容易漏）
• Mac 上额外注意：folly 默认启用 libdwarf 和 libunwind，但 Homebrew 的 llvm 工具链可能不兼容，可加 -DBUILD_TESTS=OFF -DFOLLY_HAVE_DWARF=OFF 规避

在生产环境用 Futex 或 AsyncSocket 前先看 ABI 兼容性

folly 里像 folly::futures::Future、folly::AsyncSocket、folly::EventBase 这些组件，底层重度依赖内核特性（如 Linux futex、epoll）和 libc++/libstdc++ 的 ABI 实现细节。不是“能跑”就等于“能上线”。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

• 不同发行版的 glibc 版本差异会导致 folly::SocketAddress 解析 IPv6 地址行为不一致，建议在目标部署环境里用 ldd 检查 libfolly.so 所链接的 libc.so.6 版本是否匹配
• 如果项目混用 GCC 和 Clang 编译，务必统一标准库：GCC 默认用 libstdc++，Clang 默认倾向 libc++，而 folly 官方只保证对 libstdc++ 的 ABI 稳定性（尤其在 folly::fbstring 上）
• Futex 类型在旧内核（ENOSYS，得 fallback 到 pthread_mutex —— folly 提供 Futex<atomtype>::wait()</atomtype> 的返回值检查，但很多人忽略这个分支

调试 folly::IOBuf 内存泄漏时别只盯 new/delete

folly::IOBuf 的内存管理是引用计数 + 池化混合模型，泄漏往往不是传统意义上的 new 没配对 delete，而是 IOBuf::clone() 或 IOBuf::coalesce() 后忘了释放原始 buffer 引用，或者跨线程传递时没用 IOBuf::cloneOne()。

立即学习“C++免费学习笔记（深入）”；

• 开启调试构建时，定义 FOOLY_IOBUF_DEBUG 宏，它会让 IOBuf 在构造/析构时打日志，配合 grep 快速定位未匹配的 refcount 变化
• 用 valgrind --tool=memcheck --leak-check=full 时，要加上 --freelist-vol=100000000，否则 IOBuf 的内存池分配会被误判为泄漏
• 注意 IOBuf::wrapBuffer() 创建的是 zero-copy view，不接管生命周期；而 IOBuf::copyBuffer() 才真正分配新内存 —— 混用这两者又没理清 ownership，是线上 double-free 的高发场景

folly 的复杂点不在 API 设计，而在它把性能优化深度耦合进了系统层——从内核调用到 libc ABI，从编译器特性到链接器脚本，任何一环松动都会在 runtime 突然咬你一口。用之前，先确认你的工具链、部署环境、团队 C++ 经验是否真的兜得住这些隐性契约。