HTML5 提交的是 YYYY-MM-DD 格式字符串，如"2024-03-15"；数据库应选用 DATE 类型，后端无需转换，直接透传校验即可。
HTML5
浏览器原生控件返回的是 YYYY-MM-DD 格式的纯文本，比如 "2024-03-15"。它不带时区、不含时间部分，本质是 ISO 8601 的“本地日历日期”。后端收到的就是这个字符串，不是 Date 对象，也不是时间戳。
数据库该用 DATE 还是 DATETIME 或 TIMESTAMP
选 DATE 类型最直接匹配——语义清晰、存储紧凑、查询高效。用 DATETIME 或 TIMESTAMP 属于过度设计，除非你后续要扩展为“带时间的事件”，否则会带来三个实际问题：
-
TIMESTAMP在 MySQL 中受时区影响，插入和查询可能自动转换，容易在跨服务器部署时出错 -
DATETIME多存了 6 字节（时间部分），且 ORM 映射时可能默认补00:00:00，造成逻辑混淆 - 所有带时间的类型，在做「某天内」范围查询时都得多写
BETWEEN '2024-03-15 00:00:00' AND '2024-03-15 23:59:59'，而DATE可直写= '2024-03-15'
后端接收时要不要转成时间戳或 Date 对象
不需要。从安全和简洁角度，建议跳过中间转换，直接把 YYYY-MM-DD 字符串传给数据库驱动，由驱动绑定到 DATE 字段。常见错误包括：
- 用 JavaScript
new Date('2024-03-15')再转成时间戳 → 可能因本地时区变成2024-03-14（例如东八区用户在 UTC 上下文里解析） - PHP 用
strtotime()→ 返回整数但丢失精度，再格式化易出错 - Python 用
datetime.strptime(...)后又转回字符串 → 多此一举，还可能引入%Y-%m-%d和%y-%m-%d混用 bug
只要确认输入是合法 YYYY-MM-DD（可用正则 /^\d{4}-\d{2}-\d{2}$/ 做基础校验），就直接透传。
立即学习“前端免费学习笔记（深入）”；
时区问题其实根本不存在
HTML5 date 输入框只管年月日，不采集时区信息，也不隐含 UTC 或本地含义。它表达的是“日历上的这一天”，和“今天是几号”一样，是业务层面的离散值。所以：
- 不必在数据库里存时区字段
- 不要用
TIMESTAMP试图“标准化”它 -
前端显示也无需做时区转换——
2024-03-15在东京、纽约、伦敦都是同一天
真正要小心的，是有人把 date 输入和 datetime-local 混用，或者后端强行塞进带时间的字段里再做时区运算——那不是格式问题，是模型误用。
