车机 WebView 兼容性差，需实测 HTML5 API 并降级；原生通信须用厂商 SDK 统一入口并加超时；资源加载受限于沙箱路径；需适配硬重启/休眠唤醒生命周期。
车机 WebView 内核老旧，HTML5 API 兼容性必须手动验证
多数车机系统用的是定制化 WebView（如基于 Android 4.4 的 Chromium 30，或某厂商魔改内核），WebGL、Web Audio API、IntersectionObserver 等现代 API 很可能未实现或存在严重 bug。不能依赖 navigator.userAgent 判断，得实测。
- 用
try...catch包裹关键 API 调用，比如new AudioContext()或canvas.getContext('webgl')，失败后降级到Audio标签或 2D 渲染 - 避免使用
Promise、async/await—— 某些车机 JS 引擎连Array.prototype.includes都不支持，优先用es5-sham+ 手动 polyfill，但注意体积限制（车机内存常低于 512MB） - 检查
localStorage是否可用且持久：有些车机在熄火后清空，或仅支持极小容量（QUOTA_EXCEEDED_ERR常见），建议用indexedDB降级方案时也加 try/catch
JS 插件与车机原生能力通信必须走约定通道
车机系统不允许直接调用 window.Android 或 window.webkit.messageHandlers 这类标准桥接对象 —— 厂商 SDK 通常封装了统一入口，比如 window.CarSDK 或 window.HUAPI，且方法名、参数格式、回调时机都非标准。
- 插件初始化前先判断
typeof window.CarSDK !== 'undefined'，再查CarSDK.version，不同版本接口差异大（如 v1.2 支持CarSDK.getVehicleData()，v2.0 改为CarSDK.vehicle.getData()） - 所有调用必须带超时控制：
setTimeout包裹原生调用，防止 JS 线程卡死（车机无 watchdog 机制，卡住即黑屏） - 避免在
onload或DOMContentLoaded中立即调用原生接口 —— 车机 SDK 加载慢，建议监听CarSDK.ready自定义事件，或轮询CarSDK.isReady()
资源加载失败不是网络问题，而是车机沙箱路径限制
车机 WebView 常禁用远程资源加载（http://）、限制本地文件协议（file:// 路径白名单）、或强制要求资源带完整 MIME 类型 —— 导致 fetch、XMLHttpRequest、甚至 静默失败。
- 静态资源一律打包进 APK 或车机固件的指定目录（如
/system/usr/webapp/xxx/），通过file:///system/usr/webapp/app/main.js加载，不要用相对路径 -
fetch请求头必须显式设置headers: {'X-Requested-With': 'XMLHttpRequest'}，部分车机拦截无该 header 的请求 - JS 插件里避免动态拼接
src，如document.createElement('script').src = url + '?t=' + Date.now()—— 车机 URL 解析器对 query 参数敏感，易触发 404
插件生命周期要适配车机“硬重启”和“休眠唤醒”场景
车机没有标准页面卸载流程：熄火即断电、锁屏即休眠、App 可能被系统强杀 —— beforeunload、visibilitychange 基本不可靠，需用更底层信号。
立即学习“前端免费学习笔记（深入）”；
- 监听车机广播事件：如
document.addEventListener('carpoweroff', handler)或document.addEventListener('huwakeup', handler)（具体事件名查对应 SDK 文档） - 状态缓存不能只靠内存变量，关键数据写入
localStorage后立即调用localStorage.setItem('x', y)并检查返回值（某些车机同步写入失败不报错） - 插件启动时先清理旧定时器：
clearInterval(window.__car_plugin_timer)，避免休眠唤醒后多个实例叠加执行
addEventListener('click') 在某些型号上可能因触控驱动上报延迟而漏触发 —— 最稳妥的方式是结合 touchstart + setTimeout 模拟 click，同时保留 fallback。细节多，但每处都绕不开。 
