pattern 对 input type="datetime-local" 无效，浏览器会忽略它；W3C 规范明确禁止其参与验证，且 setCustomValidity() 无法覆盖内置校验逻辑。
datetime-local 的 pattern 属性根本不起作用
直接说结论：pattern 对 <input type="datetime-local"> 无效——浏览器会忽略它。W3C 规范明确要求，对 datetime-local 这类原生日期时间控件，pattern 不参与验证，且 setCustomValidity() 也无法覆盖其内置校验逻辑。
旧版浏览器（如 IE、旧版 Safari）根本不支持 datetime-local
这类浏览器会降级为 type="text"，此时 pattern 才生效，但问题来了：你写的正则必须匹配真实输入格式，而用户自由输入的字符串五花八门。
- 标准格式是
yyyy-MM-ddThh:mm（如2024-05-20T14:30），但用户可能输2024/05/20 14:30、20-05-2024 2:30 PM，甚至空格或中文字符 -
pattern="[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}"看似合理，但只校验格式，不校验日期有效性（比如2024-02-30T12:00也能通过） - IE11 及更早版本连
datetime-local都不识别，连降级都不可靠，valueAsDate返回null，value是空字符串
真正可行的兼容方案只有 JavaScript 校验 + 降级 fallback
别指望 HTML 层面用 pattern 一劳永逸。必须用 JS 做两件事：检测支持性、接管验证逻辑。
- 用
document.createElement('input').type = 'datetime-local'检测是否原生支持；不支持时，手动插入两个<input type="date">和<input type="time">，或引入轻量级 picker 库（如 flatpickr） - 监听
input或blur事件，用new Date(value)尝试解析，并比对toISOString().slice(0,16)是否与输入一致（注意时区影响） - 对旧浏览器，禁用原生
required，改用setCustomValidity()动态设错，且需在form.submit前手动调用checkValidity()
if (!supportsDateTimeLocal()) {
input.type = 'text';
input.addEventListener('blur', () => {
const d = new Date(input.value);
if (isNaN(d.getTime()) || d.toISOString().slice(0,16) !== input.value) {
input.setCustomValidity('请输入有效的日期时间，格式：YYYY-MM-DDTHH:mm');
} else {
input.setCustomValidity('');
}
});
}最常被忽略的坑：时区和 valueAsDate 的行为差异
即使浏览器支持 datetime-local，value 返回的是本地时区的 ISO 字符串（不含时区偏移），但 valueAsDate 返回的是本地时间对应的 Date 对象——这意味着你在 UTC 环境下处理时，容易误以为它是 UTC 时间。
立即学习“前端免费学习笔记（深入）”；
-
input.value永远是类似"2024-05-20T14:30"的字符串，没有Z或+08:00 -
input.valueAsDate在北京时间下返回Sun May 20 2024 14:30:00 GMT+0800，但如果你把它转成 UTC 时间戳再发给后端，得显式调用d.getTime() - d.getTimezoneOffset() * 60000 - 不要用
input.checkValidity()判断值是否合法——它只检查格式，不检查是否为真实日期（如 2 月 30 日在某些浏览器里仍返回 true）
实际项目里，与其花力气绕过浏览器限制，不如用 date + time 组合控件，或者统一用第三方库控制输入路径。原生 datetime-local 的兼容性和语义一致性，远不如表面看起来可靠。
