在 layui table 的 templet 函数中，用 return d.value > 100 ? '' + layui.util.escape(d.value) + '' : layui.util.escape(d.value); 实现条件加粗，注意数值类型转换与 html 转义。
layui table 的 templet 中怎么根据数值条件加粗文本
直接在列配置的 templet 函数里用条件判断包裹内容，返回带 <strong></strong> 的 HTML 字符串即可。Layui 表格渲染时会自动解析该字符串，不需要额外开启任何开关。
常见错误是写成纯文本拼接（比如 "<strong>" + d.value + "</strong>"）但没注意引号嵌套导致语法报错；或者用了 return d.value > 100 ? "<strong>" + d.value + "</strong>" : d.value 却忘了对原始值做转义，导致 XSS 风险或标签被当作文本显示。
- 必须用单引号包裹 HTML 标签，内部用双引号写属性（如
'<strong style="color:red;">' + d.value + '</strong>'），避免引号冲突 - 若原始值含 HTML 特殊字符（如
、<code>&），先用layui.util.escape(d.value)转义再包裹<strong></strong> - 不要在
templet里调用layui.jquery或操作 DOM，表格渲染阶段 DOM 尚未挂载完成
为什么不能用 style 直接写 font-weight: bold
可以写，但没必要绕开 <strong></strong>。Layui 对 templet 返回的字符串是原样插入 innerHTML 的，所以 '<span style="font-weight:bold;">' + d.value + '</span>' 同样生效。但用 <strong></strong> 更轻量、语义正确，且不依赖 CSS 类或样式表加载顺序。
容易踩的坑是误以为要改全局 CSS（比如给 .layui-table-cell 加 font-weight），结果整列都变粗了——这是无效的，因为列样式无法感知单元格数据逻辑。
-
<strong></strong>是最简方案，无兼容性问题，Layui 2.x / 3.x 均支持 - 如果项目已统一用 class 控制强调样式（如
class="text-em"），那就在templet里返回'<span class="text-em">' + d.value + '</span>'，并确保对应 CSS 已加载 - 避免在
templet中写内联style大段颜色/尺寸，维护成本高且易和主题色冲突
数值比较时要注意类型转换和空值
Layui 表格的 d 数据对象里字段值可能是字符串（尤其从后端 JSON 直接传入时），直接用 d.score > 80 可能因字符串比较出错（如 "100" 返回 true）。
典型现象：明明数值大，却没加粗；或者所有值都加粗/都不加粗，调试发现 typeof d.score === "string"。
- 统一转数字：用
Number(d.score) > 80或parseFloat(d.score) > 80，前者对空字符串返回 0，后者返回 NaN - 兜底处理空值：
const val = Number(d.score) || 0，再比较 - 如果字段可能为
null或undefined，先判空再转数字，否则Number(null) === 0可能掩盖真实问题
性能影响小，但别在 templet 里做复杂计算
单次加粗判断（一次数值转换 + 一次比较 + 一次字符串拼接）几乎无性能损耗，即使上千行表格也感知不到卡顿。真正拖慢的是在 templet 里调接口、查数组、递归处理或格式化时间等操作。
容易被忽略的是：同一列多个条件分支（比如按区间分五档加粗+变色），如果每个分支都重复调用 Number() 或正则匹配，累积起来也会轻微影响首屏渲染速度。
- 把转换和判断逻辑提到外层变量里（如
const score = Number(d.score) || 0），后续只读取score - 避免在
templet中调用自定义函数（除非该函数极轻量且已定义在全局作用域） - 如果加粗规则未来可能变，建议抽成独立函数，但别让它成为
templet的闭包依赖
templet 里碰 DOM、别忽略字符串转数字、别让空值悄悄变成 0。其它都是枝节。
