车载系统中 无法输入字符，主因是老旧 WebKit 内核（如 Chromium 30）不支持合成事件与软键盘联动；应改用 type="text"+视觉遮盖、触摸驱动 focus()+select()、动态 autocomplete 值、非标准字段名，或 Canvas 虚拟键盘，并确保 HTTPS 提交与 TLS 时间校验。
车载系统里
多数车机 WebKit 内核老旧（如 Android 4.4 的 Chromium 30），不支持现代密码输入的合成事件或软键盘联动。用户点击输入框无反应、长按弹不出键盘、或者输入后 value 为空，基本都卡在这儿。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 优先检测车机实际 User-Agent，用
navigator.userAgent看是否含WebKit/537.36但版本号低于Chromium/60 - 避免依赖
input[type="password"]的默认行为，改用type="text"+ 视觉遮盖（如用•或自绘圆点） - 监听
input事件而非change，老内核对change触发时机极不可靠
软键盘唤起失败时怎么强制触发
车机浏览器常禁用 focus() 自动唤起键盘（尤其在非用户手势上下文），直接调 input.focus() 基本无效。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 确保聚焦操作由真实触摸事件驱动，例如在按钮
onclick里调input.focus()，而不是页面加载后 setTimeout 唤起 - 加一行
input.select()在focus()后，部分旧 WebKit 需要选中态才弹键盘 - 若仍失败，退而求其次：用
contenteditable="true"的模拟输入框，配合compositionstart/compositionend捕获中文输入autocomplete="off"在车机上根本不管用老版 WebKit 对
autocomplete属性解析异常，甚至会把off当成有效值并自动填充上次密码。更糟的是，某些车机系统会劫持所有type="password"输入框，硬塞自己的密码管理器逻辑。实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不用
autocomplete="off"，改用随机字符串如autocomplete="new-password-"，并在 JS 中动态写入时间戳或随机数 - 密码字段名别用
password或pwd，改用auth_token、pin_code等非标准名称，降低被识别概率 - 关键场景（如车锁认证）建议绕过 HTML 表单，用 Canvas 绘制虚拟键盘，完全控制输入流
明文传输风险比显示问题更致命
很多开发者只盯着“密码星号不显示”，却忽略车机环境里更大的雷：
XMLHttpRequest或fetch发送密码时未走 HTTPS，或证书校验被系统级代理劫持（常见于带远程诊断模块的车机）。实操建议：
立即学习“前端免费学习笔记（深入）”；
- 所有密码提交必须用
fetch(url, { method: 'POST', body: JSON.stringify({ token }) })，禁用 URL 拼接传参 - 检查车机系统时间是否严重偏差——旧设备 RTC 失效会导致 TLS 握手失败，表现为 fetch 报
TypeError: Failed to fetch且无具体错误 - 若需兼容 HTTP 调试环境，至少做前端哈希（如
sha256(pin + salt)），但注意：纯前端哈希不能替代服务端 bcrypt
车机适配不是单纯“让密码框看起来像密码框”，而是要在内核限制、输入链路断裂、网络不可信三重约束下，重新定义“输入”和“保密”的边界。最稳的方案往往是最不像标准方案的那个。
- 不用
