地图产品里，前端边界会一路延伸到原生层

做地图和导航相关产品时，我很快发现它不像普通移动页面。

普通页面主要处理数据、布局和交互。地图页面还要处理定位、瓦片、坐标、路线、搜索、权限、原生 SDK、性能和网络。它看起来在前端，实际边界会一路延伸到后端服务、原生模块甚至地图厂商能力。

地图不是一张背景图

地图最容易被误解成一个视觉组件。把地图放到页面上，能缩放、能拖动，好像就完成了。

真实产品里，地图是一个运行环境。用户当前位置、路线规划、POI 搜索、瓦片加载、图层切换、路径绘制、标记点点击、离线或弱网表现，都会影响体验。任何一个环节不稳定，用户都会觉得整个产品不可信。

所以我会把地图能力拆开看：哪些应该由客户端 SDK 处理，哪些应该走后端 API，哪些需要代理，哪些只是页面状态。

不是所有地图请求都适合直接从客户端发出去。

比如瓦片代理、路线规划、服务端 key、限流和异常处理，都可能需要后端参与。天地图瓦片代理这类接口，表面上只是转发图片，实际是在把第三方服务访问方式收进自己的系统边界里。高德路线规划也类似，客户端要的是可用路线，后端要处理 key、参数、错误和返回结构。

这样做会多一层服务，但也让客户端更轻，密钥更安全，问题更容易排查。

React Native 和 Expo 能让移动端开发快很多，但地图和导航经常会撞到原生能力边界。

我做过高德地图的 Expo 原生模块，把地图、搜索和导航能力通过 TypeScript 接口暴露出来。这里的关键不只是“能调 SDK”，还包括事件怎么从原生层传回 JS，导航状态如何监听，路线计算失败如何处理，地图点击、长按、定位变化怎样变成前端能使用的事件。

这种工作会让人更清楚地看到跨端开发的真实形态：JS 层负责产品体验，原生层负责系统能力，两边之间需要一条稳定的桥。

我也做过 SwiftUI 和 Expo Router 的移动端原型，包括地图、帖子、聊天、店铺、路线、资料等页面。

这些原型不一定都走到完整产品，但它们有价值。地图类产品早期很难只靠文档判断体验，很多问题要放到手机里才看得出来：底部面板会不会挡住路线，搜索入口放哪里，地图和列表如何切换，定位按钮是否容易触达，导航状态是否足够明确。

原型能更早暴露这些问题，避免后端和数据结构都做完以后才发现产品路径不顺。

地图产品给我的经验，是不要把移动端简单看成“前端页面”。

它需要同时理解客户端体验、原生 SDK、后端代理、第三方服务、坐标和路线数据。某个问题看起来是地图没显示，实际可能是 key、瓦片、坐标系、权限、网络或原生事件没接好。

我现在看这类项目，会先确认边界：客户端负责哪些交互，后端负责哪些服务封装，原生模块负责哪些系统能力，第三方地图服务的限制在哪里。边界清楚以后，移动地图产品才不会变成一堆难排查的临时接入。