chrome sensors emulator不支持地理位置模拟，需用devtools位置覆盖功能注入经纬度，并结合performance面板分析、web workers卸载计算、mock测试来评估异步逻辑性能。
Chrome Sensors Emulator 本身不提供地理位置模拟功能。它专用于模拟加速度计、陀螺仪、环境光、磁力计等硬件传感器数据，无法伪造或切换 GPS 坐标、经纬度、海拔、精度、时间戳等原始地理位置信息。
如果你的目标是“测试异步业务逻辑在不同地理位置下的性能表现”，关键不在传感器模拟器，而在于如何可控地注入不同地理上下文，并观察其对 JS 异步任务（如 API 调用、地图渲染、本地化计算、缓存策略等）的影响。以下是实际可行的路径：
一、用 Chrome DevTools 的位置覆盖功能注入地理位置
这是最直接、标准且无需扩展的方式：
- 打开 DevTools（F12）→ Settings（齿轮图标） → Preferences → 展开 Sensors → 勾选 Override device location
- 输入任意经纬度（例如
35.6895,139.6917东京；48.8566,2.3522巴黎） - 刷新页面后，
navigator.geolocation.getCurrentPosition()和watchPosition()返回的坐标即为你设定的值 - ✅ 优势：真实触发浏览器地理位置 API，所有依赖它的异步逻辑（如基于位置的 fetch、地图 SDK 初始化、区域限流判断）都会按预期执行
- ⚠️ 注意：需确保页面已获用户地理位置授权（可手动点击地址栏锁形图标 → Site settings → Location → 设为 Allow）
二、配合 Performance 面板量化异步逻辑响应差异
地理位置变更常引发以下异步行为，可用原生工具测量：
- 地图 SDK 加载瓦片的网络延迟（查看 Network 面板中
/tiles/请求的 TTFB 和资源大小） - 本地化格式化函数（如
Intl.DateTimeFormat、Intl.NumberFormat）的执行耗时（用console.time('format')或 Performance API 标记） - 基于区域的 API 路由（如调用就近 CDN 或不同后端集群）导致的 fetch 延迟波动
- 在 Performance 面板中录制操作，筛选
PromiseResolve、XHR、FunctionCall等事件，对比不同坐标下关键异步任务的耗时分布
三、用 Web Workers 隔离地理敏感计算，避免主线程阻塞
若地理位置触发的逻辑含大量同步计算（如地理围栏多边形点判断、距离矩阵预处理），应将其移入 Worker：
// main.js
const worker = new Worker('geo-processor.js');
worker.postMessage({ lat: 40.7128, lng: -74.0060, points: largePointArray });
worker.onmessage = ({ data }) => {
console.log('Geo calc done in', data.duration + 'ms');
};
这样即使坐标频繁变化、计算量大，也不会拖慢动画帧率（
四、构建可复现的地理测试场景（非实时模拟）
对稳定性要求高的性能测试，建议绕过实时定位，改用预设坐标集 + mock：
- 使用
jest或vitest模拟navigator.geolocation，返回固定坐标序列 - 在测试中批量触发
getCurrentPosition()，测量每次回调中异步链路（fetch → parse → render）的总耗时 - 示例 mock：
Object.defineProperty(navigator, 'geolocation', { value: { getCurrentPosition: jest.fn((success) => success({ coords: { latitude: 51.5074, longitude: -0.1278 } }) ) } });
地理位置本身不直接消耗 CPU，但它常作为触发条件，激活后续异步任务链。真正影响性能的是这些任务在网络、解析、渲染、计算各环节的执行效率。用好 DevTools 位置覆盖 + Performance 分析 + Worker 卸载 + 测试 Mock，比寻找不存在的“地理传感器模拟器”更有效。
