不可行，因破坏可访问性、键盘操作和浏览器原生行为：屏幕阅读器不识别语义、Enter/Space无响应、表单验证失效、移动端交互丢失。
div 模拟按钮/输入框会导致什么具体问题
不可行——不是技术上做不到，而是会直接破坏可访问性、键盘操作和浏览器原生行为。比如用 div 加 onclick 模拟按钮，屏幕阅读器不会宣布它是“按钮”，Enter 或 Space 键按下去没反应，tabindex 手动加了也绕不过焦点管理混乱和语义缺失。
常见错误现象包括：
• 屏幕阅读器读作“静态文本”而非“可点击按钮”
• 键盘用户无法用 Tab 进入、Enter 触发
• 浏览器内置表单验证（如 required）完全失效
• 移动端双击放大、长按菜单等默认交互丢失
ARIA role="button" 能不能补救语义缺陷
能补一部分，但只是“贴标签”，不是“改本质”。role="button" 会让屏幕阅读器读出来，但不会自动绑定 Enter/Space 响应，也不会参与表单提交、禁用状态（disabled）样式继承或焦点顺序自动管理。
实操建议：
• 必须手动监听 keydown 并判断 event.key === 'Enter' || event.key === ' '
• 必须用 aria-disabled="true" + 自定义 CSS 控制视觉禁用态（原生 button[disabled] 会自动灰掉并阻止事件）
• role 不能滥用：比如给一个带 href 的 div 加 role="link"，不如直接用 a 标签
哪些场景下必须用原生元素，绕不开
表单控件类交互基本没有妥协余地。原生 input[type="checkbox"]、select、textarea 不仅提供语义，还自带状态同步（checked、value、selectedOptions）、事件粒度（input vs change）、移动端软键盘触发逻辑。
典型不可替代点：
• input[type="date"] 在 iOS 上唤起日期滚轮，div + ARIA 完全无法模拟
• select 的键盘导航（上下键切换选项、字母跳转）是浏览器级实现
• 表单内 submit 按钮的回车提交行为，依赖原生 form 关系链
真需要高度定制外观时怎么平衡
用原生元素 + CSS 重置，而不是抛弃原生。现代 CSS 已经能深度控制几乎所有渲染细节，比如：
button {
appearance: none;
background: transparent;
border: none;
padding: 0;
font: inherit;
color: inherit;
}
button:focus { outline: 2px solid #007aff; }
关键原则：
• 优先用 button、input、label 等原生标签
• 用 appearance: none 和自定义伪类（::-webkit-inner-spin-button 等）抹除默认样式
• 保留所有原生状态（:disabled、:focus-visible、:checked）的样式响应
• 不用 ARIA 模拟状态，直接用原生布尔属性（checked、aria-checked 是冗余且易不同步的）
最常被忽略的是 focus 样式和键盘焦点可见性——很多团队只测鼠标点击，忘了键盘用户根本看不到当前焦点在哪。这比视觉还原度更影响实际可用性。
