先说几个关键点，关于Layui的laydate组件中disabledDate这个函数，其实逻辑很清晰，但细节上容易踩坑——尤其是那些刚接触前端日历组件的朋友，经常会在周末禁用这个需求上栽跟头。
disabledDate 里用 getDay() 判断是否为工作日
禁用周一到周五以外的日期，本质就是只允许 date.getDay() 返回值为 1～5 的日期。注意，JavaScript 里 getDay() 返回 0 表示周日，1 是周一，5 是周五，6 是周六——千万别把 0 和 6 当成工作日来用，否则禁用逻辑会完全失效。
但这里有一个非常容易忽略的前提：必须加空值判断。否则，当laydate初始化时传入null或undefined，整个函数会直接中断，日历面板压根打不开。所以，代码里一定要有这一行：
if (!date) return false;—— 这行是护身符，不能少，否则日期组件会崩溃。- 记住，返回
true表示禁用，false或undefined才是可用状态。 - 最直接的做法就是
return date.getDay() === 0 || date.getDay() === 6;，这样就能精准禁掉周末，干净利落，且性能最优。
为什么不能用字符串匹配（如 includes('Mon')）
有人可能会想，把 date 转成字符串再查星期几，比如 date.toString().includes('Mon')，或者自己拼个 date.getFullYear() + '-' + (date.getMonth()+1) + '-' + date.getDate()。看起来很聪明，但实际上问题不少：
- 不同浏览器或时区下，
toString()的格式可能不一致，在中文环境中includes('Mon')根本匹配不到，因为它返回的是'星期一'，直接失效，导致周末禁用功能完全失效。 - 手动拼日期字符串时，很容易漏掉补零——比如月份是9，你写成了
'9'而不是'09'，结果'2026-7-1'和'2026-07-01'对不上，导致判断逻辑出错，而且这种错误很难排查。 - 更关键的是性能问题。
disabledDate这个函数每渲染一个日期格子就会执行一次，几百次调用下来，每次都要做字符串操作，卡顿就是这么来的，尤其是在移动端或低配设备上更容易出现。
min/max 和 disabledDate 能否一起用
当然可以，而且这其实是实战中非常常见的组合方式。先用 min 和 max 锁死一个大范围，比如“只能选未来30天”；再用 disabledDate 在这个范围内做精细过滤，比如“只允许选择工作日”。这样可以实现既限制日期范围、又过滤特定星期几的效果。
不过，有两个细节需要注意：
min和max必须传字符串格式，比如"2026-07-02"。如果传new Date()，会带上时分秒信息，导致当天下午之后的时间点被意外截断，出现日期选择异常。disabledDate函数在min和max之外的日期上依然会被调用，但那些日期本身已经是不可见的，所以逻辑里不需要额外判断是否超出范围，专注规则本身即可，避免增加不必要的复杂度。
禁用逻辑写错会导致所有日期不可选
这是最隐蔽的坑。很多人写代码时，只记得在周末条件里返回 true，却忘了最后加一个兜底的 return false。比如下面这种写法：
disabledDate: function(date) {
if (!date) return false;
if (date.getDay() === 0 || date.getDay() === 6) {
return true;
}
// ❌ 缺少 else 或最终 return，其余日期也默认返回 undefined → laydate 当作 true 处理
}
结果就是，除了周末，其他日期也全变灰色了，因为 undefined 被Laydate解读为 true（禁用）。正确的写法必须明确收尾：
- 所有禁用条件都走
return true。 - 所有非禁用情况，统一走
return false，不能漏，也不能靠隐式返回，否则会导致日期选择器所有日期都不可选。 - 如果多个规则叠加（比如既要排除周末，又要排除法定节假日），用
||连接条件，最后仍然要确保有一个return false，这样逻辑才完整可靠。
这个 return false 看似简单，却是实际项目里debug半天才发现的问题根源。同事往往会在代码里找半天，最后发现只是少写了一行，所以务必养成习惯，在所有条件分支后显式返回。
