data-*属性读不到或解析失败，因仅dom初始化时解析为字符串且不自动转类型；ssr不一致会触发框架diff抹除，json需转义+try/catch，constructor中读取会因未挂载返回undefined。
混合 App 中 data-* 属性为什么读不到或解析失败
因为 data-* 只在 DOM 初始化时被解析为字符串，且不自动转类型。你在客户端 JS 里写 document.body.dataset.apiBase 得到的是字符串 "https://api.example.com"，不是 URL 对象；写 dataset.timeout 是 "5000"，不是数字 5000。SSR 渲染的 HTML 若服务端和客户端初始值不一致，框架 diff 还可能把属性当“脏值”抹掉。
常见错误现象：
- 配置含
&或双引号未 HTML 转义，导致解析截断（如data-config='{"url":"a&b"}'实际只读到{"url":"a） - 直接
JSON.parse(el.dataset.config).timeout报错，因没包try/catch - 在自定义元素
constructor()里就读this.dataset.id，此时 DOM 还没挂载，值为undefined
实操建议：
- 只用于初始化传参，挂载在
或上，例如 - 结构化数据必须先
JSON.stringify()再写入，JS 端用JSON.parse(el.getAttribute('data-config') || '{}')+try/catch - 服务端模板（如 EJS、Jinja2）输出时，对 JSON 值做 HTML 实体转义：
data-config="${escapeHtml(JSON.stringify(cfg))}"
inputmode 在混合 App 里为何总唤不起正确键盘
inputmode 是提示，不是指令。iOS Safari 直到 16.4+ 才较完整支持 inputmode="decimal"，旧版 Android WebView（尤其 Cordova 封装）基本忽略它；写了 inputmode="numeric" 却弹出全键盘，不是你写错了，是底层 WebKit/Chromium 没走标准路径。
关键差异：
- 身份证号末位可能是
X，inputmode="numeric"在多数 WebView 中无法唤出含 X 的键盘，用户得手动切，体验断裂 -
inputmode="decimal"在金融输入中常失效——它依赖系统输入法原生支持小数点布局，而混合 App 的 WebView 往往复用系统默认输入法 -
inputmode="none"不是优化延迟的解法，只是跳过键盘初始化流程，代价是用户无法自动唤起
实操建议：
- 身份证号用
inputmode="text"+pattern="[0-9Xx]{18}"+ JS 实时过滤，比依赖键盘更稳 - 金额类字段优先
inputmode="numeric"+step="0.01"+min="0"，再监听keydown拦截非数字、非小数点、非负号键（注意中文输入法下event.key === "Process"） - Android WebView 需确保
targetSdkVersion ≥ 30且使用 Chrome WebView 内核；iOS 低版本 fallback 到type="tel"（但会带拨号符号）
跨窗口拖拽时 dataTransfer.getData() 为什么经常为空或乱码
因为 dataTransfer.getData("text/plain") 不是可靠通道：它会丢换行、转义双引号、编码不可控；Safari 16.6 之前根本不认 "application/json"；Firefox 跨窗口时甚至返回空字符串——这是规范允许的安全限制，不是 bug。
真正的问题不在 draggable 属性本身，而在 setData() 类型选错或没降级。
实操建议：
- 必须双格式写入：
e.dataTransfer.setData("application/json", jsonStr)和e.dataTransfer.setData("text/plain", jsonStr) - 读取时优先
getData("application/json")，失败立刻fallback到getData("text/plain")再JSON.parse() - 禁止在
dragstart里异步读e.target.dataset.payload—— 源窗口可能已失焦，DOM 不稳定 - 推荐提前固化 payload：
el._dragPayload = {id: 123, type: "card"}或用data-payload='{"id":123}'预存
为什么不能靠 inputmode 解决软键盘弹出延迟
inputmode 完全不控制弹出时机。延迟卡在原生层与 JS 层通信链路或渲染阻塞上：Android WebView 默认等 onPageFinished() 后才允许 focus()，iOS WKWebView 需等 WebKit layout commit 完成，鸿蒙 ArkUI 的 Web 组件还有双缓冲跨线程同步延迟。
uni-app 的 <web-view></web-view> 甚至没透传原生键盘事件，JS 层只能轮询 window.innerHeight 变化，天然滞后。
实操建议：
- 放弃靠
inputmode或纯 HTML 解决延迟，转向混合层协同 - Android：抓 Logcat 的
InputMethodManager日志；iOS：看UIKeyboardWillShowNotification时间戳，比反复改inputmode有效得多 - uni-app 加
style="height: calc(100vh - var(--safe-area-inset-bottom, 0px))"，避免键盘弹起时 Webview 自身重绘卡顿 - 所有延迟问题最终都落在“焦点请求是否被原生层接收并转发”上，而不是 HTML 层有没有写对
inputmode
复杂点在于：每个属性看似简单，但混合 App 的 WebView 环境把它们拆解成了三段——HTML 层、JS 层、原生层。你改了 data-api-base，不等于客户端能立刻读到；你设了 inputmode="decimal"，不等于键盘真会弹出小数点。真正起效的，永远是那一小段桥接逻辑，而不是属性本身。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
