HTML5 的 value 属性直接返回标准 YYYY-MM-DD 字符串，无需 Date 转换；误用 new Date(input.value) 可能因时区导致日期偏移；空值为 ""；valueAsNumber 和 valueAsDate 存在时区与空值陷阱；服务端仍需校验格式与有效性。
HTML5 <input type="date"> 的值本身就是字符串
很多人以为需要手动格式化，其实浏览器原生返回的就是 YYYY-MM-DD 格式字符串。直接读取 input.value 即可，无需调用 toISOString() 或 toLocaleDateString() 等方法转换。
常见错误是拿 new Date(input.value) 再转——这反而可能因时区导致日期偏移（比如用户选的是 2023-10-01，但构造出的 Date 对象在本地时区解析后变成 9 月 30 日晚）。
-
input.value永远是"2023-10-01"这样的字符串，与用户所在时区无关 - 如果 input 未填写，
value是空字符串""，不是null或undefined - 该值可直接提交给后端、存入数据库，或用于 URL 查询参数
需要其他格式（如 YYYY/MM/DD）时才需手动替换
若 UI 或接口要求非标准分隔符（比如斜杠、中文年月日），用字符串替换最安全：
const dateStr = input.value; // "2023-10-01"
const slashFormat = dateStr.replace(/-/g, '/'); // "2023/10/01"
const cnFormat = dateStr.replace(/(\d{4})-(\d{2})-(\d{2})/, '$1年$2月$3日'); // "2023年10月01日"
不建议用 Date 构造后再格式化，因为：
— 输入为空时 new Date("") 返回 Invalid Date，容易引发错误
— 不同浏览器对 new Date("2023-10-01") 的解析行为一致，但一旦涉及时间部分（如 "2023-10-01T00:00"）就可能有时区歧义
注意 input.valueAsNumber 和 valueAsDate 的陷阱
这两个属性看似方便，实际容易出问题：
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
立即学习“前端免费学习笔记（深入）”；
-
input.valueAsNumber返回毫秒时间戳（如1696118400000），但它是基于 UTC 零点计算的——用户选2023-10-01，它返回的是2023-10-01T00:00:00Z对应的时间戳，和用户本地理解的“当天”可能跨日 -
input.valueAsDate返回Date对象，但它的getMonth()、getDate()等方法受本地时区影响，直接拼字符串仍需补零、调整 - 当 input 为空时，二者都返回
NaN（valueAsNumber）或null（valueAsDate），需额外判断
服务端接收时别假设格式一定合法
前端传来的 input.value 虽然浏览器强制校验格式，但绕过 HTML 表单（如 API 直接调用、爬虫、旧版浏览器）仍可能收到非法值：
- 检查是否匹配正则
/^\d{4}-\d{2}-\d{2}$/ - 验证日期有效性（如
2023-02-30浏览器会拒绝，但伪造请求可能发过来） - Node.js 可用
!isNaN(new Date(dateStr).getTime())快速判有效，但注意new Date("2023-02-30")在某些环境返回Invalid Date，有些却静默修正为 3 月 2 日
真正容易被忽略的是：日期字符串的「语义」依赖上下文。同一个 "2023-10-01" 在日志系统里可能是 UTC，在财务系统里可能默认是本地时区——格式只是表层，含义得靠协议约定清楚。
