禁用行数据通过LAY_DISABLED字段识别，而非DOM属性；该字段需写入缓存数据对象，同步控制UI禁用与逻辑排除，否则checkStatus等操作会误判。
禁用行数据怎么识别：靠 LAY_DISABLED 字段，不是 DOM 属性
layui 表格内部用 lay_disabled: true 标记某行复选框是否被禁用，这个字段写在缓存数据对象上，不是靠 input[disabled] 的 dom 状态判断。即使你用 templet 渲染了 disabled 属性，若原始数据没设 lay_disabled，table.checkstatus() 或全选逻辑仍可能误判。
实操建议：
- 后端返回数据时，直接加
"LAY_DISABLED": true字段（如{id: 1, name: "张三", status: "closed", LAY_DISABLED: true}） - 前端动态禁用时，别只改模板，必须同步更新缓存：
table.cache['yourTableId'][rowIndex].LAY_DISABLED = true - reload 后
LAY_DISABLED会丢失 —— 它不随接口响应自动带入，得在done回调里手动补上
怎么拿到所有禁用行数据：查 table.cache + 过滤 LAY_DISABLED
table.cache['yourTableId'] 是当前页完整原始数据数组（含所有字段），也是唯一能稳定拿到禁用行真实数据的地方。table.getData() 只返回可见行，且不保留 LAY_DISABLED；DOM 遍历更不可靠，因为禁用行的 checkbox 可能压根没渲染出来。
示例代码：
const cache = table.cache['userTable'] || []; const disabledRows = cache.filter(row => row.LAY_DISABLED === true); console.log(disabledRows); // 所有被禁用的行数据
注意点：
- 确保表格 render 时写了
id: 'userTable'，否则table.cache['userTable']是undefined - 如果用了服务端分页，
cache里只有当前页数据 —— 要跨页禁用统计，得让后端在分页接口里也返回LAY_DISABLED字段 - 别用
$(...).find('input[disabled]')去找，templet 渲染的 input 可能被 layui 隐藏或重写，DOM 不可信
禁用行和选中状态混在一起时，怎么避免漏过滤
禁用行虽然不能勾选，但它的 LAY_CHECKED 字段可能为 true（比如全选后又禁用某行，状态未清理）。这时候直接用 table.checkStatus().data 拿到的“已勾选”数据里，可能混着本该被排除的禁用行。
安全做法是：先取全量缓存，再同时按两个条件过滤：
const cache = table.cache['userTable'] || []; const validChecked = cache.filter(row => row.LAY_CHECKED === true && row.LAY_DISABLED !== true );
常见坑：
- 监听
checkbox(filter)事件时，在回调里直接读obj.data，它只是当前这一行，不反映全局禁用约束 - 调用
table.checkStatus()前没确认表格已完成渲染（比如在done外调用），cache可能为空 - CSS 遮盖了禁用视觉反馈（比如
opacity: 0），导致你以为没禁用，其实数据早被LAY_DISABLED锁死了
为什么不能只依赖模板里的 disabled 属性
templet 里写 {{# if(d.status === "closed"){ }} disabled {{# } }} 只控制 UI 层面是否可点，不影响 layui 内部状态管理。表头全选、checkStatus、导出、甚至 radio 切换都绕不开 LAY_DISABLED 字段。模板禁用只是“障眼法”，没这字段，用户用键盘空格键、或 JS 脚本仍可能触发勾选。
关键结论：
-
LAY_DISABLED是唯一被 layui 表格核心逻辑识别的禁用标识 - 模板
disabled和LAY_DISABLED必须同步 —— 前者保 UI，后者保逻辑 - 所有后续操作（统计、导出、提交）前，都得自己显式过滤掉
LAY_DISABLED: true的行，layui 不会帮你跳过
禁用行数据本身不难拿，真正容易翻车的是：以为 DOM 上看着禁用了，就等于逻辑上被排除了。Layui 的状态管理是双轨制，UI 层和数据层得各自管好，又得对齐。
