input[type="email"] 仅做基础格式校验，如含@和点号，不查域名真实性；需配合required和pattern增强限制，但无法替代后端验证；:valid/:invalid仅反映格式有效性，非邮箱真实可用性。
怎么用 input[type="email"] 做基础验证但不依赖 JS
纯 HTML 能做的邮箱验证，仅限格式检查（比如必须含 @ 和点号），浏览器不会发请求、不查域名是否存在，也不管邮箱是否真实可用。input[type="email"] 会自动触发表单原生校验，提交时失败会弹提示，但样式和提示文案不可控。
常见错误现象：value="user@domain" 被认为合法（缺后缀如 .com）；user@@domain.com 反而被拦住；IE10+ 才支持，旧版 IE 完全忽略该类型，退化成普通 text。
- 加
required属性才能触发必填校验 - 加
pattern可增强格式限制，例如pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$"，但注意：这会覆盖原生邮箱规则，且 Safari 对pattern的错误提示不显示 - 不要指望它防机器人或钓鱼邮箱——
test@test.test这种明显假地址也能过
如何用 :valid 和 :invalid CSS 伪类做状态标识
这是最轻量的“已验证/未验证”视觉反馈方式，不依赖 JS，靠浏览器实时计算表单控件有效性。
使用场景：在输入框右侧加小图标、改变边框颜色、显示“✓ 已验证”文字等。但要注意，这些状态只反映格式校验结果，不是服务器确认结果。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
:valid在值为空时也可能为真（除非加了required） -
:invalid在页面加载、尚未输入时就可能生效（因为初始值空且required），导致一上来就显红，体验差；建议配合:user-invalid（Chrome 102+、Firefox 119+ 支持）只在用户交互后才触发 - CSS 示例：
input:valid { border-color: #4CAF50; }<br>input:invalid:not(:placeholder-shown) { border-color: #f44336; }
为什么不能只靠前端验证来标记“已验证邮箱”
前端验证只能说明“看起来像邮箱”，和“邮箱真实存在”“用户能收邮件”“用户已点击验证链接”完全无关。把 :valid 状态当成“已验证”是典型误解。
容易踩的坑：input 值通过 JS 改成合法格式（比如补上 @example.com），CSS 就立刻变绿，但用户根本没发过验证邮件；或者后端返回“邮箱未激活”，前端却还显示 ✓ 图标。
- 真正“已验证”状态必须由后端返回，通常带字段如
is_email_verified: true - 前端应单独维护一个布尔变量（如
emailVerified），根据 API 响应设置，再决定 UI 样式 - 如果要做“发送验证邮件”按钮的禁用逻辑，判断依据应是
!emailVerified && input.value !== ""，而不是input.checkValidity()
服务端验证回传后，怎么安全更新前端状态标识
拿到后端返回的邮箱验证状态后，不能直接用字符串对比或模糊匹配来设 UI，得靠明确字段驱动。
参数差异：有些接口返回 status: "verified"，有些是 email_confirmed: 1，还有些放在嵌套对象里如 user.profile.email_status。硬编码字段名极易出错。
- 优先用布尔字段，如
is_email_verified，避免字符串比较（"true"vstruevs"verified"） - 更新 DOM 时，别只改颜色或图标，同步更新
aria-live区域，让读屏器可感知变化，例如：<div aria-live="polite" id="email-status"></div>
- 如果用户修改了邮箱输入框内容，应自动清除已验证状态（哪怕新值格式合法），因为验证的是旧邮箱，不是新输的这个
:valid 是格式有效，后端的 is_email_verified 是行为确认——两者永远不该混用。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
