navigator.geolocation 是浏览器自动调度定位源的统一接口，开发者无法指定硬件传感器；其精度取决于HTTPS、授权状态、参数设置及物理环境。
HTML 本身不提供任何硬件传感器访问能力，navigator.geolocation 也不是“根据硬件传感器配置选择”的函数工具——它只是一个统一接口，背后由浏览器自动调度设备可用的定位源（GPS、Wi-Fi、基站、IP），开发者无法也不应手动指定用哪个传感器。
为什么不能指定用哪个硬件传感器
浏览器对底层定位硬件（如 GPS 芯片、IMU、Wi-Fi 扫描模块）没有开放细粒度控制权。调用 navigator.geolocation.getCurrentPosition() 后，系统会按优先级自动组合多种信号源：在户外手机上可能主要用 GPS，在室内笔记本上则依赖 Wi-Fi 热点数据库或 IP 地址库。这个过程完全黑盒，且受操作系统策略限制（例如 macOS 上 Safari 默认禁用高精度定位，Windows 上 Edge 可能绕过 GPS 直接查本地缓存）。
- 你传
{ enableHighAccuracy: true }，只是“请求”高精度，并不保证启用 GPS；设备没 GPS 或权限被拒时，浏览器仍会返回 Wi-Fi 定位结果 - 你无法判断当前坐标到底是来自 GPS 还是
sensors命令读出的 CPU 温度——这两者毫无关系，混在一起是典型概念错配 - 所谓“硬件传感器配置”，对
geolocationAPI 来说既不可见，也不可编程干预
真正影响定位结果的其实是运行环境和参数
决定你拿到什么精度、什么延迟、什么坐标的，不是 HTML 函数选型，而是以下四点：
- HTTPS 是否启用：HTTP 页面下 Chrome/Edge/Safari 会直接拒绝调用，连错误回调都不触发
-
用户是否已授权且未永久拒绝：一旦用户点“禁止”，后续所有
getCurrentPosition()都会进error.code === PERMISSION_DENIED，不会重弹窗 -
options 参数的实际取值：
timeout设太小（如 1000）会导致多数 Wi-Fi 定位失败；maximumAge设太大（如 3600000）会让页面反复用一小时前的坐标 - 设备所处物理环境：地下室、电梯、金属幕墙写字楼内，GPS 信号基本为 0，此时全靠 Wi-Fi 或基站估算，误差常达百米级
如果真要对接硬件传感器，得换技术栈
想读 CPU 温度、GPU 占用率、电池电压这类指标，navigator.geolocation 完全无用。必须脱离纯前端环境：
立即学习“前端免费学习笔记（深入）”；
- 用 Electron/Tauri 打包，通过 Rust/Go 调用
sysinfo或psutil获取温度列表，再暴露成 JS 命令供 HTML 调用 - 起一个本地 Node.js 服务，执行
sensors（Linux）、istats（macOS）、wmic /namespace:\rootwmi PATH MSAcpi_ThermalZoneTemperature get CurrentTemperature（Windows）并返回 JSON - 用 WebUSB 连接外置 I2C 温度探头（如 TMP117），但需设备固件支持 HID 协议，且仅限 Chrome/Edge
这些方案和地理位置获取在协议层、权限模型、错误类型上完全不同，强行塞进同一个“HTML 函数工具”分类里，只会导致调试时分不清是定位失败还是温度读取超时。
最常被忽略的一点：很多开发者在测试时用的是公司内网 Wi-Fi，而该 Wi-Fi 的 BSSID 未被 Google/Apple 的定位数据库收录，结果 accuracy 返回 2000 米——这不是代码问题，是地理数据库覆盖盲区。遇到这种情形，别改 JS，先换手机热点重试。
