八叉树在点云中起空间索引作用，通过递归划分三维空间为8个子立方体，仅存储各区域内的点索引，加速邻域查询；需合理设置包围盒、动态分裂阈值及球形相交检测以避免漏查。
八叉树在点云中到底起什么作用
八叉树不是万能加速器，它只在点云分布不均匀、存在大量空旷区域时才明显优于暴力遍历。如果点云密集且填满整个空间（比如体素扫描的完整模型），建树开销可能反而比直接查表还高。
核心价值是空间索引：把三维空间递归划分为 8 个子立方体，每个节点只存落在该区域内的点索引（或指针），查询某坐标附近 10 米内的点时，不用遍历全部百万级点，而是沿树下降，跳过明显无关的分支。
std::vector<point3d></point3d> 怎么塞进八叉树节点
别直接存 Point3D 对象——频繁复制拖慢建树速度。推荐存原始索引：std::vector<size_t></size_t>，指向外部点数组；或者用 std::span<const point3d></const>（C++20）避免拷贝。
建树前必须确定世界包围盒（min_bound/max_bound），这是根节点范围。常见错误是用点云 bbox 当作初始范围，但没预留缓冲，导致后续插入新点时触发重平衡或越界。
立即学习“C++免费学习笔记（深入）”；
- 初始化时建议扩大 5%～10%：
auto padding = 0.05 * (max_bound - min_bound); - 节点分裂阈值别硬写死 16 或 32 —— 点密度差异大时，用动态阈值更稳，比如按当前节点体积反比调整
- 叶子节点存点数上限建议设为 8～64，太小导致树过深，太大失去剪枝意义
查询“半径 R 内所有点”为什么常漏掉跨节点的点
八叉树的轴对齐特性决定了：一个球形查询范围必然与多个节点相交，但标准实现常只检查中心是否落入节点立方体，漏掉那些“角上擦边”的节点。
正确做法是对每个待检节点调用 intersects_sphere(center, radius)，而不是 contains_point(center)。这个函数要判断球心到节点立方体的最近距离 ≤ radius。
示例逻辑（伪代码）：
float distance_squared = 0;
for each axis in {x,y,z}:
if center[axis] < node.min[axis] distance_squared += (center[axis] - node.min[axis])²;
if center[axis] > node.max[axis] distance_squared += (center[axis] - node.max[axis])²;
return distance_squared <= radius * radius;
漏掉这个判断，R=2m 的查询可能只返回 70% 的真实邻点。
C++ 没有现成 Octree 标准库，该选哪个实现
PCL 的 pcl::octree::OctreePointCloudSearch 最成熟，但强依赖 PCL 生态，编译重、模板特化多；轻量场景推荐 nanoflann（仅头文件，支持自定义距离函数），但它本质是 KD 树，需手动改造成八叉树结构。
真正想手撸，重点不是节点类设计，而是内存管理：避免每层 new/delete——用对象池预分配节点块，或 flat octree（数组存储，父子关系靠下标计算），后者缓存友好，但深度受限。
最容易被忽略的是浮点精度陷阱：节点边界用 float 表示时，在大坐标（如 GPS 坐标系下 x=1e7）时一个 float 的最低有效位可能达米级，导致点被分错桶。务必统一用 double，或先做局部坐标归零（减去点云质心）。
