transform: rotate()仅视觉旋转，不改变盒模型尺寸和文档流，导致文字倾斜但列宽不变。它不触发重排，th仍按原始宽高占位，需配合display: inline-block、固定width、white-space: nowrap及transform-origin手动调控。
直接对用transform: rotate()为什么文字歪了但列宽不变？
因为rotate只改变视觉渲染，不触发重排（reflow），<th>的盒模型尺寸、内容流位置、继承的<code>width或white-space行为全都不变。结果就是：文字转了90°，但列还按原来水平布局的宽度撑开，留出大片空白或挤压相邻列。
必须配合显式尺寸控制和显示类型修正：
<th>设<code>display: inline-block或block，否则transform在内联元素上可能被忽略或行为异常
- 手动设
width（推荐固定像素值，如width: 28px），避免依赖内容宽度自动计算
- 加
white-space: nowrap防换行，再用transform-origin: center确保旋转锚点居中
- 若需顶部对齐，补
vertical-align: top，否则inline-block默认基线对齐会下沉
倾斜表头后内容挤在一起或错位怎么办？
典型现象是多个垂直表头紧贴排列、文字重叠，或底部悬空——这基本都是height和line-height没协同导致的。旋转后的文字高度不再是原始line-height，而是其对角线长度，浏览器不会自动适配。
可靠解法是脱离行高依赖，用padding+固定高控形：
- 清空
line-height，设height: 120px（根据旋转后视觉高度预估）
- 用
padding-top: 10px + padding-bottom: 10px替代line-height做垂直居中
- 如果文字仍偏上/偏下，在
transform-origin后追加偏移，例如transform-origin: 50% 40%
- 避免对
<tr>整体设<code>height，它会强制压缩所有<th>，覆盖单个旋转容器的尺寸
<h3>skewX()和rotate()在表头倾斜里哪个更实用？</h3>
<p><code>rotate()适合真·垂直或固定角度（如-90°、270°），语义明确、兼容性好；skewX()适合模拟手写斜体或轻微倾角（如-6deg），但容易拉伸文字、破坏字间距，且不同字号下倾斜感不一致。
选型关键看目标效果：
- 要“竖排文字”：无条件用
transform: rotate(-90deg)，别碰skew
- 要“标题微微右倾”增强动感：用
skewX(-4deg)，但必须同步设font-kerning: auto保字距
- 想兼容IE10及以下：
rotate()需加-ms-transform前缀，skewX()在IE中支持更差
- 注意
skewX()会让文字左右边缘变尖，高DPI屏下易发虚，rotate()抗锯齿更稳
为什么给table加transform没反应，但包一层div就灵了？
因为<table>是表格渲染上下文根节点，浏览器对其应用<code>transform时会强制隔离布局，内部<th>/<code><td>仍按标准表格算法重排，抵消掉外部变形。这不是bug，是规范行为。
<p>绕过限制只有一条路：打破表格上下文</p>
<ul>
<li>必须用<code><div style="transform: rotate(-90deg)"><table>...</table></div>包裹
- 外层
div需设display: inline-block或display: block，否则transform不生效
- 如果表格有
border-collapse: collapse，倾斜后边框大概率断裂——此时应改用border-collapse: separate + border-spacing: 0
- 别试图用
will-change: transform或backface-visibility: hidden强行激活，它们对表格上下文无效
实际中最容易被忽略的是：旋转后的<th>虽然视觉上竖起来了，但它在DOM流中仍是水平方向的块，所以<code>text-align依然控制左右，vertical-align才管上下。这点一旦混淆，调试会陷入死循环。
因为rotate只改变视觉渲染，不触发重排（reflow），<th>的盒模型尺寸、内容流位置、继承的<code>width或white-space行为全都不变。结果就是：文字转了90°，但列还按原来水平布局的宽度撑开，留出大片空白或挤压相邻列。
必须配合显式尺寸控制和显示类型修正：
<th>设<code>display: inline-block或block，否则transform在内联元素上可能被忽略或行为异常- 手动设
width（推荐固定像素值，如width: 28px），避免依赖内容宽度自动计算 - 加
white-space: nowrap防换行，再用transform-origin: center确保旋转锚点居中 - 若需顶部对齐，补
vertical-align: top，否则inline-block默认基线对齐会下沉 - 清空
line-height，设height: 120px（根据旋转后视觉高度预估） - 用
padding-top: 10px+padding-bottom: 10px替代line-height做垂直居中 - 如果文字仍偏上/偏下，在
transform-origin后追加偏移，例如transform-origin: 50% 40% - 避免对
<tr>整体设<code>height，它会强制压缩所有<th>，覆盖单个旋转容器的尺寸 <h3>skewX()和rotate()在表头倾斜里哪个更实用？</h3> <p><code>rotate()适合真·垂直或固定角度（如-90°、270°），语义明确、兼容性好；skewX()适合模拟手写斜体或轻微倾角（如-6deg），但容易拉伸文字、破坏字间距，且不同字号下倾斜感不一致。选型关键看目标效果：
- 要“竖排文字”：无条件用
transform: rotate(-90deg)，别碰skew - 要“标题微微右倾”增强动感：用
skewX(-4deg)，但必须同步设font-kerning: auto保字距 - 想兼容IE10及以下：
rotate()需加-ms-transform前缀，skewX()在IE中支持更差 - 注意
skewX()会让文字左右边缘变尖，高DPI屏下易发虚，rotate()抗锯齿更稳
为什么给table加transform没反应，但包一层div就灵了？
因为
<table>是表格渲染上下文根节点，浏览器对其应用<code>transform时会强制隔离布局，内部<th>/<code><td>仍按标准表格算法重排，抵消掉外部变形。这不是bug，是规范行为。 <p>绕过限制只有一条路：打破表格上下文</p> <ul> <li>必须用<code><div style="transform: rotate(-90deg)"><table>...</table></div>包裹 - 要“竖排文字”：无条件用
- 外层
div需设display: inline-block或display: block，否则transform不生效 - 如果表格有
border-collapse: collapse，倾斜后边框大概率断裂——此时应改用border-collapse: separate+border-spacing: 0 - 别试图用
will-change: transform或backface-visibility: hidden强行激活，它们对表格上下文无效
倾斜表头后内容挤在一起或错位怎么办？
典型现象是多个垂直表头紧贴排列、文字重叠，或底部悬空——这基本都是height和line-height没协同导致的。旋转后的文字高度不再是原始line-height，而是其对角线长度，浏览器不会自动适配。
可靠解法是脱离行高依赖，用padding+固定高控形：
<th>虽然视觉上竖起来了，但它在DOM流中仍是水平方向的块，所以<code>text-align依然控制左右，vertical-align才管上下。这点一旦混淆，调试会陷入死循环。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
