先说个反直觉的结论：我最近同时用ARKit、ARCore和WebXR接了同一个室内导航项目，最后放弃ARCore的GPU压力，也放弃WebAR的帧率，改用自己拼的VIO+UWB方案。不是它们不好，而是绝大多数团队在做AR选型时，根本没搞清楚自己的副作用的容忍线。
第一个被忽视的点是「像素级定位」和「语义级定位」的混为一谈。ARCore的Cloud Anchor标称精度能到厘米级，但那是静态锚点。一旦场景里有半透明玻璃、白墙，或者天花板灯光过曝，它的特征点就跳得像心电图。我实测ARCore在房间交叉折返走30米后，累积漂移大概0.3米，而ARKit在同样路径上因为融入LiDAR深度（iPhone 12 Pro上的LiDAR在1米内深度误差约1-3cm，5米处扩大到10cm），漂移只有0.1米。但这不是决定性的——因为很多AR场景根本不需要真实世界1:1对齐，比如弹窗类效果，误差在20cm以内用户根本感知不到。真正致命的是特征点丢失后的恢复时间，ARCore平均要1.8秒，ARKit只要0.6秒。如果你做的是维修箭头叠加，这1.2秒的差距足以让用户手停在空中等你。
第二个被忽视的点是WebAR的内存和电池曲线。很多人冲着免安装选WebAR，但用WebXR跑同一个模型，iOS Safari里内存峰值是原生的2.3倍（我用的是glTF 250MB的建筑模型），帧率从原生60fps掉到42fps，而且每10分钟机身温度上升8-10度。如果你依赖相机帧做SLAM，WebXR在后台tab切换时直接冻结视觉追踪，恢复后要重新初始化，这个bug在Android Chrome和Safari上都存在。所以如果你的AR界面需要持续20分钟以上的操作，不要再试图用WebAR省包体。但反过来，如果只是做扫描二维码看个动画，WebAR的加载成本确实低很多——首屏资源可以压缩到2MB以内，而原生AR应用最小也要40MB。
第三个被忽视的点是自研SLAM的隐性成本。我们一开始觉得ARKit和ARCore封装的太好了，想自己写基于ORB-SLAM3的纯视觉定位，结果发现工程化难度远超算法本身。ORB-SLAM3在PC上跑得稳，但手机端的相机曝光、卷帘快门校正、IMU同步就写了三周。实际测试中，自研方案的定位精度（航向平均误差0.8度）确实比ARCore的1.5度好一点，但构建地图需要手动控制轨迹，不然就出现闭环不匹配。最后我们改用VIO叠加UWB吗，UWB基站的部署半径在房间内可以做到5cm精度，成本大概每100平方米四千元，加上手机自带IMU的支持，反而是最稳定的方案。现在的趋势是「视觉-惯性-超宽带」融合，而不是单纯依赖相机。
所以，我的建议是——先决定你的AR要回答「我在哪」还是「那是什么」。前者比如室内导航、机器人引导，直接用UWB+IMU踩坑之路；后者比如商品展示、特效滤镜，直接用ARKit，因为它的平面识别和光照估计（全局环境光探测速度20ms）比ARCore好上不少。至于ARCore，如果你必须适配低端Android机，而且不需要跨平台复用代码，那就用它。但别指望云端锚点能撑起多人协作——在真实网络延迟下，两个设备同时捏同一个虚拟物体，误差会在1秒内超过35cm。这不是某家算法的问题，而是物理上无法避免的。最后，无论选哪种方案，都请用真机在咖啡厅、停车场、地下商场这三种典型场景里做回归测试。我们就是漏了地下车库的荧光灯频闪，导致表面纹理识别率直接崩溃。
