HTML input 的 pattern 属性仅支持字符串格式匹配，无法校验日期语义合法性（如闰年、大小月），必须结合 JavaScript 的 Date 对象反向验证，并辅以后端严格校验。
HTML input 的 pattern 属性不支持完整日期校验
直接用 HTML 的 pattern 做“2024-02-30 是否合法”这类语义校验是不可能的。它只做字符串匹配，无法判断闰年、大小月、是否为真实存在日期。比如 pattern="^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])$" 会把 2024-02-30 当作合法——但 2 月根本没有 30 号。
常见错误现象：用户输入 2023-02-29（非闰年）或 2024-13-01，表单仍能提交成功，前端毫无感知。
-
pattern适合做基础格式过滤（如必须是YYYY-MM-DD形式），不是日期有效性校验工具 - 正则本身无法计算 2 月天数，更无法处理时区、
Date.parse()的兼容性差异 - 若仅靠
pattern，后端必须重复校验，且无法给用户即时反馈
用 JavaScript 配合 new Date() 做轻量级合法性检查
真正可行的做法是监听 input 或 blur，用 JS 构造 Date 对象并反向验证。关键点在于：不能只看 isNaN(new Date(val))，还要比对年月日是否被自动修正过。
例如：new Date("2024-02-30") 会悄悄变成 2024-03-01，这不是我们想要的“合法”。所以得提取原始值再比对：
立即学习“前端免费学习笔记（深入）”；
function isValidDateStr(str) {
const d = new Date(str);
if (isNaN(d.getTime())) return false;
const parts = str.match(/^(\d{4})-(\d{2})-(\d{2})$/);
if (!parts) return false;
return d.getFullYear() === +parts[1] &&
d.getMonth() + 1 === +parts[2] &&
d.getDate() === +parts[3];
}- 必须用
getFullYear()/getMonth()/getDate()，避免getYear()这种废弃方法 -
getMonth()返回 0~11，所以要加 1 才和输入的月份一致 - IE11 对
"2024-02-30"解析行为不一致，建议统一用new Date(year, month - 1, day)构造再比对
需要严格校验时，别绕开后端
前端任何校验都可被绕过。如果业务要求“必须是今天之后的日期”或“不能超过三年”，这些逻辑必须在后端重做一次。前端只负责降低用户误操作率，不承担数据准确性责任。
- 后端校验要用语言原生日期库（如 Python 的
datetime.date.fromisoformat()，Node.js 的date-fns/parseISO），而非正则 - HTTP 接口返回的错误信息应明确指出哪天不合法，而不是笼统说“日期格式错误”
- 前后端月份范围约定要一致（比如都用 1~12，别前端传 0~11 后端没转换）
移动端 input[type="date"] 的兼容性陷阱
虽然 <input type="date"> 自带日期选择器，看似省事，但它在 iOS Safari 和部分安卓 WebView 中存在严重问题：
- iOS 上
value始终是YYYY-MM-DD格式，但用户通过键盘手动输入时，可能绕过 picker 直接填2024/02/30，此时valueAsNumber会是NaN，但value字符串依然存在 - 某些安卓版本对
min/max属性支持不全，需额外 JS 补充限制 - 如果设计上允许手动输入（比如扫码填充日期），就不能依赖
type="date"的内置校验
最稳妥的方式是：用 type="text" + 自定义输入框 + JS 校验 + 可选的日期 picker 插件（如 flatpickr），把控制权牢牢握在自己手里。
