diff --git a/docs/AMap面试题.md b/docs/AMap面试题.md
index 26fd3bd..278047d 100644
--- a/docs/AMap面试题.md
+++ b/docs/AMap面试题.md
@@ -973,3 +973,1121 @@ zIndex 只决定视觉上的前后遮挡，不产生任何数据上的从属关
 ## 总结一句话
 
 > **高德地图中所有覆盖物（ImageLayer、Marker、Polygon 等）都是 `mapInstance` 的平级子节点，视觉上的"谁在谁上面"由 zIndex 控制，数据上互不隶属。**
+
+
+---
+## Q10：SPA 中如何管理地图实例生命周期以防止内存泄漏？
+
+---
+
+## 题目
+
+在单页应用中，你实现了高德地图的异步加载和按需引入。当用户频繁切换地图页面时，请回答：
+
+1. **如何实现 JSAPI 的异步加载，避免阻塞首屏渲染？**
+2. **页面切换时，旧地图实例如果不销毁会有什么后果？**
+3. **`map.destroy()` 到底销毁了什么？只把 DOM 清空就够了吗？**
+
+> 注：本题侧重**内存泄漏防止**，关于 SDK 单例加载的细节已覆盖在 Q1/Q2。
+
+---
+
+## 参考答案
+
+### 1. 异步加载机制
+
+JSAPI 不放在 `index.html` 中用 `<script>` 引入，而是通过 `@amap/amap-jsapi-loader` 的 `AMapLoader.load()` 动态加载。原因：
+
+| 方式 | 阻塞首屏 | 加载时机 | 多页面复用 |
+|------|---------|----------|-----------|
+| `<script>` 同步 | ❌ 阻塞 | 页面初始化（即使不访问地图页） | 全局一次 |
+| `<script>` defer/async | ✅ 不阻塞 | 但依然提前下载 | 全局一次 |
+| `AMapLoader.load()` 按需 | ✅ 不阻塞 | **真正需要时才发起请求** | 配合单例缓存 |
+
+加载逻辑的核心原则：**Promise 去重 + 结果缓存**，Q1 的 `loadAMap()` 已详细说明。
+
+### 2. 不销毁旧地图实例的后果
+
+页面切换时如果只让组件卸载而不调用 `map.destroy()`：
+
+| 资源 | 后果 |
+|------|------|
+| **WebGL 上下文** | 浏览器对单个标签页的 WebGL 上下文数量有限（通常 8~16 个），多次切换后超出上限，新地图创建失败 |
+| **DOM 节点** | 地图容器虽然随 Vue 组件移除，但 AMap 内部可能保留了 detached DOM 引用，阻止 GC |
+| **事件监听器** | 地图绑定的 `click`、`moveend`、`zoomend` 等事件仍挂在已卸载的 DOM 上，形成闭包引用链 |
+| **定时器** | 地图内部的动画帧、瓦片加载定时器未被清除，持续消耗 CPU |
+| **内存** | 单次泄漏可能只有 5~20MB，但用户切换 20 次页面后内存暴涨到 400MB+，移动端直接卡死或白屏 |
+
+> 这就是"温水煮青蛙"式的内存泄漏——单次无害，累积致命。
+
+### 3. `map.destroy()` 做了什么
+
+`destroy()` 并非简单清空 DOM，而是分五步清理：
+
+```
+① 停止所有内部定时器（瓦片加载、动画帧、位置更新）
+② 移除所有事件监听器（内置 + 用户自定义）
+③ 销毁 WebGL 渲染上下文（释放 GPU 资源）
+④ 移除所有覆盖物（Marker、Polygon、InfoWindow 等）← 注意！
+⑤ 清空地图容器 DOM 的内容
+```
+
+**一个常被忽略的点**：`destroy()` 会销毁地图上的**所有覆盖物**，但如果你把 Marker 引用存入全局变量或 Vue reactive state，这些引用不会自动清空——它们变成了"僵尸引用"（指向已销毁的底层对象）。正确的做法：
+
+```ts
+// ✅ 正确：先清空引用再销毁
+function destroyMap() {
+  markers.forEach(m => m.setMap(null))  // 逐个移除
+  markers.length = 0                     // 清空引用数组
+  mapInstance.value?.destroy()
+  mapInstance.value = null
+}
+```
+
+### 在 `useAmap()` 中的生命周期自动化
+
+Q1 中 `useAmap()` 的 `destroyMap()` 配合 `onUnmounted` 自动调用，确保组件卸载时地图一定被销毁。这是防御性编程——即使开发者忘记手动调用，框架也会兜底。
+
+---
+
+## 总结一句话
+
+> **`map.destroy()` 不止清 DOM——它释放 WebGL 上下文、解绑事件、停定时器、销毁覆盖物；不调用的后果是"切页 20 次，内存 400MB+"。生命周期自动化（`onUnmounted` 兜底）是防止人为遗忘的最后防线。**
+
+
+---
+## Q11：如何处理 GPS 原始坐标与地图坐标系的偏差？
+
+---
+
+## 题目
+
+后端返回了一批通过硬件设备采集的 GPS 原始经纬度坐标，直接在高德地图上渲染出现了百米级偏差。请回答：
+
+1. **为什么会偏差？WGS-84、GCJ-02、BD-09 分别代表什么？**
+2. **前端有哪些方式进行坐标转换？各有什么优劣？**
+3. **如果后端数据要同时给高德、腾讯、百度三个地图使用，架构上怎么设计？**
+
+---
+
+## 参考答案
+
+### 1. 三大坐标系
+
+| 坐标系 | 别名 | 使用方 | 说明 |
+|--------|------|--------|------|
+| **WGS-84** | 地球坐标系 / GPS 原始坐标 | GPS 硬件、国际标准 | 最原始的经纬度，无任何偏移 |
+| **GCJ-02** | 火星坐标系 / 国测局坐标 | 高德、腾讯、Google 中国 | 在 WGS-84 基础上加偏移算法（非线性），偏移量几十到几百米 |
+| **BD-09** | 百度坐标系 | 百度地图 | 在 GCJ-02 基础上再次加密偏移 |
+
+**为什么会有偏移？** 中国法律规定地图服务商必须使用 GCJ-02 加密坐标系，不得直接展示 WGS-84 原始坐标。偏移算法是非线性的——并非简单的"加几米"。
+
+**关键结论**：GPS 硬件采集 → WGS-84；高德/腾讯地图 → GCJ-02；百度地图 → BD-09。
+
+### 2. 前端坐标转换方案
+
+| 方案 | 原理 | 优点 | 缺点 |
+|------|------|------|------|
+| **`AMap.convertFrom()`** | 高德官方 API，上传坐标批量转换 | 官方保证精度，转换结果可直接用于高德地图 | 依赖网络请求（异步），有 QPS 限制，仅返回 GCJ-02 |
+| **`gcoord` 库** | 纯前端 JS 算法，本地计算 | 离线可用，无网络依赖，支持所有坐标系互转 | 精度略低于官方 API（算法是逆向推算的），约 1~5 米误差 |
+| **`coordtransform` 库** | 同上，纯 JS 算法 | 同上，体积更小 | 同上，维护不如 gcoord 活跃 |
+
+**前端本地转换示例**（以 `gcoord` 为例）：
+
+```ts
+import gcoord from 'gcoord'
+
+// GPS 原始坐标 → 高德/腾讯可用坐标
+const [gcjLng, gcjLat] = gcoord.transform(
+  [wgs84Lng, wgs84Lat],  // 输入 WGS-84
+  gcoord.WGS84,           // 从
+  gcoord.GCJ02             // 到
+)
+
+// GCJ-02 → 百度
+const [bdLng, bdLat] = gcoord.transform(
+  [gcjLng, gcjLat],
+  gcoord.GCJ02,
+  gcoord.BD09
+)
+```
+
+### 3. 多地图架构设计
+
+如果同一个后端服务要给高德、腾讯、百度三个前端地图提供数据，**推荐做法是在后端存储 WGS-84 原始坐标，各端按需自行转换**：
+
+```
+GPS 硬件 → 后端存 WGS-84（原始值）
+              │
+   ┌──────────┼──────────┐
+   ▼          ▼          ▼
+高德前端     腾讯前端    百度前端
+WGS→GCJ-02   WGS→GCJ-02  WGS→GCJ-02→BD-09
+(gcoord)    (gcoord)    (gcoord)
+```
+
+**为什么不存 GCJ-02？** GCJ-02 的偏移算法属于"黑盒"——虽然 `gcoord` 可以逆向推算回 WGS-84，但会有二次精度损失。存原始值，各端一次性转换，精度最高。
+
+**为什么不通过后端提前转换？** 会引入不必要的耦合——后端需要感知前端使用哪个地图服务。保持后端返回原始 GPS 数据，各前端在自己这一层处理坐标转换，职责清晰。
+
+---
+
+## 总结一句话
+
+> **GPS 设备出 WGS-84，高德/腾讯吃 GCJ-02，百度吃 BD-09；前端用 `gcoord` 离线转换或调 `AMap.convertFrom` 在线转换；后端始终存 WGS-84 原始值，各端按需自转，避免二次精度损失。**
+
+
+---
+## Q12：地图上展示 10000+ 个 Marker，如何防止卡顿？
+
+---
+
+## 题目
+
+你的项目中需要在一个地图视野内展示 10000+ 个门店/共享单车的位置。如果直接 `new AMap.Marker` 一万次，页面会严重卡顿甚至崩溃。请回答：
+
+1. **为什么普通 Marker 在万级数量下会卡顿？瓶颈在哪？**
+2. **有哪些优化方案？各自的适用场景和上限是什么？**
+3. **如果这 1 万个 Marker 需要不同的自定义样式（颜色、图标、大小），方案如何调整？**
+
+---
+
+## 参考答案
+
+### 1. 普通 Marker 为什么卡
+
+每个 `AMap.Marker` 都是独立的 DOM 节点。一万个 Marker = 一万个 `<div>` + 事件监听器 + 样式计算：
+
+| 瓶颈 | 说明 |
+|------|------|
+| **DOM 节点数** | 一万个 DOM 节点，浏览器的布局、重绘、合成开销呈超线性增长 |
+| **内存** | 每个 Marker 大约 2~5KB（DOM + 事件 + 内部对象），一万个 ≈ 20~50MB |
+| **事件** | 每个 Marker 绑定 click/hover 等事件，事件委托做不到（AMap 内部实现限制） |
+| **平移/缩放** | 每次地图移动，一万个 Marker 全部重新计算屏幕坐标并更新 DOM position → 帧率掉到个位数 |
+
+### 2. 三种优化方案
+
+#### 方案 A：点聚合（MarkerClusterer）
+
+**原理**：低缩放级别时把邻近 Marker 合并为一个数字气泡（如"🔵 237"），放大到一定级别才展开为独立 Marker。
+
+**适用**：数据有自然聚集特性（如城市门店分布），用户需要看清单个 Marker 的细节，有层级缩放交互需求。
+
+**上限**：实际性能取决于"展开后可见 Marker 数"，聚合状态本身很轻量。展开后是普通 DOM Marker，所以上限仍然是 2000~3000 个可见 Marker。
+
+**加载方式**：
+
+```ts
+// 前提：AMAP_PLUGINS 中包含 'AMap.MarkerClusterer'
+const cluster = new AMap.MarkerClusterer(map, markers, {
+  gridSize: 80,          // 聚合网格大小（像素）
+  maxZoom: 18,           // 超过此级别不再聚合
+  averageCenter: true,   // 聚合点取质心而非第一个点
+})
+```
+
+#### 方案 B：海量点类（AMap.MassMarks）
+
+**原理**：放弃 DOM，改用 **HTML5 Canvas** 在单一图层上绘制所有点。一个 Canvas 画布画十万个圆点 ≈ 0 个 DOM 节点。
+
+**适用**：不需要复杂 HTML 自定义样式，只需展示点位/图标；用户不需要单独操作每个点（拖拽、右键菜单等）。
+
+**上限**：轻松支持 10 万级，百万级开始吃力（Canvas 重绘耗时）。
+
+```ts
+const massMarks = new AMap.MassMarks(data, {
+  url: '/assets/marker-icon.png',   // 统一图标
+  size: [20, 20],                    // 图标大小
+  anchor: new AMap.Pixel(10, 10),    // 锚点
+  zIndex: 200,
+})
+massMarks.setMap(map)
+```
+
+**MassMarks vs 普通 Marker 的核心差异**：
+
+| 维度 | 普通 Marker | MassMarks |
+|------|-----------|-----------|
+| 渲染方式 | 独立 DOM 节点 | Canvas 统一绘制 |
+| 自定义 HTML | ✅ 支持 | ❌ 只支持图片 URL |
+| 独立事件 | ✅ 每个可绑定 | ⚠️ 有统一 click 事件，通过 `e.data` 区分 |
+| 拖拽 | ✅ | ❌ |
+| 10 万点性能 | 崩溃 | 流畅 30fps+ |
+
+#### 方案 C：Loca 数据可视化（WebGL）
+
+**原理**：基于 Three.js 的 WebGL 渲染引擎，全部点位数据一次性上传到 GPU 缓冲区，利用 GPU 并行计算渲染。
+
+**适用**：百万级数据、3D 可视化、动态特效（热力图、飞线、柱状图）。
+
+**上限**：百万级流畅，千万级需要分片。
+
+**缺点**：开发成本较高，需要额外引入 Loca 库，API 与核心 Marker 不兼容。
+
+### 3. 需要自定义样式怎么办
+
+如果一万个 Marker 需要**不同的颜色/图标/大小**，普通 Marker 扛不住，MassMarks 又不支持自定义 HTML。策略：
+
+| 场景 | 方案 |
+|------|------|
+| 几种固定样式（如红/黄/绿 3 种状态） | 使用 **多个 MassMarks 图层**，每种样式一个图层，按数据分类分别渲染 |
+| 样式完全动态（如渐变颜色、旋转角度） | 升级到 **Loca** 的 `ScatterLayer` 或 `IconLayer`，支持按数据字段驱动颜色、大小 |
+| 必须用 HTML 自定义但数量可控 | 先用聚类/MassMarks 展示全局，点击/搜索时按需创建少量 DOM Marker |
+
+---
+
+## 总结一句话
+
+> **千级用普通 Marker + 聚合，万级用 MassMarks（Canvas），十万级用 Loca（WebGL）。关键是选对渲染引擎——DOM → Canvas → WebGL 性能逐级提升，但灵活性逐级下降。**
+
+
+---
+## Q13：如何做到"地图拖拽/缩放时只加载当前视野内的数据"？
+
+---
+
+## 题目
+
+后端数据库有百万条地理数据，前端不可能一次性加载完。请设计一个方案，实现"用户拖拽或缩放地图时，只请求当前屏幕视野内的数据"。
+
+---
+
+## 参考答案
+
+### 1. 核心流程
+
+```
+地图视野变化
+    │
+    ├─ 'moveend' / 'zoomend' 事件
+    │
+    ├─ map.getBounds() → 获取当前视窗四至
+    │    ├─ NorthEast: [lng_max, lat_max]
+    │    └─ SouthWest: [lng_min, lat_min]
+    │
+    ├─ 防抖 300ms（避免拖拽过程中频繁请求）
+    │
+    ├─ GET /api/data?sw_lat=39.90&sw_lng=116.28&ne_lat=39.98&ne_lng=116.45
+    │
+    └─ 后端 WHERE lat BETWEEN sw_lat AND ne_lat AND lng BETWEEN sw_lng AND ne_lng
+```
+
+### 2. 关键实现细节
+
+#### 获取 BBox
+
+```ts
+map.on('moveend', () => {
+  const bounds = map.getBounds()
+  const ne = bounds.getNorthEast()  // { lng, lat }
+  const sw = bounds.getSouthWest()  // { lng, lat }
+  // 传给后端
+})
+```
+
+**注意**：`moveend` 在平移结束时触发，`zoomend` 在缩放结束时触发。两者是独立事件，需要同时监听。`zoomchange` 在缩放手势过程中触发（很频繁），不适合发请求。
+
+#### 防抖（Debounce）
+
+核心：用户连续拖拽时，每次 `moveend` 都触发但请求只发最后一次：
+
+```ts
+let debounceTimer: ReturnType<typeof setTimeout>
+
+map.on('moveend', () => {
+  clearTimeout(debounceTimer)
+  debounceTimer = setTimeout(() => fetchData(), 300)
+})
+```
+
+300ms 是一个平衡值——太短（100ms）依然频繁请求，太长（500ms+）用户感觉"数据加载延迟明显"。
+
+#### 后端 SQL 优化
+
+```sql
+SELECT * FROM locations
+WHERE lat BETWEEN #{sw_lat} AND #{ne_lat}
+  AND lng BETWEEN #{sw_lng} AND #{ne_lng}
+```
+
+**必须给 `lat` 和 `lng` 建联合索引**，否则百万级表全表扫描必超时。
+
+### 3. 进阶优化
+
+#### 缩放自适应（与 Q6 同理）
+
+缩放级别低（看全国）时视口范围大但不需要返回全量数据——用户不需要看几万个点：
+
+| zoom | 策略 |
+|------|------|
+| < 8 | 返回聚合后的城市级汇总数据（如每省 Top 10） |
+| 8~12 | 返回展平但抽稀后的数据（最多 2000 条） |
+| > 12 | 按视口精确查询，返回全量 |
+
+**做法**：前端把 `zoom` 也传给后端，后端在 SQL 中加 `LIMIT` 或调用预聚合表。
+
+#### 视口裁剪（前端侧）
+
+即使后端返回了当前视口的所有数据，地图上如果画了 Polyline 等覆盖物，也应只渲染视口内的部分：
+
+```ts
+const bounds = map.getBounds()
+polylines.forEach(poly => {
+  // 判断 polyline 的 path 是否与 bounds 相交
+  const visible = poly.getPath().some(p => bounds.contains(p))
+  poly.setMap(visible ? map : null)
+})
+```
+
+这叫"前端视口裁剪"，Q6 的方案八已详述。
+
+#### 请求去重
+
+如果防抖期间的旧请求还没返回，用户又拖到了新位置，应取消旧请求：
+
+```ts
+let abortController: AbortController | null = null
+
+async function fetchData(bounds) {
+  abortController?.abort()           // 取消旧请求
+  abortController = new AbortController()
+  const res = await fetch(url, { signal: abortController.signal })
+  // ...
+}
+```
+
+---
+
+## 总结一句话
+
+> **`moveend` + `getBounds()` 取四至 → 防抖 300ms → 带 zoom 参数传给后端 → 后端联合索引范围查询 → 前端视口裁剪只渲染可见覆盖物。三层按需（请求按需、返回按需、渲染按需）缺一不可。**
+
+
+---
+## Q14：如何实现"骑手/车辆沿道路平滑移动"？
+
+---
+
+## 题目
+
+后端每隔 5 秒推送一次骑手的最新经纬度。如果直接 `marker.setPosition(newPos)`，小车会在地图上闪烁跳跃。请回答：
+
+1. **为什么直接 `setPosition` 会闪烁？**
+2. **如何使用高德的 `moveTo` / `moveAlong` 实现平滑移动？**
+3. **车头方向如何跟随路径自动旋转？**
+
+---
+
+## 参考答案
+
+### 1. 直接 `setPosition` 的问题
+
+两个 GPS 点之间间隔 5 秒，假设车速 40km/h，两点距离 ≈ 55 米。直接跳过去：
+- 视觉上小车"瞬移"——上一帧在东，下一帧出现在 55 米外
+- 地图的平滑惯性拖拽会放大这种跳跃感
+- 没有"运动轨迹"，用户感觉不真实
+
+### 2. `moveTo` vs `moveAlong`
+
+高德 Marker 提供了两个动画方法：
+
+| 方法 | 行为 | 适用场景 |
+|------|------|---------|
+| `marker.moveTo(lnglat, speed)` | 从当前位置**直线移动到目标点**，自动插值中间帧 | 单次位置更新（如 GPS 推送新坐标） |
+| `marker.moveAlong(path, speed)` | 沿**折线路径**逐段移动，路径拐弯时自动跟随 | 已知完整路径（如路线规划后的动画） |
+
+**参数说明**：
+- `lnglat`：`[lng, lat]` 或 `AMap.LngLat` 目标位置
+- `path`：坐标数组，如 `[[lng1,lat1], [lng2,lat2], ...]`
+- `speed`：移动速度，单位 **公里/小时**（注意不是米/秒）
+
+### 3. 实时推送场景的最佳实践
+
+后端 5 秒推送一次，用 `marker.moveTo()` 实现平滑过渡：
+
+```ts
+// 收到 GPS 推送
+function onGpsUpdate(newPos: [number, number]) {
+  // 计算合理的 speed：distance(m) / 5000(ms) = m/ms → km/h
+  const distance = AMap.GeometryUtil.distance(lastPos, newPos)  // 米
+  const speed = (distance / 1000) / (5 / 3600)  // km/h
+
+  marker.moveTo(newPos, speed)
+
+  // 更新角度（如果需要手动控制旋转）
+  const angle = AMap.GeometryUtil.getAngle(lastPos, newPos)
+  marker.setAngle(angle)  // 如果没设 autoRotation
+
+  lastPos = newPos
+}
+```
+
+**为什么 `moveTo` 比 `setPosition` 更好？** `moveTo` 内部使用 `requestAnimationFrame` 循环，在两个坐标之间做线性插值，视觉上小车是"滑过去"而不是"跳过去"。如果后端推送间隔是 5 秒，`moveTo` 的动画时长正好也是 5 秒，下一次推送到达时小车刚好滑到终点，视觉上连续无缝。
+
+### 4. 车头方向旋转
+
+| 方式 | 说明 |
+|------|------|
+| `autoRotation: true`（Marker 构造参数） | 配合 `moveAlong()` 使用，自动根据路径向量计算旋转角度。**只对 `moveAlong` 生效**，对 `moveTo` 无效 |
+| `marker.setAngle(angle)` | 手动设置旋转角度。`AMap.GeometryUtil.getAngle(p1, p2)` 计算两点相对于正北方向的夹角 |
+
+```ts
+// 手动计算角度
+const angle = AMap.GeometryUtil.getAngle(
+  new AMap.LngLat(prevLng, prevLat),
+  new AMap.LngLat(currLng, currLat)
+)
+marker.setAngle(angle)
+```
+
+**注意**：`angle` 是相对于正北方向的顺时针角度（0°=北, 90°=东, 180°=南, 270°=西），这与常规数学坐标系不同。
+
+### 5. 扩展：Q4 中的"路线规划 + 动画"
+
+本场景（实时推送）与 Q4 的"路线规划后沿固定路径动画"不同：
+
+| 维度 | Q4 场景 | 本场景 |
+|------|---------|--------|
+| 数据来源 | 路线规划返回的完整路径 | 后端实时推送的离散 GPS 点 |
+| 移动方法 | `setInterval` + `setPosition`（降采样路径） | `marker.moveTo()` |
+| 路径已知 | 全部已知 | 只有当前目标点 |
+| 方向控制 | 降采样点之间角度一致，无需额外计算 | 每次推送后需重新计算角度 |
+
+---
+
+## 总结一句话
+
+> **实时推送用 `marker.moveTo(newPos, speed)` 替代 `setPosition`，内部 rAF 线性插值实现平滑滑动；车头方向用 `AMap.GeometryUtil.getAngle` 计算正北夹角 + `setAngle`，或对固定路径用 `autoRotation` + `moveAlong`。**
+
+
+---
+## Q15：如何实现电子围栏（GeoFence）与越界判断？
+
+---
+
+## 题目
+
+共享单车禁停区、配送运营范围等业务需要在地图上绘制多边形电子围栏，并判断用户/车辆当前位置是否在围栏内。请回答：
+
+1. **如何绘制和编辑多边形围栏？**
+2. **如何判断一个点是否在多边形内部？**
+3. **围栏数据如何与后端同步？格式怎么设计？**
+
+---
+
+## 参考答案
+
+### 1. 绘制与编辑多边形
+
+#### 绘制围栏
+
+使用 `AMap.Polygon` + `AMap.MouseTool`（鼠标工具插件）：
+
+```ts
+// 前提：AMAP_PLUGINS 中包含 'AMap.MouseTool'
+const mouseTool = new AMap.MouseTool(map)
+
+// 进入多边形绘制模式
+mouseTool.polygon({
+  strokeColor: '#FF33FF',
+  strokeWeight: 2,
+  fillColor: '#FF33FF',
+  fillOpacity: 0.2,
+})
+
+mouseTool.on('draw', (e) => {
+  const polygon = e.obj       // AMap.Polygon 实例
+  const path = polygon.getPath()  // 顶点坐标数组
+  // 保存 path 到后端
+})
+```
+
+#### 编辑围栏
+
+使用 `AMap.PolygonEditor` 插件，让运营人员可以拖拽修改围栏：
+
+```ts
+// 前提：AMAP_PLUGINS 中包含 'AMap.PolygonEditor'
+const editor = new AMap.PolygonEditor(map, polygon)
+
+editor.open()   // 进入编辑模式 → 顶点可拖拽、边可添加新顶点
+editor.close()  // 退出编辑模式
+editor.on('adjust', () => {
+  const newPath = polygon.getPath()  // 编辑后的新坐标
+})
+```
+
+**交互设计要点**：编辑和查看是两个模式。查看模式下 polygon 不可编辑（避免误拖），点击"编辑围栏"按钮后才 `editor.open()`。
+
+### 2. 点在多边形内判断
+
+高德提供了 **`AMap.GeometryUtil`** 空间计算插件（需在 `AMAP_PLUGINS` 中声明 `'AMap.GeometryUtil'`）：
+
+```ts
+const isInside = AMap.GeometryUtil.isPointInRing(
+  new AMap.LngLat(userLng, userLat),  // 待判断的点
+  polygon.getPath()                     // 多边形顶点数组（环形）
+)
+// true → 在围栏内
+// false → 在围栏外
+```
+
+**`isPointInRing` vs `isPointInPolygon`**：
+- `isPointInRing(ring)`：判断是否在一个环内
+- `isPointInPolygon(path)`：判断是否在一个多边形内（可能包含多个环/孔洞）
+
+对于简单围栏，两者等价。对于有孔洞的复杂围栏（如"区域内但排除某个湖"），需要用 `isPointInPolygon`。
+
+**性能**：GeometryUtil 的方法是纯 JS 计算（射线法），单次判断耗时 < 0.1ms。但如果要同时判断 **1 万个点在 500 个围栏中**（如"所有共享单车是否在禁停区"），需要优化为空间索引（R-Tree）。
+
+### 3. 围栏数据的存储格式
+
+多边形围栏本质上是一个**有序的坐标数组**：
+
+```json
+{
+  "id": "geofence-001",
+  "name": "配送范围 - 朝阳区",
+  "type": "delivery_zone",
+  "path": [
+    [116.443, 39.921],
+    [116.451, 39.925],
+    [116.455, 39.918],
+    [116.447, 39.914]
+  ],
+  "updatedAt": "2025-01-15T10:30:00Z"
+}
+```
+
+**关键约束**：
+- 顶点顺序必须是**顺时针或逆时针**（不能乱序）
+- 首尾不需要闭合（AMap 会自动闭合）
+- 坐标使用 **GCJ-02**（高德坐标系），如果后端存的是 WGS-84，前端加载后要先转换（见 Q11）
+- 经纬度精度保留 **6 位小数**足够（约 0.1 米精度）
+
+### 4. 越界告警的实时检测
+
+场景：配送员骑行中，每 3 秒上报一次位置，需检测是否离开配送范围。
+
+```
+GPS 推送 → 坐标转换(WGS→GCJ) → isPointInRing → 结果
+                                              ├─ true → 正常
+                                              └─ false → 弹窗告警 + 语音提示
+```
+
+**性能优化**：如果围栏数量多（如全国几千个运营区），不要遍历所有围栏判断。先用 BBox 粗略过滤——围栏的 BoundingBox 都不包含该点 → 直接跳过。
+
+```ts
+function isInAnyGeoFence(point, geoFences) {
+  return geoFences.some(fence => {
+    // 粗筛：BBox 不包含 → 跳过
+    if (!fence.bbox.contains(point)) return false
+    // 精判：射线法
+    return AMap.GeometryUtil.isPointInRing(point, fence.path)
+  })
+}
+```
+
+---
+
+## 总结一句话
+
+> **`AMap.MouseTool` 绘制 + `PolygonEditor` 编辑 → 围栏数据存为有序坐标数组 → `GeometryUtil.isPointInRing()` 判断越界 → 先用 BBox 粗筛、再射线法精判，多围栏场景避免全量遍历。**
+
+
+---
+## Q16：物流场景下多途经点路线如何规划？
+
+---
+
+## 题目
+
+司机从 A 点出发，途中去 B、C、D 等 10 个地方送货，最后到达 E 点。请回答：
+
+1. **如何使用高德规划多途经点路线？**
+2. **高德途经点有数量上限吗？超出上限怎么处理？**
+3. **如何优化途经点的顺序？（旅行商问题 TSP）**
+
+---
+
+## 参考答案
+
+### 1. `AMap.Driving` 多途经点规划
+
+`Driving.search()` 支持 `waypoints` 参数，可以传入途经点数组。但要注意**途经点有顺序**——高德不会自动帮你排序（不会解决 TSP 问题），它按照你传入的顺序依次经过。
+
+```ts
+const driving = new AMap.Driving({
+  map: map,
+  policy: 0,           // 0=速度优先, 1=费用优先, 2=距离优先
+  autoFitView: true,   // 自动调整视野
+})
+
+driving.search(
+  start,                                    // 起点 LngLat
+  end,                                      // 终点 LngLat
+  {
+    waypoints: [B, C, D],                   // 途经点数组（按此顺序经过）
+    extensions: 'all',                      // 返回详细信息
+  },
+  (status, result) => {
+    if (status === 'complete') {
+      // result.routes[0] → 完整路线
+    }
+  }
+)
+```
+
+**注意**：Q4 中的 `Driving.search` 用于两点路线，本场景是**多途经点**版本，使用方式一样但多了 `waypoints` 参数。基础流程（Promise 包装、路径拼接、折线绘制）完全一致。
+
+### 2. 途经点上限与超限处理
+
+高德原生 **最多支持 16 个途经点**（含起终点总计 18 个点）。如果业务有 20+ 个途经点，需要分段：
+
+```
+方案一：服务端分段
+  后端对 20 个点做路径拓扑排序 → 分段为 A→F→K、K→P→E
+  前端分两次调用 driving.search()，用两条 Polyline 绘制
+
+方案二：前端分段
+  将途经点按地理位置分组（如按城市/区域）
+  每组内调用一次 driving.search()
+  组之间的连接用直线（或调用一次无途经点的短程规划）
+```
+
+**服务端分段更优**：因为后端可以一次性跑完 TSP 排序并分段，前端只需按顺序请求。前端分段的"组间连接"精度差且实现复杂。
+
+### 3. TSP 排序（旅行商问题）
+
+高德 **不会** 帮你优化途经点的访问顺序。如果用户只是随意添加了 B、C、D 三个点，按现有顺序可能会绕远路。但 **TSP 是一个 NP-hard 问题**，精确求解在途经点 > 10 时耗时过长。
+
+实际做法：
+
+| 途经点数 | 策略 |
+|---------|------|
+| ≤ 8 | 暴力枚举全排列，取总距离最短者（8! = 40320，前端可承受） |
+| 9~20 | 使用**最近邻贪心算法**或**遗传算法**逼近最优解，放在后端计算 |
+| 20+ | 配合分段策略，每组内再贪心排序 |
+
+```ts
+// 最近邻贪心（前端轻量实现）
+function greedyTSP(points: LngLat[]): LngLat[] {
+  const result = [points[0]]          // 从第一个点开始
+  const remaining = points.slice(1)
+
+  while (remaining.length > 0) {
+    const last = result[result.length - 1]
+    let nearestIdx = 0
+    let nearestDist = Infinity
+
+    remaining.forEach((p, i) => {
+      const d = last.distance(p)      // AMap LngLat 自带 distance 方法
+      if (d < nearestDist) {
+        nearestDist = d
+        nearestIdx = i
+      }
+    })
+
+    result.push(remaining[nearestIdx])
+    remaining.splice(nearestIdx, 1)
+  }
+
+  return result
+}
+```
+
+**提醒**：TSP 排序的结果可能不是用户期望的顺序（如必须先送药品、后送普通货物）。如果业务有优先级约束，不要完全依赖算法排序——把"必须按某顺序"的点前置固定，只对"无所谓顺序"的点做优化。
+
+### 4. 完整流程
+
+```
+后端返回 15 个配送点
+    │
+    ├─ 后端 TSP 排序（贪心）→ 优化路径顺序
+    │
+    ├─ 前端拿到排序后的 15 个点
+    │
+    ├─ 调用 driving.search(start, end, { waypoints: 15个点 })
+    │   → 未超 16 上限，一次搞定
+    │
+    ├─ 从 result.routes[0].steps 提取完整 path
+    │
+    └─ new AMap.Polyline({ path }) + map.add()
+```
+
+---
+
+## 总结一句话
+
+> **`Driving.search` + `waypoints` 参数支持多途经点，上限 16 个；超出则服务端分 2 段；途经点顺序需自行做 TSP 排序（≤8 全排列，>8 贪心），高德不做自动排序。**
+
+
+---
+## Q17：如何自定义地图样式？内网环境能离线用高德吗？
+
+---
+
+## 题目
+
+公司大屏项目需要暗黑科技风格的地图，原生样式不符合需求。另外，系统可能部署在完全隔离内网的政府/军队环境。请回答：
+
+1. **如何自定义高德地图的样式？**
+2. **高德 JSAPI 支持离线部署吗？如果不支持，替代方案是什么？**
+
+---
+
+## 参考答案
+
+### 1. 自定义地图样式
+
+#### 方式一：自定义地图平台（推荐）
+
+通过高德官方"自定义地图"平台（`https://lbs.amap.com/dev/mapstyle/`）可视化配置：
+
+1. 在线调整地图元素样式（底色、道路颜色、建筑颜色、文字颜色等）
+2. 保存后生成一个 `style_id`，形如 `amap://styles/darkblue`
+3. 在地图初始化时传入 `mapStyle` 参数
+
+```ts
+const map = new AMap.Map(container, {
+  mapStyle: 'amap://styles/darkblue',  // 高德预设暗色风格
+  // 或使用自定义 style_id
+  // mapStyle: 'amap://styles/2a9e5f8c3b7d4e6f1a0b2c3d4e5f6a7b',
+})
+```
+
+**高德内置了几个预设风格**：
+
+| style_id | 效果 |
+|----------|------|
+| `amap://styles/normal` | 默认标准 |
+| `amap://styles/dark` | 暗黑风格 |
+| `amap://styles/light` | 浅色风格 |
+| `amap://styles/whitesmoke` | 白烟风格 |
+| `amap://styles/fresh` | 清新风格 |
+| `amap://styles/grey` | 灰色风格 |
+| `amap://styles/graffiti` | 涂鸦风格 |
+| `amap://styles/macaron` | 马卡龙风格 |
+| `amap://styles/darkblue` | 暗夜蓝风格 |
+| `amap://styles/blue` | 极夜蓝风格 |
+
+#### 方式二：自定义 Mapbox 风格规范
+
+高德 JSAPI v2.0 支持 Mapbox 风格规范的 JSON。你可以在自定义地图平台导出 JSON 配置，直接传入：
+
+```ts
+const map = new AMap.Map(container, {
+  mapStyle: 'amap://styles/darkblue',
+  features: ['bg', 'road', 'building'],  // 控制图层显示（见 Q8）
+  showLabel: true,       // 是否显示标注
+  showBuildingBlock: true, // 是否显示 3D 建筑
+})
+```
+
+**结合 Q8 的知识**：在自定义样式的地图上叠加 ImageLayer 时，可以用 `setFeatures` 进一步去掉 POI 文字标注，实现完全自定义的视觉效果。
+
+### 2. 离线部署问题
+
+#### 高德官方不支持完全离线
+
+**结论：高德 JSAPI 不支持完全离线部署。** 原因：
+
+| 依赖项 | 说明 |
+|--------|------|
+| **地图瓦片** | 地图图片切片托管在高德 CDN 上，`https://wprd0{1-4}.is.autonavi.com/...` |
+| **字体文件** | POI 标注的字体文件动态加载 |
+| **插件脚本** | `AMap.Driving`、`AMap.Geolocation` 等插件的 JS 文件从 CDN 按需加载 |
+| **服务端 API** | 路线规划、地理编码、逆地理编码等依赖高德服务端接口 |
+| **用户协议** | 高德的使用条款禁止离线缓存瓦片 |
+
+#### 替代方案：OpenLayers / Leaflet + GeoServer
+
+对于**完全断网的内网环境**，技术栈需要完全替换：
+
+```
+公网方案：                 内网方案：
+                         
+高德 JSAPI                OpenLayers / Leaflet
+高德瓦片 CDN      →       本地 GeoServer + 预下载瓦片
+高德服务端 API     →       自行实现或使用开源替代（如 OSRM 路线规划）
+高德定位服务       →       纯前端 IP 定位 或 不上定位功能
+```
+
+**三步落地**：
+
+1. **搭建瓦片服务器**：部署 GeoServer 或直接 Nginx 静态文件服务
+2. **下载地图瓦片**：使用开源工具（如 `tile-dl`、QGIS）在联网环境预先下载目标区域的地图瓦片切片（通常下载到 zoom 3-18 级别）
+3. **替换前端渲染框架**：用 OpenLayers 或 Leaflet 替代高德 JSAPI，配置 `tileLayer` 指向内网的瓦片服务器
+
+```ts
+// Leaflet 离线示例
+import L from 'leaflet'
+
+const map = L.map('map').setView([39.9, 116.4], 13)
+
+L.tileLayer('http://内网IP:8080/tiles/{z}/{x}/{y}.png', {
+  maxZoom: 18,
+}).addTo(map)
+```
+
+**注意**：
+- 离线瓦片占用空间大（一个城市的 3-18 级瓦片约 10~50GB）
+- 需要定期更新瓦片（地图数据会变化——新道路、新建筑）
+- OpenLayers/Leaflet 只负责渲染，没有路线规划、地理编码等高级功能——这些需要额外搭建 OSRM、Nominatim 等开源服务
+
+---
+
+## 总结一句话
+
+> **自定义样式用高德地图平台生成 `style_id` + 9 种内置预设（如 `darkblue`）；离线部署高德官方不支持，内网场景需换 OpenLayers/Leaflet + 自建 GeoServer + 预下载瓦片，且高级功能（路线规划等）需自行搭建开源替代。**
+
+
+---
+## Q18：地图上有数百个 Marker 时，如何避免 Vue/React 响应式系统导致的性能问题？
+
+---
+
+## 题目
+
+地图上有数百个 Marker。点击一个 Marker 需要高亮它、弹出 InfoWindow 并同步更新左侧列表的选中状态。如果直接将地图相关数据绑定到框架的 State/Ref 中，往往引发高频重绘导致卡顿。请回答：
+
+1. **为什么把地图实例或 Marker 放入响应式状态会卡？**
+2. **InfoWindow 应该如何管理才能避免频繁创建销毁？**
+3. **Marker 事件 → 框架状态 → UI 更新的"双向桥"如何设计？**
+
+> 注：Q2 已详细说明 `shallowRef` vs `ref`，本题侧重**交互层**的状态流设计。
+
+---
+
+## 参考答案
+
+### 1. 地图对象与响应式的冲突
+
+Vue 的 `ref()` / `reactive()` 和 React 的 `useState()` 都会对存入的数据做深度代理/追踪。当地图实例（`AMap.Map` 是一个包含数百个属性、WebGL 上下文、事件循环的巨型对象）被放入响应式系统：
+
+| 后果 | 说明 |
+|------|------|
+| **初始化阻塞** | Vue 的 `ref()` 递归代理整个 Map 对象树（数百个嵌套属性），主线程卡顿 100~500ms |
+| **运行时抖动** | 地图内部的动画帧（每秒 60 帧）持续修改内部属性，触发 Proxy setter → 框架每帧都尝试重新渲染 |
+| **`this` 指向错乱** | 部分 AMap 方法内部依赖 `this` 指向原始对象，Proxy 包装后 `this` 指向 Proxy，导致方法调用失败或异常 |
+
+**解决方案**（Q2 已展开）：`mapInstance` 用 `shallowRef`，`Marker` 数组用普通 JS 变量或 `shallowRef`，不让响应式系统深度干预第三方对象。
+
+```ts
+const mapInstance = shallowRef<AMap.Map | null>(null)  // ✅ 只追踪整体替换
+const markers: AMap.Marker[] = []                       // ✅ 普通数组，不响应式
+const selectedMarkerId = ref<string | null>(null)       // ✅ 只追踪选中 ID
+```
+
+### 2. InfoWindow 复用策略
+
+**核心思想**：InfoWindow 只有一个实例，点击不同 Marker 时只改内容和位置，不销毁重建。
+
+```ts
+// ❌ 错误：每次点击都创建新的 InfoWindow
+function onMarkerClick(marker, data) {
+  new AMap.InfoWindow({ content: buildInfoHtml(data) })
+    .open(map, marker.getPosition())
+  // 上一个 InfoWindow 没销毁 → 地图上越堆越多
+}
+
+// ✅ 正确：复用同一个 InfoWindow
+let sharedInfoWindow: AMap.InfoWindow | null = null
+
+function onMarkerClick(marker, data) {
+  if (!sharedInfoWindow) {
+    sharedInfoWindow = new AMap.InfoWindow({ offset: new AMap.Pixel(0, -30) })
+  }
+  sharedInfoWindow.setContent(buildInfoHtml(data))
+  sharedInfoWindow.open(map, marker.getPosition())
+}
+```
+
+**复用的好处**：
+- 避免 DOM 创建/销毁开销
+- InfoWindow 内部的 DOM 事件监听器不会泄漏
+- 视觉上更流畅（同一个气泡移动 vs 旧消失新出现）
+
+### 3. 事件 → 状态 → UI 的三层桥接
+
+```
+高德 Marker 点击事件（原生 DOM 事件）
+    │
+    ▼
+更新 light-weight 响应式状态（只存 ID 或数据索引）
+    │  selectedMarkerId.value = data.id
+    │
+    ▼
+框架自动更新 UI
+    ├─ 左侧列表高亮选中项
+    ├─ 右侧详情面板刷新数据
+    └─ 地图上更新 Marker 外观（高亮/缩小）
+```
+
+**关键原则**：**单向数据流桥接**。Marker 点击 → 只改一个 `selectedId`。高亮逻辑由"该 Marker 的 id 是否等于 selectedId"计算得出，而不是在点击事件里操作 DOM。
+
+```ts
+// 点击事件
+marker.on('click', (e) => {
+  selectedId.value = markerData.id            // 只改一个轻量状态
+  updateInfoWindow(markerData)                 // 复用 InfoWindow
+})
+
+// 高亮逻辑：在 computed 或 watch 中处理
+watch(selectedId, (newId, oldId) => {
+  // 取消旧高亮
+  if (oldId) markerMap.get(oldId)?.setContent(buildNormalContent(oldId))
+  // 设置新高亮
+  if (newId) markerMap.get(newId)?.setContent(buildHighlightContent(newId))
+})
+```
+
+**为什么不直接在 click 事件里改 Marker DOM？** 如果有多处 UI（列表、详情面板、地图 Marker）需要响应这次点击，直接在 DOM 里分散操作会导致状态不一致——Marker 高亮了但列表没选中，或反过来。通过一个响应式 `selectedId` 作为唯一真相源，所有 UI 层都从它派生。
+
+### 4. 事件委托优化
+
+如果有 500 个 Marker，每个绑定独立 click 事件 = 500 个事件监听器 = 内存浪费：
+
+```ts
+// ❌ 500 个监听器
+markers.forEach(m => m.on('click', handler))
+
+// ✅ 一个监听器（如果用的是 MassMarks）
+massMarks.on('click', (e) => {
+  const data = e.data           // 通过 data 字段区分点击的是哪个点
+  selectedId.value = data.id
+})
+```
+
+对于普通 Marker，高德没有原生的事件委托机制。但可以通过**在地图层面监听 click 事件 + 手动判断**来模拟（不推荐，实现复杂且精度差）。务实做法：普通 Marker 在 500 个以内各自绑定事件是可接受的；超过 500 个应切换到 MassMarks + 统一事件。
+
+---
+
+## 总结一句话
+
+> **地图对象不入响应式（`shallowRef` + 普通变量）→ InfoWindow 只创一次、复用 `setContent` + `open` → 交互走单向数据流桥：Marker 事件只改 `selectedId`，所有 UI 层（列表、面板、地图高亮）从该状态派生，避免多源状态不一致。**
+
+
+---
+## Q19：H5 移动端定位失败怎么排查和兜底？
+
+---
+
+## 题目
+
+在 H5 移动端网页中使用高德 `AMap.Geolocation` 插件，经常出现定位失败，提示"Get geolocation time out"或"Permission denied"。请回答：
+
+1. **从哪些维度去排查定位失败的原因？**
+2. **有哪些兜底策略可以保证用户体验不中断？**
+3. **如果 H5 嵌套在 App/小程序中，如何利用原生定位能力？**
+
+---
+
+## 参考答案
+
+### 1. 失败原因排查清单
+
+按排查优先级排列：
+
+| 优先级 | 原因 | 现象 | 解决 |
+|--------|------|------|------|
+| **P0** | HTTP 协议 | 浏览器直接拒绝 Geolocation API 调用 | 部署到 **HTTPS**（iOS 10+ / Android 7+ 强制要求） |
+| **P0** | 用户拒绝权限 | `Permission denied` | 引导用户去系统设置中开启定位权限（无法代码绕过） |
+| **P1** | 微信/浏览器内核限制 | 微信内置浏览器、UC 浏览器等可能拦截 Geolocation | 引导用户用系统自带浏览器打开，或走 JSBridge |
+| **P1** | 室内 / 地下室 | GPS 信号无法穿透建筑 | 降级到 IP 定位或 WiFi 定位 |
+| **P2** | `AMap.Geolocation` 插件未加载 | `AMap.Geolocation is not a constructor` | 确保 `AMAP_PLUGINS` 中包含 `'AMap.Geolocation'` |
+| **P2** | 安全密钥配置错误 | `INVALID_USER_SCODE` | `_AMapSecurityConfig` 必须在 JSAPI 加载前设置（见 Q1） |
+| **P3** | HTTPS 证书问题 | 自签名/过期证书也可能被浏览器拒绝定位 | 使用正规 CA 签发的证书 |
+
+**为什么 HTTP 必失败？** Chrome 从 50 版本、Safari 从 iOS 10 开始，`navigator.geolocation.getCurrentPosition()` 只能在"安全上下文"（HTTPS 或 localhost）下调用。这是浏览器层面的强制限制，与高德无关。
+
+### 2. 兜底策略：多层降级
+
+```
+① 尝试 GPS 高精度定位
+    ├─ 成功 → 使用精确定位结果
+    └─ 失败 ↓
+
+② 降级到 IP 定位（AMap.CitySearch）
+    ├─ 成功 → 定位到城市/区级（精度数公里）
+    └─ 失败 ↓
+
+③ 降级到默认中心点
+    └─ 显示地图默认位置（如天安门/上海外滩），用户手动搜索
+```
+
+```ts
+async function locate() {
+  try {
+    // 第 ① 层：GPS 高精度定位
+    const position = await getGpsPosition()
+    return { lng: position.lng, lat: position.lat, precision: 'gps' }
+  } catch (err) {
+    console.warn('GPS 定位失败:', err.message)
+    try {
+      // 第 ② 层：IP 城市定位
+      const city = await getCityByIP()
+      const center = await getCityCenter(city)  // 地理编码获取城市中心坐标
+      return { lng: center.lng, lat: center.lat, precision: 'city' }
+    } catch (err2) {
+      // 第 ③ 层：默认位置
+      console.warn('IP 定位也失败:', err2.message)
+      return { lng: 116.397, lat: 39.908, precision: 'default' }
+    }
+  }
+}
+```
+
+**`AMap.Geolocation` 与 `AMap.CitySearch` 的区别**：
+
+| 方法 | 原理 | 精度 | 耗时 | 依赖 |
+|------|------|------|------|------|
+| `AMap.Geolocation` | 浏览器原生 `navigator.geolocation`（GPS/WiFi/基站） | 5~50 米 | 3~15 秒 | HTTPS + 用户授权 |
+| `AMap.CitySearch` | IP 地址解析 | 数公里（城市/区级） | < 1 秒 | 无（纯网络请求） |
+
+### 3. App/小程序环境的原生桥接
+
+如果 H5 嵌套在自研 App 或微信小程序中，应**放弃浏览器定位，改用原生能力**：
+
+#### 微信小程序 WebView
+
+```ts
+// 小程序侧 → 调 wx.getLocation → 通过 URL 参数或 postMessage 传给 H5
+wx.getLocation({
+  type: 'gcj02',         // 返回 GCJ-02 坐标，高德直接可用
+  success: (res) => {
+    // 通过 JSSDK 或 URL 参数将经纬度注入 H5
+    webView.postMessage({ lng: res.longitude, lat: res.latitude })
+  }
+})
+```
+
+#### 自研 App WebView（JSBridge）
+
+```ts
+// H5 侧调用 JSBridge
+const pos = await window.NativeBridge.call('getCurrentPosition')
+// Native 侧：Android → LocationManager, iOS → CLLocationManager
+// Native 拿到 WGS-84 坐标后，在传回 H5 前转为 GCJ-02（或由 H5 侧转）
+```
+
+**为什么原生定位比浏览器定位更可靠？**
+- 原生 API 不受浏览器 HTTPS 限制
+- 系统级定位权限弹窗的信任度更高，用户更可能通过
+- 可以控制超时时间、精度模式等参数
+- 可以结合基站/WiFi 辅助定位（A-GPS），室内场景可用性更好
+
+### 4. 用户体验细节
+
+| 场景 | 做法 |
+|------|------|
+| 定位中 | 显示加载动画 + "正在获取位置..." + 超时 15 秒自动降级 |
+| 定位失败 | Toast 提示原因 + 提供"手动选择城市"入口 |
+| 精度低（IP 定位） | 在地图角落标注"📍 粗略定位"，让用户知道可能不准 |
+| 用户拒绝授权后再次尝试 | 弹窗引导 → 不会自动弹系统权限框（浏览器不允许），需引导用户手动进入系统设置 |
+
+---
+
+## 总结一句话
+
+> **定位失败先查 HTTPS + 权限 → 三层降级：GPS → IP 城市定位 → 默认中心点 → App/小程序环境走 JSBridge 原生定位（可靠度最高）。关键是每一层都有 fallback，保证用户体验不因定位失败而中断。**