必须用 hh:mm 或 hh:mm:ss 格式赋值，如 "14:30"；min/max 仅支持 hh:mm，step 单位为秒且旧版 safari 可能忽略；读写均用 value 字符串，监听推荐 change 事件；ie 等不支持时需降级为 type="text" 并校验格式。
input type="time" 的基本用法和 value 格式要求
直接写 <input type="time"> 就能触发原生时间选择器，但必须注意：value 只接受 "HH:MM" 或 "HH:MM:SS" 格式字符串，不能带空格、中文或 AM/PM。比如 value="14:30" 合法，value="下午2:30" 或 value="2:30 PM" 会静默失败，控件显示为空。
常见错误现象是 JS 动态赋值后界面没变化——大概率是字符串格式不对。用 padStart(2, '0') 补零是稳妥做法：
const h = now.getHours();
const m = now.getMinutes();
document.getElementById('meeting-time').value = `${h.toString().padStart(2, '0')}:${m.toString().padStart(2, '0')}`;
min/max/step 属性的取值规则和实际限制效果
min 和 max 必须与 value 同格式，即严格为 "HH:MM"（不支持秒）。浏览器会禁用范围外的时间选项，但用户仍可通过键盘手动输入——所以后端必须二次校验。
step 单位是秒，默认 60（1 分钟）。设 step="900" 表示只允许 00、15、30、45 分；设 step="1800" 则只允许 :00 和 :30。注意：某些旧版 Safari 会忽略 step，不能依赖它做强约束。
-
min="08:00"+max="17:30"+step="900"组合后，合法时间点是 08:00 / 08:15 / … / 17:30 - 若
value超出min/max范围，控件初始化时会清空（不是报错） - 移动端系统级选择器可能不完全响应
step，仅桌面 Chrome/Firefox 表现稳定
JavaScript 操作 time 输入框的典型场景
读取值永远用 element.value，它返回字符串；设置值也必须传字符串。不要试图用 Date 对象直接赋值，input[type="time"] 不接受 Date 实例。
需要把当前时间填入控件时，别漏掉补零逻辑；需要重置为默认时间（如“09:00”），直接赋字符串即可：
document.getElementById('start-time').value = '09:00';
监听时间变更推荐用 change 事件（用户确认选择后触发），而不是 input（每敲一个字符都触发，对 time 类型意义不大）。
兼容性 fallback 和样式控制的现实约束
IE 完全不支持 type="time"，Edge 18- 及部分安卓 WebView 也有问题。渐进增强策略是：先写原生控件，再用 JS 检测支持性，不支持时降级为 type="text" 并配合 pattern="[0-9]{2}:[0-9]{2}" 做基础格式提示。
浏览器强制使用系统原生 UI，CSS 样式控制极其有限：::-webkit-inner-spin-button 可隐藏 Chrome 的上下箭头，但 iOS 和 Android 上几乎无法定制外观。如果项目要求统一视觉风格或需秒级选择、12 小时制、AM/PM 等功能，就得换第三方库（如 flatpickr 或 @mobiscroll/time）。
真正容易被忽略的是：不同系统渲染的交互逻辑差异极大——iOS 滚轮选时分、Android 弹出数字键盘、桌面端靠箭头微调。别在设计稿里假设“用户一定会看到下拉菜单”，更别把时间选择器嵌在固定高度容器里，否则在 iOS 上可能被截断。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
