time输入框的min/max属性必须用“HH:MM”格式（如"09:00"），否则失效；仅Chrome/Firefox/Edge支持，Safari及部分Android原生选择器可能忽略；属弱约束，需配合JS校验与后端兜底。
time 输入框的 min 和 max 属性必须用 24 小时制字符串
HTML <input type="time"> 本身不校验时间逻辑，只靠 min 和 max 属性做 UI 级限制。但这两个属性值必须是严格格式化的 "HH:MM"（24 小时制，两位小时+两位分钟），不能带秒、时区或空格。写成 "9:00" 或 "17:0" 会失效——浏览器直接忽略该属性。
常见错误现象：min="9:00" 不生效，滑块/下拉仍可选 00:00；控制台无报错，但 input.validity.rangeUnderflow 可能为 true 却没视觉反馈。
- 正确写法：
min="09:00"、max="17:30" - 如果需动态设置，JavaScript 中要用
.toISOString().slice(11,16)截取或手动补零，例如String(hours).padStart(2,'0') + ':' + String(minutes).padStart(2,'0') - 注意：Safari 在 iOS 15.4 之前不支持
min/max对time的限制，仅 Chrome/Firefox/Edge 生效
用户仍可绕过 min/max 直接输入非法时间
min 和 max 是弱约束——用户在文本输入模式下（比如点击输入框后键盘输入）可以手动键入超范围时间，且不会触发 invalid 事件，除非显式调用 checkValidity() 或表单提交。
使用场景：后台强校验前，前端需主动拦截或修正。不要依赖 UI 限制代替逻辑判断。
立即学习“前端免费学习笔记（深入）”；
- 监听
input事件，用new Date()解析输入值并比对范围，再用setSelectionRange()或value覆盖修正 - 更稳妥的做法是提交前调用
form.checkValidity()，并检查input.validity.rangeUnderflow/rangeOverflow - 避免只监听
change：该事件在失去焦点时才触发，无法实时响应
与 JavaScript Date 对象交互时注意时区陷阱
<input type="time"> 的值始终是本地时区的“时刻”，不含日期和时区信息。若你用它构造 Date 对象（如 new Date('2000-01-01T' + input.value)），得到的时间戳会按用户本地时区解释——这在跨时区应用中极易出错。
性能 / 兼容性影响：没有运行时开销，但逻辑错误会导致服务端时间解析偏移。
- 如需 UTC 时间，应先用
input.valueAsNumber（返回毫秒数，从当天 00:00 开始）再结合new Date().getTimezoneOffset()手动换算 - 更推荐方案：改用
<input type="datetime-local">（支持日期+时间+min/max），或后端约定统一用 ISO 字符串传参 - 注意：
valueAsNumber在 Safari 中对time类型返回NaN，需降级处理
移动端时间选择器不响应 min/max 的典型原因
部分 Android 厂商定制系统（如小米 MIUI、华为 EMUI）的时间选择器组件会忽略 min/max，或只限制滚动范围但允许手动输入。这不是 bug，而是原生控件实现差异。
容易踩的坑：在真机测试前只用 Chrome DevTools 模拟，误判功能已覆盖。
- 必须在目标机型上实测；iOS 上一般正常，Android 需重点验证
- 备用方案：禁用原生控件（
appearance: none），用 JS 时间选择库（如 flatpickr）接管，但需额外引入体积和样式成本 - 如果业务允许，可将时间范围限制逻辑下沉到提交接口，前端仅做友好提示
min/max 只是第一道轻量防线，真正关键的是提交时的 JavaScript 校验和后端兜底。别让“看起来被限制了”掩盖了数据层面的风险。 
