input[type="time"]的值需正则校验格式并结合业务规则，因Date构造函数不解析纯时间字符串，valueAsNumber在非法时为NaN，推荐用/^([01]\d|2[0-3]):[0-5]\d(:[0-5]\d)?$/匹配HH:mm或HH:mm:ss。
input[type="time"] 的值天然受浏览器约束，只要用户通过原生日历/时间控件选择，value 就一定是合法的 "HH:mm" 或 "HH:mm:ss" 字符串（取决于是否含秒）。但手动输入、JS 赋值、或旧版/非标准环境可能绕过校验，所以仍需主动验证。
为什么 new Date("12:30") 不能用来判断 time 合法性
JavaScript 的 Date 构造函数不解析纯时间字符串：new Date("12:30") 会尝试当作完整日期解析，结果通常是 Invalid Date；即使侥幸返回一个对象（如在某些时区下 fallback 到当前日期），也完全不可靠。时间校验必须独立于 Date 对象。
- 浏览器对
input[type="time"]的原生校验只检查格式（HH:mm或HH:mm:ss），不校验业务逻辑（如“不能早于 09:00”） -
valueAsNumber属性返回的是从当天 00:00 开始的毫秒数，但仅当value合法时才为有效数字；若value为空或非法，valueAsNumber为NaN - 直接用正则匹配比依赖
Date更轻量、更确定
input[type="time"] 的合法格式正则怎么写
标准格式是 HH:mm（24 小时制，两位小时 + 冒号 + 两位分钟），可选秒（HH:mm:ss）。推荐用这个正则做快速过滤：
/^([01]\d|2[0-3]):[0-5]\d(:[0-5]\d)?$/
-
[01]\d|2[0-3]：匹配 00–23，排除 24、25 等非法小时 -
[0-5]\d：匹配 00–59 分钟/秒 - 末尾
?表示秒部分可选，但一旦出现就必须是两位数字+冒号前缀 - 必须用
^和$锚定，否则"25:00"中的"23:00"子串会被误判为合法
如何结合原生校验与自定义规则（如禁止早于 09:00）
浏览器的 setCustomValidity() 是唯一可靠方式，它能触发原生表单提示，且不影响提交流程：
立即学习“前端免费学习笔记（深入）”；
const timeInput = document.querySelector('input[type="time"]');
timeInput.addEventListener('change', () => {
const value = timeInput.value;
// 先过格式关
if (!/^([01]\d|2[0-3]):[0-5]\d$/.test(value)) {
timeInput.setCustomValidity('请输入合法时间（例如 09:30）');
return;
}
// 再业务校验：转成分钟数比较更直观
const [hh, mm] = value.split(':').map(Number);
const totalMinutes = hh * 60 + mm;
if (totalMinutes < 9 * 60) {
timeInput.setCustomValidity('时间不能早于 09:00');
} else {
timeInput.setCustomValidity(''); // 必须清空，否则持续阻断
}
});
- 不要用
input.valueAsNumber做业务比较——它返回毫秒数，但语义模糊（比如 00:01 返回 60000，和 23:59 相差极大，但逻辑上只是 1 分钟之差） - 手动拆解
HH:mm字符串转为分钟数，计算清晰、无时区干扰、易读易维护 -
setCustomValidity('')这一行漏掉会导致后续所有提交都失败，哪怕用户已改对
真正容易被忽略的是：服务端绝不能信任前端任何校验结果。input[type="time"] 的值始终是字符串，后端收到后仍需用同样正则 + 业务逻辑双重验证，尤其要防空字符串、超长字符串、或注入式时间（如 "09:00<script>"</script>）。
