<input type="time"> 提交被拦因浏览器严格验证：空值、缺前导零（如"9:30"）、超范围（如"25:00"）均触发 badInput === true，导致 reportValidity() 返回 false 且静默失败；必须确保值为 "HH:mm" 或 "HH:mm:ss" 格式（HH 为 00–23），并用 input 事件监听补零或清空时调用 setCustomValidity('') 解除阻断。
为什么 <input type="time"> 提交时总被浏览器拦住
因为浏览器对 time 输入框的验证非常严格：空值、格式不匹配（如 "9:30" 缺少前导零）、超出 24 小时制范围（如 "25:00"），都会触发 ValidityState.badInput === true，表单 submit 被阻止。它不接受任意字符串，只认 HH:mm 或 HH:mm:ss 格式，且 HH 必须是 00–23。
常见错误现象：form.reportValidity() 返回 false；控制台无报错但提交静默失败；用户输入 "9:30" 后 input.value 为空字符串。
- 确保用户输入始终补零 —— 不要依赖用户手输
"09:30"，用input事件监听并格式化 - 若允许“不填”，需显式设置
required属性为false，或用setCustomValidity('')清除默认验证阻断 - 服务端绝不能信任前端值 ——
time输入框的value是字符串，且可能被绕过（禁用 JS、手动修改 DOM）
如何让 <input type="time"> 接受空值或可选时间
浏览器默认把空 time 输入框视为“无效”，即使没加 required。这是因为规范中空值触发 badInput 而非 valueMissing，导致 checkValidity() 返回 false。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 在
input或change事件中，检测event.target.value === ''，立即调用event.target.setCustomValidity('') - 避免用
required，改用 JS 做业务级校验（例如：“会议开始时间必填，结束时间可选”） - 若需视觉上保留占位提示，用
placeholder属性无效（time不支持），改用 label 文案或外层 wrapper 模拟
示例：
const timeInput = document.querySelector('input[type="time"]');
timeInput.addEventListener('input', () => {
if (timeInput.value === '') {
timeInput.setCustomValidity('');
}
});
后端接收 time 输入值时要注意什么
<input type="time"> 提交的值是形如 "14:30" 或 "14:30:45" 的字符串，不含日期、不含时区。后端解析时容易忽略三点：
- PHP 的
DateTime::createFromFormat('H:i', $val)会接受"9:30"，但浏览器根本不会提交这种格式 —— 所以你收到的一定是两位小时，无需补零处理 - Python 的
datetime.time.fromisoformat()可直接解析"14:30"，但遇到"14:30:00"也 OK；若字段允许秒，注意数据库列类型是否为TIME(0)或TIME(3) - Node.js 的
new Date(`1970-01-01T${value}`)是常见误用 —— 它生成的是本地时区时间，且易因夏令时偏移出错；应直接用字符串切分或专用库（如dayjs的dayjs(val, 'HH:mm')）
替代方案：什么时候该放弃 type="time"
当项目需要支持 Safari 15.6 以下、Android 4.4 WebView、或要求显示 AM/PM、带秒滑动选择、或与日期联动（如“开始时间不能晚于结束时间”）时，原生 time 输入框就力不从心了。
此时更稳的选择是：
- 用
type="text"+ 自研或轻量库（如flatpickr配置enableTime: true, noCalendar: true） - 禁用原生控件：给
input加readonly和onfocus="this.showPicker()"不生效，正确做法是pointer-events: none+ 外层按钮触发自定义面板 - 若仅需 HH:mm，用两个
numberinput（小时 0–23，分钟 0–59）+ 组合逻辑，兼容性最好，无障碍也更可控
原生 time 的最大价值在于移动端唤起系统时间选择器，但它的验证行为和样式不可控，一旦业务规则稍复杂，就该果断换掉。
