嵌套表格合法但高风险，应优先用details替代；若必须使用，须将子table完整置于td或th内，重置border-collapse为separate，并避免width:100%。
嵌套表格只能写在 <td> 或 <code><th> 里
<p>浏览器对 <code><tr> 的子元素有硬性限制：它只接受 <code><td> 和 <code><th>。如果你把 <code><table> 直接写在 <code><tr> 下，浏览器会自动把它“踢”出去——可能塞到父 <code><table> 外面，也可能丢进隐式 <code><tbody>，结果就是 DOM 结构错乱、CSS 选不到、JS 查不到节点。
<p>常见错误现象：</p>
<ul>
<li>子表格显示在主表上方或下方，而不是目标单元格内</li>
<li>
<code>document.querySelector('table.nested') 返回 null
tr > table 写的 CSS 完全不生效正确做法只有一个：把整个子 <table> 完整写进某个 <code><td> 或 <code><th> 的内容区域。必要时先用 <code>colspan 或 rowspan 合并出足够空间，再往里塞。
子表格边框消失？必须重置 border-collapse
父表若用了 border-collapse: collapse（常见于 Bootstrap 或自定义样式），子表默认继承后，边框会被“吃掉”——要么全无，要么粗细加倍。这不是 bug，是 CSS 层叠行为。
立即学习“前端免费学习笔记（深入）”；
必须显式重置子表样式：
- 给子表加
border-collapse: separate（不是inherit） - 避免用
width: 100%，改用max-width: 100%+overflow-x: auto，尤其当父表启用了table-layout: fixed时 - 子表内的
<th> 默认加粗居中，容易和父表冲突，建议统一加类名隔离，比如 <code>.child-table th为什么推荐用
<details></details>替代静态嵌套多数所谓“嵌套需求”，其实是“点击展开详情”。硬塞一个子表进去，既难调样式，又难维护，还影响打印和屏幕阅读器体验。
<details></details>是零 JS 解决方案，语义清晰、无障碍友好：-
<summary></summary>可被读屏软件识别，支持键盘聚焦与空格切换 - 结构扁平，不会污染父表样式或 DOM 层级
- 响应式天然友好，不需要额外重置
table-layout或border-collapse
示例结构：
<td> <details> <summary>展开明细</summary> <table class="nested-table"> <tr><td>A</td><td>B</td></tr> </table> </details> </td>嵌套表格合法但高风险，优先考虑替代方案
<table> 在 <code><td> 里嵌套是 HTML5 合法的，但现代开发中应避免——语义混乱、可访问性差、CSS 控制困难，且与响应式布局天然冲突。 <p>真正能用的子表格必须满足三个条件：视觉可区分、结构可维护、行为可预测。实际项目中：</p> <ul> <li>若需展示“表中表”结构（如订单明细嵌在订单行内），优先用 <code><details></details>+ CSS 折叠，或 JS 动态展开/收起区块 -
- 若只为实现“格子对齐”，而非真正需要表格语义（如数据行列关系、排序、导出），用 CSS Grid 或 Flex 实现更轻量、更易维护
- 仅当需快速兼容老旧 CMS 或邮件模板等受限环境时才考虑嵌套
<table><p>最常被忽略的点是：嵌套表格的字体、行高、内边距会继承父表，导致视觉不一致；必须为子表单独加 class 并重置关键样式，不能依赖 <code>cellspacing/cellpadding（已废弃）。
