time输入框value必须为hh:mm或hh:mm:ss格式（24小时制），否则变空；需用字符串赋值、截取totimestring、解析iso时间提取；required不可靠，须js校验+change监听+css反馈；移动端兼容差，需fallback与服务端双重校验。
time 输入框的 value 值必须符合 ISO 8601 时间格式
浏览器只接受 HH:MM 或 HH:MM:SS 格式的字符串（24 小时制），比如 "14:30" 或 "09:05:22"。哪怕多一个空格、少一位数、用 12 小时制带 AM/PM，value 都会变成空字符串 —— 这是表单验证失败最隐蔽的源头。
常见错误现象：input.value 看起来有值，但实际是空；提交后后端收不到时间字段。
- 手动赋值时务必用
input.value = "13:45"，不要写"1:45 PM"或"13:45:00.000" - 从 Date 对象生成时，用
date.toTimeString().slice(0, 5)截取前 5 位（如"13:45"），避免毫秒和时区干扰 - 后端传来的 ISO 时间字符串（如
"2023-05-12T13:45:00"）需先解析再提取：new Date(timeStr).toTimeString().slice(0, 5)
required 属性不等于“用户选了时间”
required 只校验 value 是否为非空字符串，而 time 输入框在未操作时 value 默认为空，点开又取消选择，value 仍是空 —— 表面看没问题，但用户可能根本没意识到要选。
更现实的问题是：用户点了输入框、看了下时间、关掉，表单就通过了，但业务上这不算有效输入。
- 别只依赖
required，加一层 JS 判断：if (!input.value || input.value === "Invalid Date") - 监听
change而非input，避免频繁触发；但得补一个提交前的兜底校验 - 配合
:valid/:invalidCSS 伪类做视觉反馈，比如红框+提示文字，比默认浏览器提示更可控
移动端 time 输入框的兼容性与 fallback 方案
iOS Safari 16.4 之前不支持 type="time" 的原生控件，Android Chrome 虽支持但弹出的是滚轮式时间选择器，样式不可控，且部分低端机型会回退成文本框 —— 这时候用户直接输 "25:00" 也能通过 required 校验。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
关键不是“能不能用”，而是“用户输错时系统能不能拦住”。原生控件在低端环境几乎不校验格式。
- 服务端必须二次校验：解析
HH:MM字符串，检查0 ≤ HH 且 <code>0 ≤ MM - 前端 fallback 推荐用
input type="text"+ 正则/^([01]?[0-9]|2[0-3]):[0-5][0-9]$/实时匹配 - 不要用第三方日期库强行统一 time 控件，它解决不了原生控件缺失时的语义缺失问题
form.checkValidity() 和 reportValidity() 的实际表现
调用 form.checkValidity() 会触发所有 type="time" 输入框的原生校验逻辑，但它的返回值只反映「是否满足 required / pattern 等约束」，不反映时间值是否合法（比如 "25:00" 在某些浏览器里会被认为合法）。
更麻烦的是：reportValidity() 在 iOS 上可能完全不显示错误提示，或提示语是英文且无法定制。
- 别把
reportValidity()当最终防线，它只是辅助手段 - 提交前手动遍历所有 time 输入框：
Array.from(form.querySelectorAll('input[type="time"]')).every(el => isValidTime(el.value)) -
isValidTime(str)函数至少要做三件事：非空判断 → 格式正则匹配 → 数值范围校验
真正容易被忽略的点是：time 输入框的 value 是只读字符串，你不能靠设置 valueAsNumber 或 valueAsDate 来绕过格式限制 —— 它们在 time 类型上始终返回 NaN 或 null。所有处理都得回到字符串层面。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
