能，但存在语义错误、可访问性差、移动端点击区域小、SEO不友好等缺陷；必须用包裹或配合tabindex、focus样式、data-href等方案保障可用性。
onclick="window.location.href=..." 能直接写在 上吗？
能，但有明显缺陷：语义错误、可访问性差、移动端点击区域小、SEO 不友好。浏览器允许，不代表该这么做。
常见错误现象是点击后跳转正常，但键盘用户无法用 Tab 键聚焦整行，屏幕阅读器读不出链接意图，onclick 事件也不触发 click 的默认行为（比如右键“在新标签页打开”）。
- 必须确保
<tr> 外层有 <code><tbody> 包裹，否则部分旧版 IE 或 Safari 可能不响应事件
<li>
<code>window.location.href 是同步跳转，会阻塞后续 JS 执行；若需异步（比如带埋点），得用 setTimeout 或 Promise 包裹
- 不要在
onclick 里写 target="_blank" —— window.location.href 本身不支持 target，它只在当前页跳转
想开新标签页跳转，为什么 window.location.href 不行？
因为 window.location.href 是页面级跳转，强制覆盖当前浏览上下文。要新开标签页，得用 window.open()，但要注意弹窗拦截和安全策略。
典型错误写法：onclick="window.location.href='xxx'; target='_blank'" —— 后半句完全无效，HTML 解析器会忽略。
立即学习“前端免费学习笔记（深入）”；
- 正确做法是：
onclick="window.open('https://example.com', '_blank', 'noopener,noreferrer')"
- 必须加
noopener 和 noreferrer，否则新开页可通过 window.opener 控制原页面，存在安全风险
- 移动端 Safari 对
window.open() 拦截更严格，建议 fallback 到 window.location.href + 提示
用 data-href + JavaScript 绑定更可靠吗？
是，这是目前最平衡的方案：语义清晰、可访问性可控、兼容性好、便于扩展逻辑（比如加 loading、统计、权限判断）。
关键不是“能不能”，而是“怎么让 click 事件真正像链接一样工作”。核心是把 data-href 值注入到事件处理中，并模拟原生链接行为。
- 给
<tr> 加 <code>data-href="/detail?id=123"，再用 JS 绑定 click 事件
- 在事件处理器里用
event.target.tagName === 'TR' 过滤，避免 <td> 内部元素误触发
<li>按需决定是否调用 <code>event.preventDefault()：如果同时支持键盘 Enter 和空格键，就得阻止默认行为并手动跳转
- 为支持键盘导航，需加
tabindex="0" 到 <tr>，否则 Tab 键跳不过去
<h3>为什么 CSS cursor:pointer 和 focus 样式容易被忽略？</h3>
<p>因为很多人只加了 <code>.tr-link:hover { cursor: pointer; }，却没处理键盘聚焦态，导致可访问性测试失败。
真实场景下，用户可能用键盘操作（尤其残障人士或笔记本无鼠用户），没视觉反馈就等于功能不可见。
- 必须配对写：
.tr-link:focus { outline: 2px solid #007bff; outline-offset: 2px; }
- 不要用
outline: none 粗暴移除焦点框，除非你提供了等效的视觉替代样式
- 移动端点击高亮（iOS Safari 的灰色背景）可通过
-webkit-tap-highlight-color: transparent; 关闭，但别影响 focus 样式
整行跳转看着简单，实际卡点全在细节：语义是否合规、键盘是否可用、新窗口是否安全、移动端是否生效。最容易被忽略的是 tabindex 和 focus 样式 —— 它们不报错，但一测可访问性就暴露问题。
能，但有明显缺陷：语义错误、可访问性差、移动端点击区域小、SEO 不友好。浏览器允许，不代表该这么做。
常见错误现象是点击后跳转正常，但键盘用户无法用 Tab 键聚焦整行，屏幕阅读器读不出链接意图，onclick 事件也不触发 click 的默认行为（比如右键“在新标签页打开”）。
- 必须确保
<tr> 外层有 <code><tbody> 包裹，否则部分旧版 IE 或 Safari 可能不响应事件 <li> <code>window.location.href是同步跳转，会阻塞后续 JS 执行；若需异步（比如带埋点），得用setTimeout或 Promise 包裹 - 不要在
onclick里写target="_blank"——window.location.href本身不支持 target，它只在当前页跳转 - 正确做法是：
onclick="window.open('https://example.com', '_blank', 'noopener,noreferrer')" - 必须加
noopener和noreferrer，否则新开页可通过window.opener控制原页面，存在安全风险 - 移动端 Safari 对
window.open()拦截更严格，建议 fallback 到window.location.href+ 提示 - 给
<tr> 加 <code>data-href="/detail?id=123"，再用 JS 绑定click事件 - 在事件处理器里用
event.target.tagName === 'TR'过滤，避免<td> 内部元素误触发 <li>按需决定是否调用 <code>event.preventDefault()：如果同时支持键盘 Enter 和空格键，就得阻止默认行为并手动跳转 - 为支持键盘导航，需加
tabindex="0"到<tr>，否则 Tab 键跳不过去 <h3>为什么 CSS cursor:pointer 和 focus 样式容易被忽略？</h3> <p>因为很多人只加了 <code>.tr-link:hover { cursor: pointer; }，却没处理键盘聚焦态，导致可访问性测试失败。真实场景下，用户可能用键盘操作（尤其残障人士或笔记本无鼠用户），没视觉反馈就等于功能不可见。
- 必须配对写：
.tr-link:focus { outline: 2px solid #007bff; outline-offset: 2px; } - 不要用
outline: none粗暴移除焦点框，除非你提供了等效的视觉替代样式 - 移动端点击高亮（iOS Safari 的灰色背景）可通过
-webkit-tap-highlight-color: transparent;关闭，但别影响 focus 样式
tabindex和focus样式 —— 它们不报错，但一测可访问性就暴露问题。 - 必须配对写：
想开新标签页跳转，为什么 window.location.href 不行？
因为 window.location.href 是页面级跳转，强制覆盖当前浏览上下文。要新开标签页，得用 window.open()，但要注意弹窗拦截和安全策略。
典型错误写法：onclick="window.location.href='xxx'; target='_blank'" —— 后半句完全无效，HTML 解析器会忽略。
立即学习“前端免费学习笔记（深入）”；
用 data-href + JavaScript 绑定更可靠吗？
是，这是目前最平衡的方案：语义清晰、可访问性可控、兼容性好、便于扩展逻辑（比如加 loading、统计、权限判断）。
关键不是“能不能”，而是“怎么让 click 事件真正像链接一样工作”。核心是把 data-href 值注入到事件处理中，并模拟原生链接行为。
