必须用.value获取<input type="time">的值，因其返回"HH:MM"格式字符串；.valueAsDate返回null，.valueAsNumber返回NaN；需手动解析字符串，注意空值和时区无标识。
获取 <input type="time"> 的值必须用 .value，不是 .valueAsNumber 或 .valueAsDate
HTML 时间输入框（<input type="time">）返回的是字符串格式，形如 "14:30" 或 "09:05"，不是 Date 对象，也不是毫秒数。试图用 .valueAsDate 会返回 null，.valueAsNumber 也始终为 NaN —— 这是规范明确规定的，不是浏览器 bug。
常见错误现象：
• 直接对 input.valueAsDate 调用 .getHours() 报错 “Cannot read property 'getHours' of null”
• 用 new Date(input.value) 得到一个错误日期（如 1970 年 1 月 1 日），时分被当作 UTC 解析，本地时区未参与转换
- 正确做法：只用
input.value获取原始字符串 - 若需计算或比较，手动解析字符串，例如
input.value.split(':').map(Number) - 注意空值：用户未选择时，
input.value是空字符串""，需提前判断
解析 input.value 得到小时和分钟要小心时区与 24 小时制
<input type="time"> 值始终以 24 小时制、本地时区显示和提交，但不携带时区信息。它只是“时间片段”，没有日期上下文。这意味着你不能直接把它喂给 Date 构造函数来获得有意义的绝对时间点。
- 安全解析示例：
const timeStr = input.value; // "15:45" if (!timeStr) return; const [hours, minutes] = timeStr.split(':').map(Number); // [15, 45] - 避免
new Date(`1970-01-01T${timeStr}`)：虽然能构造出 Date 对象，但会隐式按本地时区解释该时间，跨浏览器行为一致但易引发误解（比如你以为它代表 UTC） - 如果后续要和日期合并（如选了日期 + 时间），应显式使用
setHours(hours, minutes)到目标Date实例上，而不是拼字符串再解析
提交表单时，<input type="time"> 的值自动编码为字符串，无需额外处理
当表单以 application/x-www-form-urlencoded 提交（包括原生 submit 或 FormData.append()），<input type="time"> 的值会原样作为字符串发送，符合 RFC 3339 的 HH:MM 或 HH:MM:SS 格式（秒可选，取决于浏览器是否显示秒控件）。
立即学习“前端免费学习笔记（深入）”；
- 服务端收到的就是类似
meeting_time=13%3A20（即meeting_time=13:20） - 用
FormData采集时：const fd = new FormData(form); console.log(fd.get('my-time-input')); // 直接得到 "08:45" 字符串 - 不要在 JS 中提前转成时间戳或 Date 再塞进 FormData —— 后端通常更希望接收标准时间字符串，便于验证和存储
移动端兼容性没问题，但 iOS Safari 不支持秒输入且默认不显示秒
所有现代浏览器（Chrome、Firefox、Edge、Safari）都支持 type="time"，但实现细节有差异：
- iOS Safari 和旧版 Android WebView 不显示秒控件，即使设置
step="1"也无效；其value永远是"HH:MM"格式 - 桌面 Chrome 允许通过
step="1"显示秒选择器，此时value可能为"14:22:05" - 如果你依赖秒级精度，不能只靠
type="time"，得降级为文本输入 + 自定义校验，或改用type="datetime-local"（但会带日期）
真正麻烦的地方在于：这个控件看起来很“智能”，但它不提供任何时区标识、不触发 change 以外的语义事件、也不暴露内部时间对象 —— 所有逻辑必须由你用字符串手工维护。别指望它替你做时区转换或时间运算。
