type="email"等html属性仅作前端格式提示，无法防御篡改；真正安全防线是后端用标准库（如python email-validator）复核校验，且必须与前端规则完全一致。
type="email"这类HTML属性根本不是安全防线
它只做格式提示，不防篡改。浏览器看到 type="email"，只是在提交时检查值里有没有 @ 符号和点，连域名是否存在都不验证；用户用开发者工具删掉 required、或者直接 fetch() 发请求，校验就彻底失效。真正拦住恶意数据的，永远是后端按相同规则再跑一遍——而且必须用服务端语言的标准库，比如 Python 的 email-validator 或 Go 的 net/mail。
pattern 属性容易被当成“正则防火墙”，但实际很脆弱
pattern 适合表达简单约定，比如密码至少 8 位：pattern=".{8,}"；但它不处理空字符串（Safari 就不触发）、不校验 Unicode 边界、更不防回溯爆炸。以下情况必须放弃依赖：
- 正则太复杂，比如带嵌套量词或
.*开头的模式，可能卡死渲染线程 - 规则动态变化，如不同国家身份证格式，前端硬编码
pattern很快过期 - 字段参与权限或金额计算，比如
pattern="[0-9]{1,5}"拦不住后端收到的"999999"
min/max/maxlength 这些数值类属性的真实作用边界
它们能减少用户误操作，但对攻击者毫无约束力。例如：
-
input[type="number"]+min="0"+max="100"可以防止用户滑出范围，但服务端仍需做int(request.form.get("score"))范围校验 -
maxlength="20"拦不住通过fetch提交的超长字符串，后端必须截断或拒绝 - 某些 WebView（如老版 iOS Safari）对
minlength支持不一致，空值时行为不可靠
真正起效的组合：HTML 属性 + 明确的服务端复核逻辑
单独用任何 HTML 属性都没意义，但配合服务端策略时，能抬高攻击门槛：
- 前端用
accept="image/png,image/jpeg"+File.type初筛，服务端必须读文件头魔数（如89 50 4E 47）确认真实 MIME - 前端
type="date"限制选择范围，服务端仍要解析并校验是否在业务允许区间（如不能选未来日期） - 所有校验规则必须前后端完全一致——不是“差不多”，而是正则字符串、字符集白名单、转义方式全部同步
最容易被忽略的是：服务端校验逻辑一旦更新，前端对应提示文案和 pattern 必须同步改，否则用户看到的错误信息和实际拦截点对不上，反而增加调试成本。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
