<input type="time">原生支持时间选择，返回HH:MM格式字符串，移动端唤起系统键盘；需设id/name提交，step控制分钟粒度（如900=15分），IE不支持须降级为text+pattern或JS检测，服务端必须二次校验。
用 <input type="time"> 最直接
浏览器原生支持，不用 JS 就能拿到格式化的小时分钟值（如 "14:30"），且在移动端会唤起系统时间选择器，体验比手输好得多。
基础写法就是：
<input type="time" id="meeting-time">。注意它默认不带秒，值始终是
HH:MM 格式，即使用户选了秒，大多数浏览器也会忽略或截断。
- 必须加
id或name，否则表单提交时拿不到值 - 不设
value时，初始显示为空（不是当前时间），要预设得手动填，比如value="09:00" - Chrome/Firefox/Safari 都支持，但 IE 完全不支持，需降级方案
step 属性控制最小时间粒度
默认粒度是 60 秒（即 1 分钟），如果想允许用户选 15 分钟间隔（如会议时段），就得用 step：
<input type="time" step="900"> <!-- 900 秒 = 15 分钟 -->
这个值单位是秒，常见取值：60（1 分）、300（5 分）、900（15 分）、1800（30 分）。设成 1 并不会启用秒选择——多数浏览器仍只显示分，且可能报错或忽略。
立即学习“前端免费学习笔记（深入）”；
-
step只影响可选值范围，不影响输入框显示精度 - 若设
step="1"且浏览器支持秒（如新版 Chrome 加required后），才可能显示HH:MM:SS - Firefox 目前完全忽略
step对 time 输入框的影响
兼容性差时 fallback 到文本输入 + 正则校验
IE、旧版 Safari 或某些安卓 WebView 不识别 type="time"，会退化成普通文本框，这时得自己兜底。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
先用 type="text"，再加 pattern 和 title 引导用户输入：
<input type="text" pattern="[0-9]{2}:[0-9]{2}" title="请输入 HH:MM 格式，例如 09:30" placeholder="09:30">但 pattern 只在表单提交时校验，交互体验弱。更稳妥的是用 JS 检测支持性：
const input = document.getElementById('meeting-time');<br>if (input.type !== 'time') {<br> input.type = 'text';<br> input.placeholder = 'HH:MM';<br> // 后续可加 keyup 监听，实时格式化或校验<br>}- 别依赖
Modernizr.inputtypes.time，太重；用上面的属性检测更轻量 - 服务端必须二次校验，因为前端校验可绕过
- 移动端 fallback 后失去原生时间键盘，用户易输错，建议加「点击选择」按钮触发 JS 时间 picker
获取和设置值要注意时区与字符串格式
input.value 拿到的永远是本地时区下的 "HH:MM" 字符串，不含日期、不含时区信息。它不是 Date 对象，不能直接传给 new Date()。
比如用户选了 "15:45"，你不能写 new Date("15:45")——这会解析失败或变成 1970 年某天。正确做法是拼一个完整日期再解析：
const timeStr = input.value; // "15:45"<br>const today = new Date();<br>const [h, m] = timeStr.split(':').map(Number);<br>const dt = new Date(today.getFullYear(), today.getMonth(), today.getDate(), h, m);- 不要用
Date.parse()解析纯时间字符串，行为不一致 - 如果后端需要 ISO 时间（如
"T15:45"），直接拼接即可："T" + input.value - 设值时，
input.value = "08:00"有效；设"8:00"或"08:0"会被清空或忽略
真正麻烦的是跨时区场景：用户在北京选 "09:00"，后端按 UTC 存，前端再读出来显示时还得转回本地——type="time" 本身不解决这个问题，得靠业务层约定或额外字段传递时区。
