最省内存又不卡顿的是CSR格式的std::vector封装邻接表：节点只存偏移与数量，边数据扁平化存储，用整数索引替代指针，兼顾内存效率、cache友好性与扩展性。
稀疏图用什么指针结构最省内存又不卡顿
直接说结论：别用裸指针管理超大规模稀疏图，改用 std::unique_ptr + std::vector 的组合封装邻接表，配合 std::unordered_set 或压缩索引做去重。裸指针手动 new/delete 在亿级边场景下极易内存碎片、泄漏、释放顺序错乱，且无法自动迁移——而稀疏图的边访问模式又极不规则，malloc 分配的小块内存会加剧 TLB miss。
典型错误是写成这样：
struct Node {
Edge* head; // 每个节点一个链表头
};
Edge* edges = new Edge[total_edges]; // 一次性分配所有边
// ……然后靠 next 指针串起来问题在于：插入/删除边时要改指针链，多线程根本不敢碰；迭代时 CPU cache line 利用率极低；OOM 前连 warning 都没有。
如何让邻接表支持千万级节点+十亿级边还不爆内存
核心思路是「分离存储 + 索引压缩」：节点只存边的起始偏移和数量，所有边数据扁平化进一个 std::vector<edge></edge>，再用 std::vector<uint32_t></uint32_t> 存每个节点的出边起始索引（CSR 格式）。指针只在初始化时用一次，后续全靠整数索引。
立即学习“C++免费学习笔记（深入）”；
-
std::vector<edge></edge>存所有边（Edge定义为struct { uint32_t dst; float weight; }），连续内存，cache 友好 -
std::vector<uint32_t></uint32_t>存row_ptr：第 i 个节点的出边在边数组中的起始位置 -
std::vector<uint32_t></uint32_t>存col_idx：边的目标节点 ID（已按源节点分组排序） - 节点本身不需要指针字段，访问邻居只需循环
[row_ptr[i], row_ptr[i+1])区间
这样 10 亿条边仅需约 12 GB 内存（假设每条边 8 字节 + 索引数组开销），比链表节省 40% 以上，且支持 mmap 直接加载二进制图文件。
为什么 std::shared_ptr<Node> 在图遍历中是性能陷阱
常见误区是给每个节点套一层 std::shared_ptr，以为能自动管理生命周期。实际在 BFS/DFS 遍历时，引用计数原子操作会成为热点，尤其在 NUMA 架构上跨 socket 更新计数器引发严重 cache line bouncing。
更糟的是：稀疏图中大量节点度为 0 或 1，shared_ptr 的控制块（16 字节）比节点数据本身还大，内存放大比达 3x～5x。
正确做法：
- 图结构生命周期明确（如整个程序运行期只加载一次），就用
std::vector<:unique_ptr>></:unique_ptr>或干脆std::vector<node></node>（若节点无虚函数） - 需要动态增删节点？用对象池（
std::deque<Node>+ 自由列表），避免频繁分配 - 真要共享所有权？用
std::weak_ptr缓存路径，但遍历主干必须用原始索引或迭代器
用 std::unique_ptr<Edge[]> 初始化 CSR 表时的坑
有人试图用 std::unique_ptr<edge></edge> 替代 std::vector<edge></edge> 来“更底层”，结果掉进两个坑：
- 不能 resize：CSR 构建阶段边数不确定，
unique_ptr数组大小固定，只能预估后反复 realloc + memcpy，反而更慢 - 无法移动语义优化：
std::vector的 move 构造器是 O(1)，而unique_ptr<edge></edge>move 后原对象仍持有空指针，但 vector 能保证容量信息不丢
唯一适合裸数组指针的场景，是 mmap 映射只读图文件后，用 static_cast<edge>(mapped_addr)</edge> 直接访问——这时连 unique_ptr 都不该用，因为不归你管内存。
真正棘手的是图更新：比如流式插入百万新边。这时候得切分 chunk，用 std::vector<:vector>></:vector> + 合并排序，而不是硬扛单一大数组的插入成本。
