原生 input[type="date"] 不支持范围选择，必须用两个独立控件 + JS 联动 + 后端校验三者结合；JS 需监听 change 事件动态同步 min/max，后端必须二次校验格式、逻辑及时区。
原生 input[type="date"] 不支持范围选择，必须用两个独立控件 + JS 联动 + 后端校验，三者缺一不可。光靠 min/max 属性或单个事件监听，一定会漏掉手动输入、粘贴、时区偏移等边界情况。
用两个 input[type="date"] 实现起止日期结构
这是唯一兼容主流浏览器、无障碍友好、语义清晰的方案。不要尝试用 type="daterange"（不存在），也不要改用 type="text" + 自研日历——成本高、可访问性差、移动端体验断裂。
-
name必须明确区分：起始用name="start_date"，结束用name="end_date"，后端才能正确解析 - 起始控件建议加
required，结束控件不加——业务上允许“仅查某天起”的场景很常见 - 起始控件可设
min为当前日期（2026-10-26），但别设max；结束控件初始不设min，等 JS 动态注入 - 两个控件都应放在同一个
<form></form>内，方便后续用FormData统一采集
JS 动态同步 min/max 防止逻辑冲突
原生控件不会自动响应值变化。用户改了开始日期，结束日期的日历仍能选旧值；反之亦然。必须用事件监听强制对齐。
- 监听
start_date的change事件，把它的value赋给end_date.min - 监听
end_date的change事件，检查end_date.value ，若成立则清空或报错（不能只设 <code>start_date.max，那会锁死起始框） - 注意：
min/max只影响日历可选范围和浏览器基础校验，无法阻止用户粘贴2026-13-01这类非法字符串 - 示例片段：
const start = document.querySelector('input[name="start_date"]');
const end = document.querySelector('input[name="end_date"]');
start.addEventListener('change', () => {
if (start.value) end.min = start.value;
});
end.addEventListener('change', () => {
if (end.value && start.value && end.value < start.value) {
alert('结束日期不能早于开始日期');
end.value = '';
}
});
与多条件筛选共存时的 FormData 处理要点
日期范围只是筛选条件之一，常和品牌、分类、价格区间等并存。所有条件必须走同一套采集逻辑，否则状态不同步、URL 无法还原、分页失效。
立即学习“前端免费学习笔记（深入）”；
- 整个筛选区必须包裹在单个
<form></form>中，所有字段（含日期）用标准name，如name="brand"、name="price_min" - 读取时统一用
new FormData(form)，它会自动跳过未选中的 checkbox、合并同名值、忽略 disabled 控件 - 日期字段为空时，
FormData.entries()不会包含该 key，所以后端需按缺失字段处理（如“不限日期范围”） - 不要手动拼对象：
{ start_date: start.value, end_date: end.value }—— 这样一旦加个动态条件（如搜索框 debounce），就容易漏掉或覆盖
后端必须二次校验日期格式与逻辑
前端限制可被完全绕过：禁用 JS、修改 DOM、curl 直接发请求。任何生产环境都必须在服务端做两件事：
- 验证字符串是否符合
YYYY-MM-DD格式且是真实日期（如2026-02-30是非法的） - 验证
end_date >= start_date，且都在业务允许的时间窗口内（例如只接受未来 90 天内的预约） - 注意时区：前端
toISOString().split('T')[0]返回的是 UTC 时间，若业务按本地时间判断，后端需转换时区再比对
最容易被忽略的是：用户可能在 Chrome 开发者工具里直接改 end_date.min 属性，让日历显示可选范围变宽，但 JS 事件监听没触发，导致 min 值滞后。这种情况下，仅靠前端联动根本兜不住，非得靠后端兜底。
