凌晨两点，屏幕蓝光刺眼。
我在调试一个地图聚合的Bug。
客户说，加载十万个点的时候，浏览器卡成PPT。
我盯着日志，心里骂了一句脏话。
这帮做产品的，总觉得数据量大点没关系，反正现在硬件都强。
强个鬼。
内存溢出，主线程阻塞，用户直接关页面。
这时候，我想起了那个被遗忘在角落里的概念：geo 四叉树。
别被名字吓到。
听起来很高大上，其实道理特别朴素。
想象一下，你有一张巨大的桌子，上面撒了一把米粒。
你想快速找到某一颗特定的米。
你不可能一颗一颗去摸。
你会先把桌子分成四块。
看米粒在哪一块。
然后再把那一块分成四块。
一直分下去，直到那个格子里只有一两颗米。
这就是四叉树的核心逻辑。
分层，再分层。
对于地图数据来说，经纬度就是一个二维平面。
我们把这个平面切成四个象限。
如果某个区域点太多，就继续切。
直到每个小区域里的点数量少于阈值，比如5个。
这样，当你缩放地图的时候。
只需要判断当前视口落在了哪个节点。
然后只加载那个节点下的数据。
其他的？
直接忽略。
这就是为什么高德、百度地图能流畅缩放的原因。
他们背后都在用这种空间索引技术。
我之前在一个项目中，没用这个。
结果呢？
每次缩放，前端都要重新计算十万个点的坐标。
CPU占用率瞬间飙到100%。
风扇呼呼响，像要起飞一样。
后来换了geo 四叉树方案。
初始化时间从3秒降到了200毫秒。
缩放时的帧率，稳定在55帧以上。
那种丝滑感，真的，谁用谁知道。
当然，也不是没有坑。
我第一次写的时候，忘了处理边界情况。
有些点刚好卡在分割线上。
导致数据重复计算。
查了整整两天。
头发掉了一把。
还有，树的深度控制不好，也会出问题。
切得太深，递归调用栈溢出。
切得太浅，索引效果不明显。
这个平衡点，得靠实测数据来调。
不能拍脑袋。
我现在的做法是，先建一棵树，统计一下各层的节点数量分布。
看看是不是呈现指数级下降。
如果不是，说明切分策略有问题。
或者数据本身分布极不均匀。
比如，所有点都挤在市中心。
那市中心那块就要切得更细。
郊区可能切两刀就够了。
这种动态调整，才是高级玩法。
说回那个Bug。
我加上geo 四叉树索引后。
重新跑了一遍测试。
看着控制台里那些跳动的数字，心里那块石头终于落地。
虽然代码多了几十行。
逻辑稍微复杂了一点点。
但换来的用户体验，值了。
用户不会关心你用了什么算法。
他们只关心，点一下，有没有反应。
转一圈，卡不卡。
流畅，就是王道。
现在，我每次看到地图类的项目。
第一反应就是：
要不要上geo 四叉树？
哪怕只有几千个点。
养成这个习惯。
能帮你省去很多不必要的优化痛苦。
毕竟，好的架构，是写出来的，也是省出来的。
别等到上线前夜，才想起这回事。
那时候，真的来不及。
对了，刚才那行代码，我好像把递归终止条件写反了。
不过没关系，明天再改。
今晚先睡。
生活还得继续，代码还得接着敲。
这就是程序员的日常，粗糙，但真实。
希望这篇笔记，能帮你少走点弯路。
哪怕只是让你知道，有这么个东西存在。
下次遇到性能瓶颈，能想起它。
那就够了。
