a标签用于跳转，button标签用于触发操作；mailto、tel、锚点等必须用a，button无法原生支持；button必须显式设type="button"防误提交；卡片跳转应整体用a包裹而非div onclick。
button 和 a 标签都能“看起来像按钮”，但语义和行为完全不同
直接结论：a 适合跳转，button 适合触发操作——别为了“长得像”就硬改标签，否则会踩语义、键盘、无障碍、移动端兼容性一连串坑。
常见错误是把 @#@#@#@#@#@#@#@#@#@0 当成万能按钮用，结果发现：空格键不能触发、屏幕阅读器读作“链接”、iOS WebView 拦截跳转、右键菜单弹出“在新标签页打开”这种无效选项。
真正该用哪个，只看一件事：用户点它之后，是不是立刻、无条件、纯前端跳转到另一个 URL（含 mailto:、tel:、锚点）？是 → 用 a；否 → 用 button。
mailto 或页面跳转必须用 a 标签，button 只能靠 JS 模拟且不稳
mailto: 链接依赖浏览器原生协议处理机制，button 没这个能力。写 <button href="mailto:admin@example.com"></button> 是无效 HTML，属性被忽略，点击没反应。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 正确做法：用
@#@#@#@#@#@#@#@#@#@1，再用 CSS 去掉下划线、加背景、圆角等，让它“像按钮” - 中文或特殊字符必须 URL 编码，比如
mailto:admin@example.com?subject=%E5%8F%8D%E9%A6%88，否则部分客户端收不到完整主题 - 若非要用
button（比如已有复杂 JS 流程），只能window.location.href = "mailto:..."，但 iOS 微信内置浏览器、某些 WebView 会静默拦截，不如原生a可靠 -
a必须保留title属性，例如title="发送邮件至 admin@example.com"，这对屏幕阅读器和 tooltip 提示都关键
button type="button" 是防止表单意外提交的底线配置
把 button 放进 <form></form> 里却不写 type，等于埋雷——默认是 type="submit"，一点就提交表单并刷新页面，根本不是你想要的“触发 JS”。
- 所有非表单提交用途的
button，必须显式声明type="button" - 别依赖
onclick="doSomething(); return false;"来阻止提交：return false 对 button 本身无效，它本来就不提交；真正起作用的是type属性 - 如果按钮要禁用，用
disabled属性（<button type="button" disabled>加载中</button>），比用 JS 控制 class + pointer-events 更可靠、更可访问 - 图标按钮务必包裹文字或加
aria-label，纯<i class="icon"></i>在高对比模式或语音导航下可能完全不可识别
卡片式交互区域该用哪个标签？别嵌套，也别用 div onclick
一个“用户头像+昵称+关注按钮”的卡片，点击整块区域要跳转到个人主页——这本质是导航，应该用 a 包裹整个卡片，而不是给卡片加 onclick 或在里面塞个 button。
-
@#@#@#@#@#@#@#@#@#@2是合法且语义正确的写法 - 避免
<div onclick="goToUser(123)">...</div>：无法聚焦、Enter/Space 键失效、屏幕阅读器无法识别为可交互元素 - 更别搞
<div> <a>头像</a><button>关注</button> </div>：焦点顺序混乱、键盘用户可能卡在中间、触摸热区重叠导致误点 - 触控设备要求最小热区 ≥44px × 44px，CSS 设置
padding或min-height/min-width比强行放大字体更稳妥
最易被忽略的点是：键盘焦点和屏幕阅读器对 a 和 button 的处理逻辑完全不同，这不是“样式像就行”的事——语义错了，后续所有交互、可访问性、SEO 行为都会偏移。写完先按 Tab 键走一遍流程，再用 VoiceOver 或 NVDA 听一遍朗读内容，比跑十遍视觉测试更有价值。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
