正确做法是 min: "2026-09-04" 或 min: new Date().toISOString().slice(0,10)，避免时区歧义和格式不兼容；range 模式需双框均设 min 并用 reload 动态同步，且须前端校验+后端兜底。
min 配字符串，别配 new Date()
直接写 min: new Date() 会出问题——它带时分秒（比如 2026-09-04T14:24:30），laydate 解析时按本地时区转 UTC 再比对，结果下午设的限制，可能晚上就禁掉今天了。更糟的是，type: 'datetime' 下还会把秒级精度带进去，可选窗口被压缩到几小时内。
正确做法是强制截断到日：min: "2026-09-04"。它会被解析为当日 00:00:00，安全、稳定、无时区歧义。
- 动态生成推荐：
min: new Date().toISOString().slice(0,10)（兼容性好，不手动算月份+1） - 绝对不要用：
min: new Date().toLocaleDateString()（IE 格式不统一，可能是9/4/2026） - 如果后端返回日期字符串，确保格式也是
yyyy-MM-dd，否则 laydate 不认
range 模式下两个输入框都要设 min
只给开始时间框设 min: "2026-09-04"，结束时间框默认仍可选昨天——laydate 不自动校验「结束 ≥ 开始 ≥ 今天」这个链式关系。
必须显式控制两个入口：
- 初始化时，两个
elem都要单独调laydate.render()，且都配min: "2026-09-04" - 若要求「结束不能早于开始」，监听第一个框的
done事件，拿到所选日期后，调第二个实例的reload({ min: selectedStart }) - 注意：v2.8.0+ 才支持
reload()；老版本得先ins.destroy()再重 render，但会丢焦点和已填值
手动输入仍能绕过限制？得加前端校验
min 只约束面板选择，不限制 input 框手动输入。用户敲 2026-09-01，laydate 不拦。
业务强要求时，必须补两层防护：
- 在
done回调里检查value是否早于今天，早于则清空或提示 - 监听
change事件做实时校验（记得加防抖，避免每输一个字符都触发） - 后端必须二次校验——前端限制只是体验优化，不可信
真正容易被忽略的点
时区 + 字符串格式 + reload 三者必须同时对齐。哪怕你用 toISOString().slice(0,10) 算对了今天，漏掉一次 reload，或者在 IE 里用了 toLocaleDateString() 导致格式变成 9/4/2026，整个限制就失效了。
