表格高亮失效源于DOM更新后highlight类未同步迁移，应采用局部更新、MutationObserver监听、独立高亮逻辑及动态增删class来确保状态与数据一致。
表格数据更新后高亮失效，是因为没重触发样式逻辑
DOM 更新后，之前加的 highlight 类不会自动消失或迁移——它只属于被操作过的旧节点。如果用 innerHTML 或 outerHTML 替换整行，原 highlight 类就丢了；如果用 document.createElement 重建行，新节点默认不带任何类。这不是 CSS 失效，是节点生命周期断了。
- 避免直接覆写
table.innerHTML，改用row.replaceChild(newCell, oldCell)或row.cells[i].textContent = newValue局部更新 - 若必须整表重绘（如从 API 拉新数据），渲染完立即调用高亮函数，比如
applyHighlight(table, targetValue) - 不要在渲染前预设 class，比如
<td class="highlight">...</td>—— 这会让高亮“固化”，后续值变但样式不撤
用 MutationObserver 监听表格内容变化并自动高亮
手动调用高亮函数容易漏场景（比如分页、搜索、排序后），MutationObserver 是更健壮的选择。它能捕获 characterData 和 childList 变化，比轮询高效，也比事件委托更底层。
- 只观察
tbody或具体td节点，避免监听整个table导致冗余触发 - 回调中用
mutation.target.textContent判断是否匹配目标值，再向上找最近的tr加highlight类 - 注意过滤掉
table初始化时的首次变化（可加 flag 或检查mutation.type === 'characterData'） - 记得在页面卸载前调用
observer.disconnect()，否则内存泄漏
高亮逻辑和原始数据脱钩，才能应对动态变化
很多实现把高亮条件硬编码进渲染层，比如 PHP 模板里写 <?php echo $val > 100 ? 'style="background:red"' : '' ?>。这导致前端 JS 修改值后，背景色不会同步更新——因为 DOM 上没有状态标记，只有静态内联样式。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 统一用 class 控制样式：
td.above-threshold，CSS 定义.above-threshold { background: #ffebee; } - 高亮判断逻辑抽成独立函数，例如
shouldHighlight(cellValue, threshold) { return cellValue > threshold; }，所有地方复用 - 给
td加data-value属性存原始数值（如<td data-value="127">127.5</td>），避免因格式化（千分位、小数位）导致字符串比对失败 - 阈值别写死在 JS 里，从
table.dataset.threshold或全局配置对象读取，方便后端注入或运行时调整
表格含分页/虚拟滚动时，高亮容易只作用于当前页
分页切换或滚动加载新行后，新插入的 tr 节点不在初始高亮范围内。常见错误是只对 document.querySelectorAll('table tr') 批量处理一次，后续新增行完全被忽略。
立即学习“前端免费学习笔记（深入）”；
- 每次新行插入后，单独对这批
tr调用高亮函数，而不是全量重扫 - 如果用
IntersectionObserver做懒加载，可在callback中触发高亮，确保仅处理可视区域内的行 - 避免用
querySelectorAll('tr').forEach(...)在事件回调里反复执行——DOM 查询开销大，尤其表格行多时 - 考虑缓存高亮状态：用
WeakMap存cell → isHighlighted映射，比反复计算更轻量
高亮不是一次性贴纸，而是随数据呼吸的活状态。最容易被忽略的是：当值变回正常范围时，有没有主动移除高亮类？ 很多人只写“加”，不写“删”，结果异常恢复后红底还在。
