HTML5 input[type="date"]不支持负数年份（公元前），因严格遵循ISO 8601的YYYY-MM-DD格式，要求年份为1–9999的4位无符号数字；设value为"-0044-03-15"会清空值，checkValidity()返回false，且min/max/step等属性对负年份无效。
HTML5 input[type="date"] 不支持负数年份（公元前年份）
浏览器原生的 input[type="date"] 控件只接受公元1年及以后的日期，年份范围通常为 1–9999。传入负数（如 -44 表示公元前44年）或字符串 "-0044" 会导致值被清空或解析失败，且无明确错误提示。
为什么 value 设为负数会失效
HTML5 日期类型严格遵循 ISO 8601 标准中「扩展格式」的子集，即 YYYY-MM-DD，其中 YYYY 要求是 4 位十进制数字（如 0001–9999），不包含带符号的年份表示法。即使某些 XML Schema 或 JavaScript Date 支持 +0000/-0000 扩展语法，浏览器表单控件并未实现该部分。
-
input.value = "-0044-03-15"→ 实际被忽略，input.value变为空字符串 -
new Date("-0044-03-15")在部分 JS 引擎中可能解析成功（非标准行为，V8/SpiderMonkey 不保证） - 提交表单时，该字段会被当作无效值跳过（取决于 form validation 状态）
需要公元前年份时的替代方案
必须放弃原生 input[type="date"]，改用组合式输入或第三方组件：
- 三个独立
select：年份（含“公元前”标识）、月份、日期，年份选项手动构造（如["公元前1000年", "公元前1年", "公元1年", ...]） - 使用
input[type="text"]+ 自定义日期解析库（如date-fns或dayjs插件），自行处理"BCE 44-03-15"类格式 - 避免依赖
toISOString()或toJSON()—— 它们对公元前日期返回null或非法字符串 - 后端接收时需明确约定格式（例如统一用带符号年份的 ISO 字符串
"-0044-03-15"，并用支持 BCE 的解析器如 Python 的dateutil处理）
兼容性与验证陷阱
即使你绕过前端限制、用 JS 强行写入负年份字符串，checkValidity() 仍会返回 false，且 :valid/:invalid 伪类样式不可靠。更麻烦的是：
立即学习“前端免费学习笔记（深入）”；
- Chrome/Firefox/Safari 对
min/max属性中的负年份直接忽略（如min="-0050-01-01"无效） -
step属性不支持跨公元/公元前步进 - 移动端弹出的日期选择器完全不显示公元前选项
真正需要处理公元前时间的应用（如历史数据库、考古系统），得从表单结构、序列化协议到后端存储全链路自行定义规则，不能指望 HTML5 原生日期控件兜底。
