type="time" 不支持秒级选择，因浏览器原生实现仅承诺“时分”；需改用 type="datetime-local" 并设 step="1"，或自研时间控件确保秒级精度。
input type="time" 无法真正精细到秒选择——这不是你配置错了，是浏览器原生实现根本不支持秒级交互。
为什么 step="1" 在多数场景下无效
写 step="1" 看似合理，但实际效果极差：Chrome 桌面版可能允许手动输入 "14:30:45" 并保留，但 UI 不显示秒控件；Safari（包括 iOS）完全忽略 step 属性；Android 系统级时间选择器压根没有秒字段。更关键的是，即使用户键入带秒的字符串，部分浏览器（尤其是旧 WebView 或 Safari）会在提交前自动截断为 "14:30"，且不报错。
-
value读取结果始终是"HH:MM"或空字符串，不含秒（除非你用 JS 强行改值） -
valueAsDate可能返回含秒的Date对象，但用户无法通过 UI 修改秒 - 表单校验（
checkValidity()）对秒字段无感知，"14:30:45"和"14:30"都算合法
datetime-local 是唯一靠谱的原生替代方案
要真正让用户可选、可调、可提交秒级时间，必须换用 input type="datetime-local"，并配 step="1"：
<input type="datetime-local" step="1">
它在 Chrome/Firefox/Edge 中会显示完整年月日+时分秒三段式选择器（含秒滑块），且提交值为 "YYYY-MM-DDTHH:MM:SS" 格式。注意两点：
立即学习“前端免费学习笔记（深入）”；
- 用户看到的是本地时间，不带时区，服务端收到后需按本地时区解析（不是 UTC）
- Safari 桌面版支持较晚（macOS 13+），iOS Safari 从 iOS 16.4 起才稳定支持
step="1"，低于此版本会降级为仅时分 - 若页面只关心时间（不要日期），仍得用 JS 截取
.split('T')[1].slice(0, 8)提取"HH:MM:SS"
真要强依赖秒级时间，就得放弃原生控件
当业务要求「所有终端都必须有秒选择 UI」「不能接受 Safari 降级」「需统一 AM/PM 或 24 小时制展示」时，原生方案已不可靠。此时应：
- 用
input type="text"+ 自研或轻量库（如flatpickr、@vueuse/core的useTimeAgo配合自定义 UI） - 禁用原生控件：
input.setAttribute('type', 'text')后接管焦点与键盘事件，限制输入格式为/^\d{2}:\d{2}:\d{2}$/ - 服务端绝不假设前端传来的 time 字段含秒——要么拆成三个数字字段（hour/min/sec），要么强制用
datetime-local并校验字符串长度是否 ≥ 19
别在 type="time" 上浪费调试时间。它语义上就只承诺“时分”，加 step="1" 是透支规范，不是补丁。
