table-layout: fixed 是唯一能让列宽真正可控的前提，不加它，所有 width 设置都只是“建议”；浏览器默认 table-layout: auto，列宽由整列最宽内容决定，td width="200" 仅作初始提示且易被撑开，同时 width 属性只影响首行、百分比基于表格总宽计算，而 colgroup+col 才是最可靠精确的列宽控制方式。
table-layout: fixed 是唯一能让列宽真正可控的前提，不加它，所有 width 设置都只是“建议”。
为什么 td width="200" 经常不生效
浏览器默认用 table-layout: auto，此时列宽由整列中最宽内容（比如长 URL、连续无空格文本）决定。td width="200" 只是初始渲染时的提示，后续会被撑开。更隐蔽的问题是：width 是 HTML 属性，若同时写了 CSS width，后者会覆盖前者；但即使只写 CSS，没设 table-layout: fixed，它依然不强制生效。
另外，td 的 width 只影响首行对应列的宽度计算，后续行不继承；百分比值（如 width="30%"）是相对于整个表格宽度，不是父容器，容易误判实际占位。
用 <colgroup></colgroup> + <col> 精确控制每列宽度
这是目前最可靠、语义最清晰的方式，尤其适合固定某列像素宽、其余列自适应的场景。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
<colgroup></colgroup>必须紧跟<table> 开始标签后，且在 <code><thead> 或第一行 <code><tr> 之前 <li>每个 <code><col>按顺序对应一列；缺位则该列回退为自动计算 -
<col width="120">：设置固定像素宽度，HTML 属性，兼容性好 -
<col style="width: 25%">：百分比基于表格总宽度计算，不是父容器 -
<col style="width: 1fr">：仅 Chromium/Firefox 支持，Safari 不认，生产环境慎用 - 保持
table-layout: auto - 给单元格加
word-break: break-word和white-space: normal - 用
overflow-x: auto包裹表格容器，让横向滚动成为兜底方案 - 若某列需最小宽度防压缩，额外加
min-width到<td> 或 <code><th> 上，并确保父 <code><table> 有明确宽度（如 <code>width: 100%）别把
<table> 当页面布局工具用 <p><code><table> 的语义是结构化数据展示，不是页面整体布局。用它塞导航栏、侧边栏、页脚，会直接破坏屏幕阅读器解析逻辑——读屏软件会逐行列出“首页 首页 首页”，而不是按语义朗读导航项。 <p>现代 CSS（Flexbox/Grid）已能干净替代所有老式表格布局需求。真要在某个 <code><td> 内组织局部内容（比如按钮组、带标题的描述块），可以，但必须： <ul><li>把子结构完整写进 <code><td> 开闭标签之间，不能放在 <code><tr> 下层 <li>避免在 <code><td> 里再套 <code><table> ——除非你明确需要二维数据呈现（如价格对比表） <li>若真要用子表，务必重置 <code>border-collapse: separate，否则父表的 collapse 会让子表边框异常
注意：用了 table-layout: fixed 后，<td> 上的 <code>width 属性会被跳过，只读取 <col> 或首行 <th>/</th>
<td> 的显式宽度。
<h3>响应式场景下怎么避免列宽锁死</h3>
<p>硬编码像素值（如 <code>width="150"）在移动端会破坏自适应能力；百分比相加不等于 100% 时，浏览器行为不可预测；1fr 虽直观但 Safari 不支持。
真正稳妥的做法是：
复杂点在于：一旦你开始想用 colspan “挪动格子”或靠 position: relative 微调对齐，说明已经超出表格能力边界，该换 Flexbox 或 Grid 了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
