不能靠 CSS 选择器自动计算权重，必须用 JS 遍历每行、提取关键词打分后设置 style.opacity；需优先读取 dataset.keyword、避免文本重复计分、用 MutationObserver 响应动态变更，并对得分做对数归一化防过低透明度。
如何用 JavaScript 动态设置 <tr> 的 opacity 基于关键词匹配权重
直接结论：不能靠 CSS 选择器自动“算权重”，必须用 JS 遍历每行，提取文本/属性，按预设关键词表打分，再写入 style.opacity。CSS 本身不支持基于内容的数值计算。
常见错误是试图用 [data-keyword~="urgent"] 这类属性选择器模拟权重——它只能做存在性匹配，无法叠加、归一化或映射到 0.2–1.0 的透明度区间。
- 权重逻辑必须在 JS 中定义：比如
"critical"→ 0.2，"info"→ 0.8，重复出现累加后截断到 [0.1, 1] - 推荐从
<td>文本中提取（而非仅textContent全量），避免匹配到隐藏列或操作按钮里的干扰词 - 若表格启用了客户端分页或虚拟滚动，需在数据重绘后重新运行该逻辑，否则新行 opacity 不更新
querySelectorAll('tbody tr') 遍历时怎么安全读取关键词并防重复计算
关键点在于“提取源”和“去重粒度”。直接对整行 textContent 模糊搜索会导致同一关键词在多个单元格里被反复计分，造成权重虚高。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 遍历每行的
<td>或<th>，用cell.dataset.keyword优先（显式声明比文本解析更准、更快） - 若必须文本匹配，对每个
<td>单独执行cell.textContent.toLowerCase().includes(keyword)，匹配成功即记 1 分，不再向内深挖子元素文本 - 用
Set缓存已处理过的关键词（如防止 “error” 和 “errors” 被当两个词），或统一用词干（stemming）预处理，但简单场景直接用白名单字符串匹配更稳
为什么不要用 rgba() 替代 opacity 控制行视觉强度
表面看 rgba(0,0,0,0.3) 和 opacity: 0.3 效果相似，但行为完全不同：前者只影响文字/边框颜色通道，后者作用于整个 <tr> 及其所有子元素（含背景色、图标、输入框）。
更关键的是继承问题：
-
opacity会向下透传给所有后代元素，若某<td>里有按钮需保持高对比度，就得额外设button { opacity: 1 }补救 -
rgba()只改当前元素颜色，不影响子元素，但无法统一控制整行视觉衰减——比如背景色变淡了，文字却还是纯黑，反而降低可读性 - 性能上，
opacity触发合成层（GPU 加速），而频繁改background-color的 rgba 值可能引发重排
权重归一化时容易忽略的边界情况
把原始得分（如 critical×2 + warning×1 = 3）直接映射到 opacity 0.1–1.0 区间，最常漏掉三类情况：
- 空行或无关键词行：得分 0，但 opacity 设为 0 会让行完全消失，应设下限如
Math.max(0.1, normalized) - 关键词堆叠行（如日志里连续出现 5 次 “timeout”）：线性缩放会压到 0.05 以下，人眼难辨，建议用对数压缩：
0.1 + 0.9 * Math.log10(score + 1) / Math.log10(maxScore + 1) - 动态增删行后未重算：监听
DOMSubtreeModified不可靠，改用MutationObserver监听tbody的childList变更，回调里只重算新增/删除的<tr>，别全量重跑
权重不是越细越好，上线前拿真实数据跑一遍分布直方图，确认 opacity 值集中在 0.3–0.9 区间——太集中说明区分度不足，两极分化严重则说明归一化函数没兜住异常值。
