templet函数中d参数即为后端返回的原始行数据对象，未被扁平化或受前端操作影响；需用可选链（如d.user?.info?.name）安全取值，禁止修改d属性以免污染数据。
templet函数里d参数就是原始行数据
你不需要额外查找或转换，templet 回调函数的第一个参数 d 就是当前行的原始 json 对象（即后端返回的那条记录），原封不动、未被扁平化、也未受前端排序/过滤影响。
常见错误现象：在 templet 里写 d.user.info.name 报错 Cannot read property 'info' of undefined —— 这不是因为 d 不对，而是 d.user 本身为 null 或 undefined。
- 用可选链安全取值：
d.user?.info?.name || '-' - 别在
templet里改d的属性（比如d.name = d.user?.info?.name），这会污染原始数据，影响后续排序、导出、table.cache等行为 - 如果列定义中
field是name，但你想在templet里显示d.user.info.name，那就没问题；但若你还想点击表头按这个字段排序，field必须对应一个真实存在的键名（不能是表达式），否则排序失效
为什么不能直接用 field="user.info.name"
Layui 表格的 field 只支持一级属性名，不解析点号路径。它内部用的是 obj[field] 方式取值，obj["user.info.name"] 显然不存在。
使用场景：单列展示嵌套值、且不需要排序/筛选/导出该字段时，templet 是最轻量的解法；但一旦涉及多列、或需要服务端分页兼容，就得靠 parseData 预处理整个数据集。
-
templet中可以访问完整行对象，包括未在cols中定义的字段（比如d.extraConfig?.timeout） - 不要在
templet里发起fetch或调用复杂函数，渲染会被阻塞，滚动卡顿明显 - 若需动态拼接 HTML（如带 class 的 badge），记得用
return返回字符串，别漏掉return
templet 和 table.cache 数据不一致怎么办
table.cache['id'] 存的是经过 parseData 处理后的数据（或前端分页切片后的子集），而 templet 拿到的 d 是原始响应里的那一项 —— 两者来源不同，天然可能不一致。
容易踩的坑：你在 parseData 里把 item.user.info.name 提取为 name，又在 templet 里还去读 d.user.info.name，结果发现有的行是 undefined，有的能读到 —— 这说明后端返回结构不统一（比如部分数据 user 字段缺失）。
- 统一取值逻辑：要么全走
parseData扁平化 +field直接绑定，要么全在templet里用可选链安全读取 - 调试时打印
console.log(d)，确认结构是否和后端文档一致，别依赖“应该有” - 若用了前端分页（
data参数传数组），templet的d仍来自该数组，不是table.cache
templet 中需要异步加载关联数据怎么处理
不能。Layui 渲染是同步的，templet 必须立刻返回字符串。如果你在里头写 await fetch(...)，只会得到 [object Promise]。
替代方案只有两个：
- 提前在
parseData或初始data加载阶段，把关联数据 prefetch 好，合并进每行（例如加个userInfo字段） - 用事件委托：给单元格加
data-id，点击后再查详情，用layer.open展示，而不是在表格里实时渲染
真正容易被忽略的是：哪怕只是加个 tooltip 弹出完整描述，也别在 templet 里写 title 属性硬塞长文本 —— 渲染大量行时 DOM 属性膨胀会导致内存占用陡增，滑动变卡。
