原生 返回 "yyyy-mm-dd" 字符串而非 date 对象，需注意空值判断、时区解析、浏览器兼容性及降级方案，服务端不可依赖前端校验。
用 <input type="date"> 就能直接创建原生日期选择器
浏览器原生支持，不用 JS 库也能跑，但得注意它返回的是 "YYYY-MM-DD" 格式字符串，不是 Date 对象。提交表单时值会自动按这个格式编码，后端接收时别当成时间戳或本地化日期解析。
- 必须设置
name属性，否则提交时该字段不会被包含 -
value要严格匹配YYYY-MM-DD（比如"2024-05-20"），填"2024/05/20"或"2024-5-20"会被忽略，输入框显示为空 - 可配合
min、max限制范围，例如min="2024-01-01"，但 Safari 对min/max的校验较弱，需前端额外验证
用户没选日期时 input.value 是空字符串，不是 null 或 undefined
这是最容易踩的坑：很多人用 if (!input.value) 判断是否填写，看起来没问题，但一旦设置了 value="2024-01-01" 又清空，再读 input.value 还是 ""；而如果 DOM 初始化没设 value，初始值也是 ""。所以不能靠“有无 value”反推用户是否操作过。
- 需要区分“未填写”和“已清空”，建议加一个布尔标记（如
hasUserInteracted）监听input或change事件 - 服务端别依赖前端传来的日期必填——即使加了
required，用户仍可绕过（禁用 JS、手动删属性等） - 若需默认值，直接写在 HTML 里：
<input type="date" value="2024-01-01">，JS 动态赋值要用el.value = "2024-01-01"，不要用setAttribute
IE 和旧版 Safari 不支持 type="date"，降级方案要真能用
IE 全系显示为普通文本框；iOS 13.3 之前的 Safari 也只渲染成文本输入，不弹日期面板。这时候不能只加个 placeholder 了事，得提供可操作的替代路径。
- 用
Modernizr.inputtypes.date或简单检测：document.createElement('input').type === 'date'判断支持性 - 不支持时，推荐用两个方案之一：① 改用
type="text"+ 正则限制（如/^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$/）并配日历图标触发 JS 插件；② 直接拆成年/月/日三个<select></select>，兼容性拉满且无需 JS - 避免用
type="date"加 polyfill 库（如 flatpickr 的 auto-init），容易和原生行为冲突，尤其在表单重置（form.reset()）时状态不同步
获取用户选择后，别直接传给 new Date()
input.value 是 "2024-05-20"，传给 new Date("2024-05-20") 在某些浏览器（如 Safari）会解析成 UTC 时间，导致本地时区偏移一天。这不是 bug，是规范行为：带连字符的日期字符串被当作 ISO 8601 UTC 时间处理。
- 安全做法是手动拆解：
const [y, m, d] = input.value.split('-'); const date = new Date(y, m - 1, d); - 或者用
Date.parse(input.value + 'T00:00')强制指定时间为当日零点（但仍有兼容性风险） - 如果只是校验或格式化展示，其实没必要转
Date对象——字符串本身已满足大多数后端接口要求
原生 type="date" 看似简单，但时区、空值语义、降级交互、字符串/对象误转换这四点，任一疏忽都会在真实用户场景中暴露。尤其当表单涉及跨时区业务或需要精确到日的逻辑判断时，别省那几行代码。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
