用<tr>做导航栏违反语义且不可访问，应使用<nav><ul><li>结构配合CSS实现横向排列，否则会导致屏幕阅读器误读、SEO识别困难、键盘导航混乱及WCAG合规失败。
用 <tr> 做导航栏违反语义且不可访问
直接把导航链接塞进 <tr> 里，看似能横向排开，但这是错的。HTML 表格元素（<table>、<tr>、<td>）只该用于展示二维数据，比如价格表、课程安排。用它做导航，屏幕阅读器会读成“表格，1行，3列”，用户完全不知道这是菜单；搜索引擎也难识别导航意图；键盘 Tab 流也会因表格结构变得混乱。
真正该用的标签是 <nav> + <ul> + <li>
语义正确、默认可访问、样式控制更直接。横向排列靠 CSS，不是靠表格行：
<nav>
<ul>
<li><a href="/home">首页</a></li>
<li><a href="/about">关于</a></li>
<li><a href="/contact">联系</a></li>
</ul>
</nav>
配合简单 CSS 即可水平排列：
-
ul设display: flex或list-style: none+display: inline-block -
a加text-decoration: none和适当 padding - 别忘了给
nav加role="navigation"（虽现代浏览器自动补，但稳妥起见）
如果硬要用 <tr>（不推荐，但 legacy 代码可能遇到）
那至少得补救可访问性，否则等于埋雷：
立即学习“前端免费学习笔记（深入）”；
- 必须给外层
<table>加role="navigation"和aria-label="主导航" - 每个
<td>里的链接要加tabindex="0"（否则部分旧浏览器不聚焦） - 移除所有
border、cellspacing、cellpadding，否则视觉干扰严重 - 响应式会非常痛苦：表格在小屏下必然换行错乱，而
flex可直接用flex-wrap或媒体查询降级为垂直菜单
<tr> 导航在真实项目中会触发哪些具体问题
不是“不好看”那么简单，而是实际卡点：
- WCAG 2.1 会判为
Failure of Success Criterion 1.3.1（信息关系未以编程方式表达） - Lighthouse 的 “Accessibility” 分数直接扣分，尤其 “List items are contained in
<ul>or<ol>” 这条 - React/Vue 等框架里，用
<tr>渲染动态菜单时，key 容易错配（<tr>不是合法的<ul>子元素，React 会警告） - 某些无障碍工具（如 JAWS）跳过表格内部链接，或把整个导航读成单个“表格对象”
语义不是教条，是浏览器、辅助技术和开发者之间的契约。用 <tr> 做导航，相当于寄快递不写地址只画个格子——东西可能到，但谁也说不清怎么到的，出问题也没法追责。
