原生 <input type="time"> 无法满足复杂业务需求，因其样式不可定制、不支持秒级输入、iOS Safari 中事件失效、无法禁用特定时段且 min/max 仅校验提交值；需用 type="text" + 键盘事件模拟或 datetime-local（带日期代价）等组合方案实现可控时间交互。
HTML 原生 <input type="time"> 在多数现代浏览器中能直接唤起时间选择器，但交互效果受限——比如无法自定义样式、不支持秒级输入、iOS Safari 不触发 change 事件、无法禁用特定时间点。真要可控的时间交互，得靠组合方案。
为什么不能只靠 type="time" 做交互逻辑
原生控件在 Chrome/Edge 上表现尚可，但在 iOS Safari 和部分安卓 WebView 中行为割裂：点击无响应、input 事件不触发、valueAsNumber 返回 NaN。更关键的是，它不暴露内部状态，无法做“禁用 12:00–13:00”或“只允许整点选择”这类业务约束。
-
type="time"的min/max只校验提交，不阻止用户手动输入非法值 - iOS Safari 中
input事件在键盘输入后才触发，且不保证格式（如用户输 “9:5”） - 无法监听“正在编辑中”的中间态（比如用户刚删掉分钟位，值暂为 “14:”）
用 type="text" + 键盘事件模拟时间输入（带格式化）
核心思路是用文本框承载输入，用 keydown 和 input 拦截并自动补全冒号、限制字符数、校验范围。比纯 type="time" 更可控，兼容性拉满。
示例逻辑（仅处理 HH:MM）：
立即学习“前端免费学习笔记（深入）”；
const timeInput = document.querySelector('input[data-time]');
timeInput.addEventListener('input', e => {
let v = e.target.value.replace(/\D/g, ''); // 只留数字
if (v.length >= 4) {
v = v.slice(0, 4);
v = v.slice(0, 2) + ':' + v.slice(2);
} else if (v.length >= 2) {
v = v.slice(0, 2) + ':';
}
e.target.value = v;
});
timeInput.addEventListener('blur', e => {
const [h, m] = e.target.value.split(':').map(Number);
if (isNaN(h) || isNaN(m) || h < 0 || h > 23 || m < 0 || m > 59) {
e.target.value = ''; // 清空非法值
}
});
- 避免用
keypress：已被废弃，且不捕获删除键 - 不要在
input中直接e.preventDefault()，会阻断用户粘贴 - 注意移动端软键盘弹出时，
blur可能延迟触发，校验逻辑建议同时放在change和blur
用 datetime-local 替代 time 的隐藏代价
如果业务允许带日期（比如预约系统），<input type="datetime-local"> 在桌面端 Chrome/Edge 中提供带时间滚轮的统一 UI，且 valueAsNumber 可靠。但它在 iOS Safari 中仍降级为文本框，且必须包含日期部分——哪怕你只关心时间。
- 设置默认日期为今天：
input.value = new Date().toISOString().slice(0, 16)（注意时区） - 提交前提取时间部分：
new Date(input.value).toTimeString().slice(0, 5)，但需注意时区偏移 - 若后端只要时间字符串（如 "14:30"），前端解析后务必丢弃日期，否则可能因本地时区导致服务端解析错误
真正难的不是让时间“看起来可选”，而是让时间“按业务规则被选”。格式化、禁用、时区、移动端回填——这些细节堆起来，原生控件就撑不住了。动手前先想清楚：你到底需要用户「输入」时间，还是「选择」时间？前者倾向文本+JS控制，后者倾向封装好的日历组件（如 flatpickr 的 time-only 模式）。
