提交值为空或格式异常，主因是浏览器未交互时忽略字段、不支持秒/时区且无日期上下文；服务端须校验空值，前端应补默认值，解析需手动分离时分，跨控件需同步逻辑，移动端需正则校验兜底。
HTML <input type="time"> 提交时值为空或格式异常
浏览器原生 <input type="time"> 默认提交的是 HH:MM 格式字符串（如 "14:30"），但实际开发中常遇到后端接收不到、被当成空字符串、或解析失败。根本原因不是前端没填，而是：用户未聚焦/未修改过该字段时，部分浏览器（尤其是 Safari 和旧版 Chrome）可能不触发 change 事件，且表单序列化时若字段未被“交互过”，FormData 或 form.submit() 可能忽略它；更关键的是，该控件**不支持秒和时区**，且值始终是本地时区下的时间，没有日期上下文。
实操建议：
- 服务端不要依赖该字段“一定存在”，需做空值校验（如
if (!req.body.time) { ... }） - 前端提交前主动读取值并补默认值：
const timeInput = document.querySelector('input[type="time"]');<br>const timeValue = timeInput.value || '00:00'; // 避免空串 - 若需秒级精度或 UTC 时间，必须用
<input type="text">+ 自定义时间选择器（如 flatpickr），不能强求原生控件
后端解析 <input type="time"> 提交的 HH:MM 字符串
Node.js（Express）、Python（Flask/Django）、PHP 等环境收到的都是纯字符串，比如 "09:15"。它不是 ISO 时间，也不含日期，直接传给 new Date() 或 datetime.strptime() 会出错或产生意外日期（如 1970-01-01）。
正确做法是分离时分，再组合为所需格式：
立即学习“前端免费学习笔记（深入）”；
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- JavaScript 后端（如 Express）：
const [hours, minutes] = req.body.time.split(':').map(Number);<br>// 构造当日时间戳（如需）<br>const now = new Date();<br>now.setHours(hours, minutes, 0, 0); - Python Flask：
time_str = request.form.get('time', '00:00')<br>try:<br> h, m = map(int, time_str.split(':'))<br> # 转为 timedelta 或拼入当前日期<br>except (ValueError, ValueError):<br> h, m = 0, 0 - 注意：别用
datetime.fromisoformat("09:15")—— 这会报ValueError，ISO 时间必须含日期
与 <input type="datetime-local"> 混用时的时间一致性问题
如果页面同时用了 <input type="time"> 和 <input type="datetime-local">，它们的值在不加干预时完全独立：前者只传时分，后者传“日期+本地时间”（如 "2024-05-20T14:30"）。用户改了日期但忘了调时间，或反之，后端拿到的就是割裂数据。
常见错误现象：预约系统里选了“2024-05-20 14:30”，但时间输入框还是“08:00”，最终存成“2024-05-20 08:00”。
解决思路：
- 优先弃用单独的
type="time"，改用type="datetime-local"并用 CSS 隐藏日期部分（不推荐，可访问性差） - 更稳妥的是：只保留一个
datetime-local，前端用 JS 拆解其值供展示：const dt = new Date(input.value);<br>const timeOnly = dt.toTimeString().slice(0, 5); // "14:30"
- 若 UI 强制要求分离日期/时间控件，必须用 JS 同步二者：
datetime-local改变时，更新time值；time改变时，用当前日期拼接新datetime-local值
移动端 Safari 对 type="time" 的兼容性陷阱
iOS 15+ 之前，Safari 不支持 type="time" 的原生唤起，会降级为文本输入框，且不校验格式（用户可输 "abc" 或 "25:70"）。iOS 16+ 支持了，但仍有两个坑：
- 点击输入框后弹出滚轮选择器，但**点击遮罩层取消后，
value仍会被设为空字符串**（即使之前有值） - 用户用语音输入“下午三点”，Safari 可能解析为
"15:00"，也可能解析失败留空 - 应对方式：提交前强制校验格式，用正则
/^([01]?[0-9]|2[0-3]):[0-5][0-9]$/，不匹配就提示重填或 fallback 到默认值
真正难处理的不是怎么读值，而是怎么让这个控件在各种设备上行为一致 —— 它天生缺乏对“未填写”“取消操作”“非法输入”的明确语义表达，所有边界都得自己兜底。
