date 和 datetime-local 在 Chrome、Edge、Firefox 中支持良好，但 Safari（尤其 iOS 16.4 前）存在兼容问题；datetime-local 值格式固定为 YYYY-MM-DDTHH:MM，无效时 value 为空字符串；需用 JS 解析修正输入、避免光标跳动；表单提交时无效字段不会出现在 POST 数据中；原生样式不可定制日历面板；datetime-local 无时区信息，后端须明确处理逻辑。
date 和 datetime-local 输入类型在不同浏览器中的表现差异
Chrome、Edge 和 Firefox 对 date 和 datetime-local 的原生支持基本一致，但 Safari 在 macOS 和 iOS 上长期存在兼容性问题：iOS 16.4 之前不支持 datetime-local，只渲染为文本框；macOS Safari 直到 Safari 16.5 才完整支持 datetime-local。这意味着依赖原生控件时，用户可能看到的是纯文本输入而非日历/时间选择器。
-
date在所有现代桌面浏览器中都能唤起日历弹窗，但在旧版 Android WebView 中可能退化为文本输入 -
datetime-local的值格式固定为YYYY-MM-DDTHH:MM（无秒、无时区），提交前必须确保格式合法，否则表单会静默失败或触发invalid事件 - 若需兼容 Safari 或低版本 WebView，应搭配 JavaScript 库（如 flatpickr）或 fallback 文本输入 + 格式校验
如何用 JavaScript 拦截并修正用户手动输入的日期格式
用户直接在 date 或 datetime-local 输入框中键入内容时，浏览器不会自动标准化格式，比如输入 2024/05/01 或 01-05-2024 会被视为无效值，input.value 返回空字符串。必须监听 input 或 change 事件，并主动解析和重写。
- 对
date类型，可使用new Date(input.value)判断是否有效，再用toISOString().slice(0,10)提取标准格式 - 对
datetime-local，需补全缺失的时分（如只输日期），可用正则匹配后拼接默认时间T00:00 - 避免在
input事件中直接赋值input.value = ...，这会导致光标跳到末尾；推荐用setSelectionRange保留编辑位置
form 表单提交时 date/datetime-local 字段为空的常见原因
字段显示有值，但 FormData 或序列化后的数据里该字段为空，通常不是代码写错，而是值本身未通过浏览器内置校验。
- 用户清空输入框后 blur，
input.value变为空字符串，而非null，此时required属性会阻止提交，但若没设required，字段就真的被忽略 -
datetime-local输入框若用户只填了日期（如2024-05-01），缺少T和时间部分，浏览器判定为无效，value保持空字符串 - 服务器端接收时注意：PHP 的
$_POST或 Node.js 的req.body不会包含该字段名，而不是传空字符串——这是 HTML 表单规范行为，不是 bug
用 CSS 定制原生日期选择器的外观是否可行
不能真正“定制”弹出的日历面板样式，但可以控制输入框本身的视觉表现，并隐藏默认箭头（仅限部分浏览器）。
立即学习“前端免费学习笔记（深入）”；
- Chrome/Edge 允许用
::webkit-inner-spin-button和::webkit-calendar-picker-indicator隐藏上下箭头或右侧图标，但 Safari 和 Firefox 不支持这些伪元素 - 无法修改日历弹窗的颜色、字体、按钮形状等，这些由操作系统或浏览器 UI 控制，强行覆盖会失效
- 如果品牌一致性要求高，更可靠的方式是禁用原生控件（
appearance: none+pointer-events: none），再叠加自定义浮层组件
datetime-local 值永远不含时区信息，哪怕用户本地时区是 UTC+8，提交的仍是 2024-05-01T14:30 这样的本地时间字符串——后端必须明确按客户端本地时间解释，还是统一转成 UTC 处理。这个逻辑一旦定错，时间就偏了八小时。 
