HTML5 type="date" 输入框内置ISO 8601格式校验，但JS或服务端需正则+Date双重验证；仅用^\d{4}-\d{2}-\d{2}$会误判非法日期，应先用约束前导零的正则过滤，再通过new Date()与toISOString()比对确保真实存在。
HTML5 的 type="date" 输入框本身已内置日期格式校验（ISO 8601，即 YYYY-MM-DD），无需额外正则；但若需在 JS 中手动校验字符串、或服务端/非 input 场景复用逻辑，则必须用正则 —— 而且不能只靠 ^\d{4}-\d{2}-\d{2}$ 这种“假校验”。
为什么 ^\d{4}-\d{2}-\d{2}$ 不够用
它能匹配 9999-99-99、2023-02-30、2023-13-01 这类非法日期，纯属格式过关、语义错误。真实校验要兼顾：年份合理性（如不早于 1900）、月份范围（1–12）、各月天数（含闰年 2 月）、连字符位置与长度。
- 浏览器原生
<input type="date">会自动拒绝2023-02-30，但 JSvalue拿到的已是合法字符串，无需再正则 - 若后端接收 JSON 或解析 URL 参数中的日期字符串（如
?from=2023-02-30），才需要严格正则+逻辑双重把关 - 正则单独无法判断闰年或大小月，只能做前置过滤：先用正则筛出形如
YYYY-MM-DD的字符串，再用new Date()或手动计算验证有效性
推荐的正则 + 验证组合写法（JS）
分两步：正则快速排除明显非法格式，再用 Date 构造器确认是否真实存在该日期。
- 正则建议：
^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$—— 约束月份 01–12、日期 01–31，避免2023-00-00或2023-5-5（缺前导零） - 后续必须验证：
const d = new Date(dateStr); return d instanceof Date && !isNaN(d) && d.toISOString().slice(0,10) === dateStr; - 注意：
new Date("2023-02-30")不会报错，而是自动进位成2023-03-02，所以必须比对toISOString()结果是否与原字符串一致
服务端校验别依赖前端正则
前端正则可提升用户体验（实时提示），但服务端必须独立验证。例如 Node.js 中：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
立即学习“前端免费学习笔记（深入）”；
function isValidDateStr(str) {
if (!/^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$/.test(str)) return false;
const d = new Date(str);
return d instanceof Date && !isNaN(d) && d.toISOString().slice(0,10) === str;
}
Python 同理，用 datetime.strptime() 捕获 ValueError，而非仅靠正则。
真正容易被忽略的是：正则永远只是第一道筛子，Date 对象的隐式转换行为（如自动进位、时区偏移）会让单纯 !isNaN(new Date(x)) 判定失效 —— 必须比对字符串原始值。
