仅用pattern属性+正则无法可靠校验日期真实性，如“2023-02-30”能被匹配但非法；必须先用正则（如\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])）做格式初筛，再用Date对象比对toISOString().slice(0,10)确认语义有效性。
仅用 pattern 属性 + 正则表达式无法可靠校验日期是否真实存在，比如 "2023-02-30" 或 "9999-13-01" 都能被简单正则匹配，但它们根本不是合法日期。必须分两步：先用正则筛掉明显非法格式，再用 Date 对象或服务端解析确认语义有效性。
为什么 pattern="^\d{4}-\d{2}-\d{2}$" 会出错
这个正则在 HTML 表单中根本不会生效——浏览器会自动给 pattern 加上 ^(?:...)$，你写 ^ 和 $ 反而可能被旧版 Safari 忽略；更关键的是，它不约束月份范围（允许 13）、不限制每月天数（接受 2月30日），纯属“格式过关、日期造假”。
-
pattern="[0-9]{4}-[0-9]{2}-[0-9]{2}"→ 允许0000-00-00、1234-99-99 -
pattern="\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])"→ 还是会匹配2023-02-30（2月没30天） - 所有
pattern都只对type="text"、type="tel"等字符串型输入有效；type="date"完全忽略pattern，它走的是浏览器原生日期控件逻辑
pattern 该写什么才安全
把它当成第一道快速过滤网，目标是排除明显畸形的字符串，为后续 Date 校验减少无效调用。推荐这个最小可行正则：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
pattern="\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])"
- 强制年份 4 位、月份
01–12、日期01–31，拒绝2023-5-5（缺前导零）和2023-00-01 - 不尝试在正则里处理闰年或大小月——正则做不到，也不该做
- 必须配
title，否则 Chrome 报错只显示“请与所要求的格式匹配”，用户完全不知道要输啥 - 示例：
<input type="text" name="date" pattern="\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])" title="请输入 YYYY-MM-DD 格式，如 2023-06-15">
为什么必须加 JavaScript 做第二层校验
因为 new Date("2023-02-30") 不会报错，而是静默转成 2023-03-02；仅靠 !isNaN(new Date(x)) 判定会放行所有非法日期。
立即学习“前端免费学习笔记（深入）”；
- 正确做法：构造
Date后，用toISOString().slice(0,10)和原始字符串比对 const d = new Date(dateStr); return d instanceof Date && !isNaN(d) && d.toISOString().slice(0,10) === dateStr;- 服务端同理：Python 用
datetime.strptime(s, "%Y-%m-%d")捕获ValueError，不能只信前端正则 - 若用
type="date"，浏览器已帮你挡住非法输入，JS 拿到的值天然合规，无需再正则——但 URL 参数或 API 请求体里的日期字符串仍需完整双重校验
最容易被忽略的是：正则永远只管“长得像不像”，而日期合法性取决于历法规则和运行时解析行为。哪怕 pattern 写得再密，只要没和 Date 或 datetime 对齐原始字符串，就等于没校验。
