input type="time" 的高级设置需聚焦值格式约束、交互时机选择与跨浏览器一致性三大痛点：value须为“09:30”式24小时制补零字符串；min/max在safari中无效；应监听input而非change事件；显示格式受系统locale控制，无法强制24小时制。
input type="time" 的高级设置不是靠堆属性实现的，而是围绕「值格式约束」「交互时机选择」「跨浏览器一致性」三个实际痛点展开。原生控件能力有限，硬加属性容易失效，关键在知道哪些能信、哪些要绕开。
为什么 value="9:30" 会变空？
浏览器对 value 的校验极其严格：只接受两位数补零的 24 小时制字符串，如 "09:30"，"9:30"、"09:30 AM"、"09:30:00" 全部被静默忽略，控件显示为空，input.value 返回空字符串。
- 后端返回的
"9:30"必须前端格式化：timeStr.padStart(5, '0')或new Date('1970-01-01T' + timeStr).toTimeString().slice(0, 5) - 避免在 HTML 中硬写
value="9:30"，改用 JS 赋值：el.value = '14:45'更可控 - 设了
step="1"后，value必须带秒（如"14:45:30"），否则初始值仍为空
min/max 在 Safari 里根本不起作用
min 和 max 属性在 Chrome/Edge 中能禁用超出范围的选项，但在 Safari（含 iOS）中完全无效——因为 Safari 不支持 type="time"，会降级为文本框，所有约束逻辑丢失。
- 不要依赖
:invalid伪类做样式反馈，Safari 不触发该状态 - 校验必须在 JS 中重复实现：监听
input事件，用正则判断是否在范围内 - 例如限制 08:00–17:30：
/^([08-16]|17):(00|15|30|45)$/（需按实际步长调整）
监听 input 事件，别等 change
change 只在失焦或用户确认后触发，无法响应实时选择；input 才是唯一可靠的选择变更监听方式，它在用户点击完成、键盘输入、粘贴后立即触发，且不响应中文输入法选词中间态。
- 不要监听
keyup——type="time"不响应普通按键 - 不要用
valueAsDate取值再转字符串，可能因时区重解析导致时间错位 - 直接读
e.target.value，浏览器已保证其为标准格式（"HH:MM"或"HH:MM:SS"）
强制 24 小时制？原生做不到，别白费劲
显示格式（12h vs 24h）由用户系统 locale 决定，lang、dir、CSS 都无法覆盖。Chrome 英文环境显示 2:30 PM，中文环境才显示 14:30，这种不一致在 B2B 场景中不可接受。
-
<input type="time" lang="zh-CN">完全无效 - 真正可控的方案是放弃原生控件，改用
type="text"+ 实时格式化 + 正则验证 - 或者引入轻量库（如 flatpickr）并关闭其本地化，手动指定 24 小时格式
最常被忽略的一点：你写的 step="30" 在旧版安卓 WebView 中大概率被忽略，界面仍只显示分钟，value 也只保留到分——必须在真实设备上验证，不能只看桌面 Chrome 表现。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
