结论：表格布局（<table>）用于纯数据展示合理，但用作页面骨架必须重构；判断标准是看是否嵌套非表格元素、滥用colspan/rowspan或被JS动态操作；替换方案依兼容性、响应式需求和类名复用选择Flex/Grid，需手动补全对齐、列宽及事件绑定。
直接说结论：表格布局（<table>）不是“错”，但用它做页面骨架，等于把语义、样式、结构全焊死在一起——改一个像素，可能崩掉整个导航栏。重构不是为了炫技，而是让后续改需求、加响应式、接入屏幕阅读器不再像拆炸弹。
怎么判断该不该动 <table> 布局
别一上来就删 <table>。先看它干了什么：
- 如果
<table>里塞的是纯数据（如商品价格表、订单列表），保留它，加<thead>/<tbody>和scope属性就行 - 如果
<table>里嵌了<div>、<form>、甚至整个<nav>，这就是“布局型表格”，必须动 - 检查有没有
colspan/rowspan用来对齐按钮或占位，这是典型信号 - 打开 DevTools → Elements 面板，右键某个
<td>→ “Break on > attribute modification”，点一下页面任意交互，如果它被 JS 动态改 class 或 innerHTML，说明这个表格已被当 DOM 操作靶子用，风险极高
<table> 布局替换成什么，取决于你真正在意什么
别默认选 display: grid。选错方案，重构后反而更难维护：
- 要快速收口、兼容 IE11？用
display: flex+flex-direction: column套一层<header>/<main>，比 Grid 兼容性好，也更容易和旧 CSS 对接 - 要精确控制行列间距、响应式断点切换行列顺序？用
display: grid，但别写grid-template-areas—— 容易和 JS 动态插入内容冲突，优先用grid-template-columns+minmax() - 要保留旧 CSS 类名不改？给新容器加 class 如
layout-grid，然后在 CSS 里写.layout-grid { display: grid; ... }，避免全局污染 - 千万别用
float替换 —— 你刚修好塌陷，下周就有人加个clear: both把整个侧边栏推到页脚下面
重构时最容易被忽略的三件事
很多团队改完发现“样式全乱了”，问题不在 Grid 写错，而在没处理这三处：
立即学习“前端免费学习笔记（深入）”；
-
<table>默认有border-collapse: collapse和vertical-align: middle，Grid/Flex 没这默认行为，得手动补align-items: center或重置vertical-align - 旧代码常靠
<td>的width属性（如width="200"）撑开列宽，Grid 里得对应写grid-template-columns: 200px 1fr，不能只写1fr 1fr就完事 - 所有
<tr>上的onclick或class="highlight-row"，必须提前迁移到新容器的<div>或<section>上，否则 JS 绑定失效，且找不到对应元素
最麻烦的从来不是怎么写新代码，而是旧逻辑藏在哪——比如某个 <td> 的 style="padding-left: 30px" 其实是为避开左侧菜单留的空隙，删掉它，整个右侧内容就贴边了。重构前花 20 分钟画出各区块依赖关系，比写 2 小时代码更重要。
