:invalid对type="email"不实时生效，因浏览器仅在提交或失焦时校验；需加required属性、结合:user-invalid和JS手动控制服务端错误态，形成完整验证链。
为什么:invalid对type="email"没反应？
因为浏览器只在表单提交（或元素失去焦点）后才触发:invalid校验，不是实时监听输入。如果你边输边等红框，那肯定看不到——它不主动验证，只响应「校验时机」。
常见误操作：input[type="email"]:invalid { border: 2px solid red; }写对了，但没加required属性，或者用户根本没点提交/移出焦点，样式就一直不生效。
- 必须加上
required，否则空值不算invalid -
type="email"本身只做基础格式检查（如含@、域名部分非空），不会发请求验证邮箱真实存在 - Chrome/Firefox 支持
:invalid，但 Safari 在未交互前可能不应用样式（需:user-invalid兜底）
怎么让提示更及时又不干扰输入？
纯:invalid太被动，可以配合:user-invalid（Safari支持，且在用户编辑后即触发）和:placeholder-shown区分「空」和「错」状态。
input[type="email"] {
border: 1px solid #ccc;
}
input[type="email"]:placeholder-shown {
border-color: #ccc;
}
input[type="email"]:user-invalid:not(:placeholder-shown),
input[type="email"]:invalid:not(:placeholder-shown) {
border-color: #d32f2f;
}
input[type="email"]:user-invalid:not(:placeholder-shown) + .error,
input[type="email"]:invalid:not(:placeholder-shown) + .error {
opacity: 1;
}
关键点：
-
:not(:placeholder-shown)排除空值干扰，避免一进页面就报错 -
.error用opacity: 0初始隐藏，靠兄弟选择器联动显示 - 不要用
:focus:invalid——聚焦时输入未完成，容易误标
后端校验和前端:invalid冲突怎么办？
如果后端返回邮箱已被注册，而:invalid此时仍为false（格式正确），视觉反馈就断层了。这时不能依赖伪类，得用JS手动加类。
典型做法是：提交失败后，给输入框添加data-server-invalid="true"，再用CSS匹配：
input[data-server-invalid="true"] {
border-color: #d32f2f;
}
input[data-server-invalid="true"] + .error {
opacity: 1;
content: "该邮箱已被注册";
}
- 别覆盖
:invalid样式，而是叠加——格式错 + 服务端错，都走同一套视觉逻辑 - 清空输入后记得同时移除
data-server-invalid，否则残留错误态 -
:invalid无法表达业务语义（如“邮箱已存在”），这部分必须由JS接管
移动端键盘和:invalid的兼容细节
iOS Safari 的 email 键盘会自动补全@和域名（如@gmail.com），但用户删掉后可能留下孤立@，此时:invalid才触发——这个时机比预期晚，体验割裂。
- 可在
input监听input事件，用正则/^[^\s@]+@[^\s@]+\.[^\s@]+$/提前标记，避免等伪类 - Android Chrome 对
:user-invalid支持不稳定，建议始终用:invalid+ JS fallback双保险 - 别依赖
checkValidity()在onchange里调用——移动端change触发太晚，改用input事件
实际项目里，:invalid只是起点，真正可靠的提示链是：基础格式（伪类）→ 用户交互反馈（JS增强）→ 服务端结果（数据驱动）。漏掉任意一环，用户都会在「我以为填对了」和「你告诉我错了」之间卡住。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
