调用 unordered_map 的 load_factor() 成员函数可获取当前负载因子，其值为 size() / bucket_count()，返回只读 float 类型实时计算结果；load_factor() 与 max_load_factor() 不同，后者为可读写阈值；实际值可能因底层桶数预分配（如质数序列）而看似“不合理”；查该值主要用于调试监控，但不可用于精确容量预测或反推桶数。
直接调用 load_factor() 成员函数
查当前负载因子最简单的方法就是调用 unordered_map 实例的 load_factor()，它返回一个 float，值为 size() / bucket_count()：
std::unordered_map<int, std::string> m = {{1,"a"}, {2,"b"}, {3,"c"}};
std::cout << m.load_factor(); // 输出类似 0.75（取决于实际桶数量）
这个值是只读的实时计算结果，不缓存、不维护，每次调用都重新算——所以性能开销极小，但也不建议在热循环里频繁查。
load_factor() 和 max_load_factor() 的区别
初学者容易混淆这两个：load_factor() 是“当前实际值”，max_load_factor() 是“触发 rehash 的阈值”：
-
m.load_factor()：只读，无参数，返回当前size() / bucket_count() -
m.max_load_factor()：可读可写，无参时返回当前阈值；带float参数时设新阈值（比如m.max_load_factor(0.5)）
注意：改 max_load_factor() 不会立刻 rehash，只影响后续插入/扩容决策；已有数据不受影响。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
为什么查到的值有时看起来“不合理”？
常见困惑：明明只插了 3 个元素，load_factor() 却显示 0.1875 —— 这通常是因为底层 bucket_count() 比你预期的大得多（比如 16 或 32）。unordered_map 初始化时桶数往往按质数序列预分配（GCC 用 11→53→193…），不是按 2 的幂次增长。
验证方法：
std::cout << "size: " << m.size() << "\n"; std::cout << "bucket_count: " << m.bucket_count() << "\n"; std::cout << "load_factor: " << m.load_factor() << "\n";
如果想控制初始桶数，可用带 bucket_count 参数的构造函数：std::unordered_map<int,string> m(8);（但实际分配仍可能向上取最近质数）。
查负载因子的实际用途和坑点
查 load_factor() 主要用于调试、监控或手动触发优化，比如判断是否该 rehash() 或预分配空间。但要注意：
- 不要依赖它做精确容量预测——不同标准库实现的桶数策略不同（libstdc++ vs libc++）
- 不能用它反推桶数：
bucket_count()才是真实桶数，load_factor()只是比值 - 多线程下查
load_factor()本身是安全的（无修改），但若同时有插入操作，值可能瞬间过期
真正关键的其实是 bucket_count() 和 max_load_factor() 的组合——它们共同决定 rehash 时机，而 load_factor() 只是那个时刻的快照。
