本身不乱码，所谓乱码实为locale、时区、编码未对齐所致；需统一用yyyy-mm-dd字符串流转，格式化/解析时显式指定zh-cn locale和本地时区。
<input type="date"> 本身不显示中文，也不会“乱码”——你看到的所谓乱码，基本是浏览器渲染日期字符串、toLocaleDateString() 格式化、或后端解析时 locale / 时区 / 编码三者没对齐导致的假象。
为什么 toLocaleDateString() 显示中文但格式错乱或变英文
这不是乱码，是 locale 缺失或不一致。浏览器用系统语言 fallback，但没显式指定 locale 时，Safari 可能用 en-US，Chrome 用 zh-CN，结果同个页面不同表现。
- 必须在调用时显式传 locale：
date.toLocaleDateString('zh-CN', { year: 'numeric', month: '2-digit', day: '2-digit' }) - 确保 HTML 根元素有
lang="zh-CN"，否则部分旧 Safari 不识别zh-CNlocale - 别用
date.toString()或拼接字符串（如date.getFullYear() + '-' + (date.getMonth()+1)），它不处理补零、农历、夏令时等边界
表单提交后日期变成前一天或 Invalid Date
这是时区归一化惹的祸：<input type="date"> 用户选的是本地日（如东八区 2024-03-15），但浏览器内部按 UTC 零点提交为 2024-03-15T00:00:00.000Z，服务端若用 new Date('2024-03-15') 解析，就可能退成 3 月 14 日。
- 前端读值别依赖
input.value直接转 Date：用new Date(input.value + 'T00:00')构造本地零点时间 - 后端接收时别用字符串自动构造 Date 对象；优先解析带时区的 ISO 字符串（如
2024-03-15T00:00:00+08:00）或明确指定时区 - 数据库存贮推荐用
DATE类型（无时区）或TIMESTAMP WITHOUT TIME ZONE，避免隐式转换
input.value 赋值后变空或不生效
<input type="date"> 只接受严格 YYYY-MM-DD 格式字符串，其他格式（如 2024/03/15、15-03-2024）会导致输入框清空或报错。
- 赋值前必须校验：
if (/^\d{4}-\d{2}-\d{2}$/.test(val)) input.value = val - 提交前检查是否为空：
if (!input.value) { /* 提示必填 */ }，别依赖checkValidity()后再读值，它可能已失效 - 后端返回日期字段给前端渲染时，务必先格式化为
YYYY-MM-DD，不能直接塞2024-03-15T08:00:00.000Z
真正要盯紧的只有两条线：一是所有环节统一用 YYYY-MM-DD 字符串流转日期（不带时间、不带时区），二是涉及格式化或解析的地方，必须显式指定 zh-CN locale 和本地时区逻辑——浏览器从不乱码，它只是太守规矩了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
