Folly不会自动提升性能，需按高吞吐低延迟场景选对组件：如folly::ConcurrentHashMap替代加锁unordered_map、IOBuf减少拷贝、fbstring优化字符串操作，并注意编译链接要求与使用陷阱。
直接用 Folly 不会自动提升性能，它只是把 Facebook 高并发服务里反复验证过的高性能 C++ 组件打包给你——关键在选对组件、避开默认陷阱、适配你的数据模式。
什么时候该用 Folly 而不是标准库？
不是所有场景都适合。Folly 的优势集中在高吞吐、低延迟、多线程共享数据的后端服务中：
- 你需要
folly::ConcurrentHashMap替代std::unordered_map+ 手动加锁，且读远多于写 - 你在做大量短生命周期对象分配（比如每请求一个 buffer），
folly::IOBuf比std::vector<uint8_t></uint8_t>减少拷贝和内存碎片 - 你用
std::string做频繁拼接或子串切片，folly::fbstring的 SSO 和引用计数能省掉不少 malloc - 你在写异步网络层，
folly::EventBase+folly::AsyncSocket比裸 epoll +std::thread更易控资源
folly::IOBuf 怎么避免“越用越慢”？
IOBuf 是零拷贝核心，但误用反而增加开销：
- 不要对小数据（folly::fbstring 或栈数组更轻量
- 调用
coalesce()前先检查isChained()，链式 IOBuf 合并会触发内存拷贝，高频路径慎用 - 从 socket 读取时优先用
IOBuf::createCombined()预分配多段缓冲，避免后续追加时反复 realloc - 释放 IOBuf 链时，确保所有持有者都已 drop 引用 —— 循环引用或提前析构会导致内存泄漏（常见于 callback 捕获 IOBuf 智能指针）
auto buf = folly::IOBuf::create(4096); buf->append(1024); // ✅ 正确：复用同一块内存 memcpy(buf->writableData(), data, 1024); buf->append(1024); // ❌ 错误：触发内部 realloc buf->advance(2048); buf->prepend(512); // 可能移动数据
folly::ConcurrentHashMap 的 key 类型陷阱
它不接受任意 std::hash，必须满足两个隐含条件：
立即学习“C++免费学习笔记（深入）”；
- key 类型必须支持 trivial copy（POD 或显式标记
std::is_trivially_copyable_v），否则运行时报static_assert失败 - hash 函数不能抛异常 —— 默认用
std::hash，但若自定义 key 用了std::string成员，需重载hash::operator()并确保不抛异常 - 迭代器不是强一致性：遍历时插入/删除可能跳过或重复元素，别依赖“全量快照”语义
- 桶数量（
initialCapacity）建议设为 2 的幂，且至少是预期 size 的 2–3 倍，否则锁争用上升明显
性能敏感路径上，如果 key 是整数或固定长字符串，直接用 uint64_t 或 folly::StringPiece，比 std::string 少一次堆分配。
编译和链接最容易漏的三件事
Folly 对构建环境要求比一般库高，没配好会静默降级或链接失败：
- 必须启用 C++17（
-std=c++17），部分组件如folly::Synchronized依赖std::shared_mutex - 链接时要加
-lfolly -lglog -lgflags -lboost_context -lboost_thread，缺glog会导致日志组件 fallback 到 stderr，缺boost_context会让folly::coro编译失败 - 使用
folly::fibers前，必须在 main() 开头调用folly::init(&argc, &argv)，否则 fiber scheduler 初始化失败，程序可能卡死在第一次co_await
真正难的不是集成，而是判断哪条路径值得换——多数服务瓶颈在 I/O 或业务逻辑，盲目套 Folly 组件反而增加维护负担。先用 perf 或 vtune 定位 hot function，再看对应组件是否解决那个具体问题。
