全局配置 parseData 必须用 table.set()，它是在首次 table.render() 前统一设置 response 字段映射的唯一方式，支持 statusName、msgName、countName、dataName 四字段名适配，但无法处理类型转换或嵌套结构，复杂场景仍需单表 parseData 兜底。
全局配置 parseData 必须用 table.set()，不是每个 render 里重复写
layui.table 没有“全局默认 parsedata”的配置入口，但 2.8+ 提供了 table.set() 方法，它是唯一能统一影响所有后续 table.render() 行为的途径。不走这步，每个表格都得手写一遍 parsedata，字段一变全得改。
关键点：table.set() 必须在首次 table.render() 之前调用，且只生效于之后新建的表格实例；已渲染的表格不受影响。
- 必须显式传入
response对象，不能只改parseData -
response里四个字段名固定：statusName（对应 code）、msgName（对应 msg）、countName（对应 count）、dataName（对应 data） - 字段值填的是后端实际返回的键名，比如后端用
success表状态，就设statusName: 'success' - 如果后端结构太复杂（如
result.data.list），response无法处理，仍需单表写parseData函数兜底
示例：
layui.use('table', function(){
var table = layui.table;
// 全局适配后端返回 { ok: true, message: '', total: 100, rows: [...] }
table.set({
response: {
statusName: 'ok', // 把 ok 当作 code，true → 0，false → 1
msgName: 'message', // 消息字段
countName: 'total', // 总数字段
dataName: 'rows' // 列表字段
}
});
// 后续所有 table.render() 都自动按这个规则解析，无需再写 parseData
});
response 字段映射和 parseData 函数是两层逻辑，别混用
response 只做字段名映射，不做类型转换或结构扁平化。parseData 才是真正执行数据清洗的地方。当 response 映射完，Layui 内部仍会把结果喂给 parseData —— 此时若你没定义 parseData，它就用内置默认函数；若你定义了，它就会调用你的函数。
-
response无法把字符串"100"转成数字，也无法把null替换成空数组 - 只要后端返回的
count是字符串、data是null或嵌套过深，就必须补parseData做兜底 - 全局
table.set()后，单表仍可覆盖：parseData: function(res){ return { code: 0, count: +res.total, data: res.rows || [] }; } - 注意：2.8+ 对
count类型校验更严，字符串会导致分页按钮全部禁用，这里+res.total就很必要
跨项目复用时，response 配置容易被忽略的坑
团队协作中，table.set() 很容易被漏掉或错放位置，导致部分页面表格空白——尤其在多入口、多 JS 文件的后台系统里。
- 不要放在某个页面的局部
layui.use里，应统一收口到公共初始化脚本（如common.js或layui-init.js） - 避免和
layui.config()混用，二者无关系；layui.config()控制模块路径，不影响 table 行为 - 上线前务必检查控制台是否有
Uncaught TypeError: Cannot read property 'length' of undefined—— 这大概率是response.dataName指错了字段，或parseData没返回data数组 - 移动端 Safari 下，如果
parseData里写了未屏蔽的console.log，偶发卡死，建议用环境变量控制调试输出
真要“完全统一”，得配合后端约定，前端只能减负不能替代
最省事的方案从来不是前端拼命适配，而是推动后端统一响应规范。哪怕只是加一层薄包装，也比每个前端项目写十几种 parseData 更可持续。
- 建议约定最小响应结构：
{ code: number, msg: string, count: number, data: array }，其他字段放extra或meta里 - 如果后端坚持用
pagination.total这类嵌套结构，前端response无能为力，必须每个表格单独写parseData -
table.set()的response是“强约定弱实现”，它假设后端字段名一致；一旦出现同字段不同含义（比如code在用户接口是 200/400，在文件接口是 0/1），还是得退回到单表parseData
真正麻烦的不是怎么配，而是字段命名在不同接口、不同团队、不同年代的代码里反复不一致。统一配置只是把混乱延迟暴露，而不是消除混乱。
