选日期总比预期早一天，因浏览器用本地时区解析而date()默认按utc解析；应优先用valueasnumber或valueasdate获取值，避免字符串直接构造date对象，并注意ios与android行为差异及二次校验。
HTML 日历控件（<input type="date">）本身不会“影响”日期逻辑，但它会显著改变用户输入路径和底层数据表现——尤其在时区、格式兼容性、移动端行为上，稍不注意就会导致日期错乱。
为什么 <input type="date"> 选出来的日期总比预期早一天？
这是最常踩的坑：浏览器用本地时区解析 2024-05-20 这类字符串，但 JavaScript 的 Date 构造函数默认按 UTC 解析。比如你在东八区输入 5 月 20 日，new Date('2024-05-20') 实际生成的是 2024-05-20T00:00:00Z，转成本地时间就变成 5 月 20 日 08:00，而 .getDate() 取到的仍是 20；但若你用 new Date(2024, 4, 20)（注意月份从 0 开始），它按本地时区构造，结果才真正对应“用户看到的那天”。
- 永远优先用
input.valueAsNumber或input.valueAsDate获取值，它们已由浏览器标准化处理 - 避免手动拼接字符串再传给
new Date()，尤其不要用'2024-05-20'这种格式直接初始化 - 后端接收时，确认它期望的是 ISO 日期字符串（如
"2024-05-20"）还是带时区的时间戳——前者更安全
<input type="date"> 在 iOS 和 Android 上的行为差异
iOS 的原生日历控件强制使用系统语言和格式，且不支持 min/max 属性的某些边界情况（例如设 min="2024-01-01"，用户仍可能手动输入更早日期）；Android Chrome 则允许键盘输入，也更容易绕过限制。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 必须用 JS 做二次校验：
if (input.value && new Date(input.value) - 不要依赖
onchange捕获所有修改——iOS Safari 在取消选择时可能不触发，改用input事件监听更稳妥 - 如果需要统一 UI 或复杂逻辑（如禁用周末），别硬改原生控件，换用
flatpickr或dayjs+ 自定义弹层更可控
服务端收到的日期字符串为什么总是 UTC 零点？
浏览器提交 <input type="date"> 的值时，只发送 YYYY-MM-DD 格式（如 "2024-05-20"），不带时区。但很多后端框架（如 Python 的 datetime.fromisoformat() 或 Node.js 的 new Date()）会把它当作 UTC 处理，导致存储为 2024-05-20T00:00:00Z，查出来显示成 5 月 19 日晚。
- PHP 中用
DateTime::createFromFormat('Y-m-d', $_POST['date'])显式指定无时区上下文 - Node.js 推荐用
dayjs(dateString).startOf('day').toDate()，避免隐式 UTC 转换 - 数据库存日期字段（
DATE类型）时，确保 ORM 没有自动加时区偏移
真正的难点不在怎么调出日历，而在于「用户看到的日期」、「浏览器提交的字符串」、「JS 内部 Date 对象」、「后端解析逻辑」、「数据库存储方式」这五层之间是否始终对齐——漏掉任意一层，日期就可能悄悄偏移一天。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
