dialog元素需调用showModal()才激活模态行为，自动禁用背景、锁定焦点、响应Esc；open属性仅控制初始状态，不能替代JS方法；点击遮罩关闭须手动监听click事件并判断e.target === dialog。
直接用原生 HTML 标签就能替代大量 JS 逻辑，而且性能更好、维护更轻——这不是理想状态，是现在就能落地的事实。关键在于选对标签、用对属性、避开浏览器解析陷阱。
dialog 元素代替 JS 模态框：为什么 show() 比 jQuery.show() 快 6 倍
旧方案依赖 jQuery.modal() 或自定义 Modal 类，要手动管理遮罩层、焦点捕获、返回值传递、ESC 关闭逻辑；dialog 原生支持这些，且不触发重排。
-
dialog.showModal()自动禁用背景交互、聚焦第一个可聚焦元素、拦截 Tab 键循环 - 关闭后触发
close事件，dialog.returnValue直接拿到按钮的value - 不兼容 IE 和 Safari 15.6 之前版本，需加
if ('showModal' in HTMLDialogElement.prototype)判断 - 不要用
display: none隐藏dialog，该元素默认不渲染，用open属性控制显隐
loading="lazy" 图片与 iframe 懒加载：不是所有场景都适用
loading="lazy" 是浏览器原生懒加载，比 IntersectionObserver + JS 实现更轻量，但有明确边界。
- 仅对
<img alt="HTML标签原生组件应用与页面性能优化" >和<iframe></iframe>生效，<picture></picture>内的<source></source>不支持 -
loading="eager"强制立即加载，适合首屏大图或关键 banner - 在低网速下，
loading="lazy"可能导致图片“跳入”，建议搭配height+width或aspect-ratio预留空间 - Chrome 77+ 支持，Firefox 75+，Safari 15.4+；不支持时会退化为正常加载，无报错
语义化标签影响渲染树构建：main/nav/header 不只是写给程序员看的
浏览器在解析 HTML 时，会根据标签语义提前优化资源调度和布局计算顺序。<main></main> 被识别为主内容区后，其子节点的样式计算和 JavaScript 执行上下文初始化会被优先安排。
立即学习“前端免费学习笔记（深入）”；
-
<main></main>区域内的<script></script>更可能被浏览器标记为“非阻塞关键路径” -
<nav></nav>中的链接常被预加载器识别为高优先级跳转目标，可能触发prefetch - 避免用
<div role="main"> 伪装语义，ARIA 角色无法替代原生语义对渲染树的影响 <li>嵌套层级过深（如 <code><section><article><section><header></header></section></article></section>）反而增加解析开销，保持 2–3 层语义嵌套最稳 -
type="email"仅校验基础格式（a@b.c），不发请求验证邮箱真实性 -
minlength对type="number"无效，数字输入框应改用min和step - 复杂规则（如“密码需含大小写字母和数字”）仍需监听
input事件 +setCustomValidity() - 提交失败时，
form.reportValidity()可主动触发验证并返回布尔值，适合封装校验入口
表单验证不用 JS：required/minlength/pattern 的真实行为边界
原生验证省掉几百行 JS，但必须清楚它只在 submit 时触发，且错误提示不可定制样式（除 ::-webkit-validation-bubble 等私有伪类）。
真正卡住性能的往往不是某段 JS，而是 DOM 树里一堆没语义的 div、没约束的图片、没声明的模态逻辑——这些细节浏览器没法猜，只能保守处理。原生组件不是“功能够用就行”，而是让浏览器知道“你想干什么”。
