tr:hover 中直接设置 font-weight 可靠，但需避免被内联样式、!important 或父级低字重覆盖；应统一作用于 td/th，优先用 600/700 而非 bold；加粗发虚可加 text-rendering: optimizelegibility；注意 display 改写、移动端 cursor 及 contenteditable 兼容性问题。
font-weight: bold 是实现表格行悬停加粗最直接的方式，但它常被误用或与其他样式冲突，导致效果不生效或文字发虚。
tr:hover 里直接设置 font-weight 是否可靠？
可靠，但前提是目标元素本身没用 font-weight 硬编码覆盖，且没被更具体的 CSS 规则压制。常见干扰来源：
-
td或th上写了font-weight: normal !important - 用了内联样式
style="font-weight: 400"，优先级高于普通选择器 - 父级设置了
font-weight: 300，而bold在某些字体下实际映射为700，可能视觉变化不明显
建议始终用 font-weight: 600 或 700 替代 bold，避免字体解析歧义。
为什么只加粗了部分单元格，而不是整行？
因为 tr:hover 本身不继承字体粗细，真正生效的是它内部的 td 和 th。如果其中某些单元格有独立样式（比如 th 默认加粗、td 没设），就会出现“半行加粗”现象。
解决方法是统一作用到所有单元格：
- 写成
#myTable tr:hover td, #myTable tr:hover th { font-weight: 700; } - 或更简洁地：在
tr:hover后加* { font-weight: 700; }（注意：通配符会影响性能，仅限小表） - 避免对
th单独设font-weight: normal，否则 hover 时会被覆盖
加粗后文字模糊或发虚，怎么调？
这是浏览器渲染 subpixel 字体时的常见副作用，尤其在 macOS 或高 DPI 屏幕上。不是 bug，但影响可读性。
缓解方式有限，但有效：
- 加
text-rendering: optimizeLegibility;到tr:hover或表格容器上 - 避免同时叠加太多 hover 效果（比如加粗 + 背景色 + 边框变色），优先保留加粗 + 轻微背景色
- 确认字体支持粗体字重，例如
font-family: "Helvetica Neue", sans-serif;比"SimSun"更稳定
兼容性与边界情况提醒
tr:hover 在 IE8+ 和所有现代浏览器都支持，但要注意两个真实限制：
- 如果表格用了
display: grid或display: flex改写布局，tr:hover就失效——必须还原为原生<table> 结构<li>移动端 Safari 对 <code>tr:hover的触发依赖于“模拟悬停”，需额外加cursor: pointer才能稳定响应点击前的 hover - 当表格嵌套在
contenteditable="true"区域里，部分浏览器会禁用 hover，此时只能用 JavaScript 监听mouseenter/mouseleave
真正麻烦的不是怎么写，而是你改完之后发现某列数据突然看不清了——那大概率是加粗让原本就紧凑的 padding 压缩了文字间距，得同步调 line-height 或 padding。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
