Layui表头全选未过滤禁用行导致状态错乱，需手动接管点击事件并仅操作非禁用行，同时重算indeterminate状态以准确反映可用行选中比例。
为什么点表头全选会把禁用行也“算进去”
layui 的 table.checkstatus() 在计算全选状态时，压根不看 lay_disabled: true 的行是否该被跳过——它只遍历当前页缓存（table.cache['your-id']），对每条数据粗暴赋值 item.lay_checked = checked，完全没做 if (!item.lay_disabled) 判断。这就导致两个问题：
• 取消全选时，禁用行的 lay_checked 字段仍为 true，下次再点全选框，它看起来“没变化”；
• 表头复选框的 indeterminate 状态错乱，因为统计勾选数时没排除禁用行。
接管表头点击事件并手动过滤禁用行
必须放弃默认全选逻辑，在 done 回调里重绑表头 checkbox 的 click 事件，并显式跳过 LAY_DISABLED: true 的数据：
- 用
$('thead input[lay-type="all"]')精准定位表头全选框，别用 class（类名易变） - 在
event.preventDefault()后，遍历table.cache['your-id']，只对!item.LAY_DISABLED的项设item.LAY_CHECKED = checked - 手动触发
table.render()或调用table.reload()刷新视图（否则 DOM checkbox 不同步） - 别直接操作
$('tbody input[type="checkbox"]')，Layui 内部状态和 DOM 不一致会导致checkStatus()返回错误结果
如何让半选状态（indeterminate）准确反映可用行选中比例
表头 checkbox 的 indeterminate 是靠 JS 控制的，Layui 原生逻辑没考虑禁用行。你需要自己算：
- 先过滤出所有可用行：
const validRows = table.cache['your-id'].filter(item => !item.LAY_DISABLED) - 再统计其中已勾选数：
const checkedValid = validRows.filter(item => item.LAY_CHECKED).length - 最后设置：
headCheckbox.prop('indeterminate', checkedValid > 0 && checkedValid - 注意：这个逻辑要放在每次 checkbox 状态变更后（包括单行勾选、全选、取消全选），否则视觉和实际状态脱节
服务端分页下无法真正“全选所有页”的硬限制
如果表格配置了 url（服务端分页），浏览器本地只有当前页数据，table.cache['your-id'] 就是当前页那几十条——你再怎么过滤，也拿不到第 2 页的禁用行 ID。这时所谓“排除禁用行”，仅限于当前页。
- 真要跨页全选 + 排除禁用行，必须让后端返回全量数据 ID 列表（带
LAY_DISABLED标记），前端缓存起来再操作 - 或者改用前端分页（
data直传数组），前提是数据量可控（一般 ≤ 5000 条） - 千万别在服务端分页场景下，幻想用 JS 遍历“所有页”来维护选中状态——那需要翻页请求 N 次，用户体验崩坏
LAY_DISABLED 的支持停留在渲染禁用样式层面，全选/半选/状态同步这些关键路径都没适配它。想让它真正可用，就得在每一处涉及勾选逻辑的地方手动补漏，尤其是 indeterminate 计算和跨页场景下的数据边界。 
