HTML不是页面交互的基石，交互基石是JavaScript；HTML唯一职责是提供可被JS操作的结构基础，通过语义化标签（如button、form）和关键属性（name、id、tabindex）为事件监听、数据提交与无障碍访问铺路。
HTML 不是页面交互的基石——它压根不处理交互。
交互的基石是 JavaScript，而 HTML 的唯一职责是提供可被 JavaScript 操作的结构基础。你点不到、选不了、传不了数据的元素，再漂亮的交互逻辑也无从下手。
为什么 HTML 必须先“可交互”？
- 浏览器只对特定标签或带特定属性的元素触发原生事件（如
click、input、submit） -
form、button、input、select、textarea这些标签天生携带语义和行为边界，JavaScript 才能可靠地监听和干预 - 普通
div或span默认不响应click（除非加tabindex或 CSScursor: pointer），更不会在表单提交时自动收集值
常见错误现象：
- 绑定了
onclick却没反应 → 元素没聚焦能力或被pointer-events: none拦截 - 表单提交后拿不到
input值 →input缺少name属性，后端收不到字段 - 使用
label但点击无效 → 没用for关联id，或没把input包在label内
使用场景中必须检查的三项：
立即学习“前端免费学习笔记（深入）”；
-
form标签是否包裹了全部相关控件，并设置了action和method - 所有用户可操作的控件是否具备明确的
name（用于数据提交）和id（用于 JS 查询或label关联） - 是否用语义化标签替代“伪按钮”：比如用
button而不是div onclick="..."，避免键盘不可访问、屏幕阅读器无法识别
HTML 如何为交互铺路：三个不可省的属性
name、id、tabindex 是最常被忽略却最关键的三个属性：
-
name：表单控件的“字段名”，决定提交时键名（如user[email]），没有它，后端收不到这个字段 -
id：DOM 查询唯一依据，也是label、aria-labelledby、<fieldset></fieldset>等无障碍关联的基础 -
tabindex：控制元素能否被键盘聚焦。值为0表示按 DOM 顺序参与 tab 导航；负值（如-1）表示可脚本聚焦但不进 tab 链
性能与兼容性影响：
- 过度使用
tabindex="0"在大量列表项上会拖慢键盘导航体验 -
id重复会导致document.getElementById()返回首个匹配项，JS 行为不可预测 -
name在input[type=radio]中决定分组关系，同名即互斥，改错一个就全乱
常见“假交互”陷阱：你以为在交互，其实只是视觉欺骗
很多初学者用 div + CSS + 内联 onclick 模拟按钮，这带来三类硬伤：
- 键盘用户无法触发（
Enter/Space不生效） - 屏幕阅读器读不出“这是一个按钮”，只读成“一段文字”
- 移动端 300ms 点击延迟未消除（
button默认已优化）
正确做法始终优先：
- 按钮行为 → 用
button，禁用时设disabled，别用pointer-events: none - 链接跳转 → 用
a，哪怕只是href="#"，再用event.preventDefault()控制逻辑 - 表单提交 → 用
form+button[type=submit]，而不是div监听click后手动fetch
简短示例对比：
错误写法（不可访问、不可提交、难维护）：
<div onclick="doLogin()">登录</div>
正确写法（语义清晰、天然支持所有交互通道）：
<button type="button" onclick="doLogin()">登录</button>
复杂点往往藏在“默认行为”里：比如 button 在 form 内默认是 type="submit"，不显式声明就会触发表单提交；又比如 label 包裹 input 时，for 属性反而多余。这些细节不翻规范、不实测，很容易在线上环境突然失效。
