margin-top/bottom百分比按父元素宽度而非高度计算，是为了避免因高度依赖导致的布局死循环；padding-top/bottom同理，但可配合position实现宽高比容器。
margin-top/bottom 百分比为什么不是按父元素高度算
因为会触发布局死循环。比如一个 div 的 height 未显式设置，靠内容撑开；此时若它的 margin-top: 10% 按父元素 height 计算，而父元素高度又依赖这个子元素的总高度（含 margin），那 margin 变大 → 子元素总高变大 → 父元素 height 变大 → margin 再次变大……无限递归。宽度没这问题：块级元素默认宽度占满父容器，内容超宽会换行，不会反向推高父宽。
padding-top/bottom 同样按父宽度计算，但能用来做等比缩放
这个特性常被用于实现「宽高比固定」的容器，比如视频占位、响应式正方形。关键点在于：padding-top 或 padding-bottom 的百分比值作用在垂直方向，但数值来源仍是父元素宽度，所以可以稳定产出与宽度成比例的垂直留白。
- 例如：
.aspect-ratio { width: 100%; padding-top: 56.25%; /* 16:9 */ position: relative; }，再用position: absolute把内容塞进去 - 注意：必须配合
height: 0或position: relative避免 padding 撑高容器本身（否则会叠加） - 这种技巧不依赖 JS，纯 CSS，但只适用于「内部内容需绝对定位」的场景
想让 margin/padding 百分比按高度算？试试 writing-mode
这不是 hack，是 CSS 规范明确支持的行为。把父容器设为 writing-mode: vertical-lr 或 vertical-rl，此时书写流变为竖排，margin-top/bottom 就自动改按父元素 height 计算了——因为“上下”在竖排中变成了“左右”方向，而百分比始终匹配当前主轴尺寸。
- 副作用明显：块级元素默认水平排列变成垂直堆叠；
margin垂直合并（collapse）也会转移到水平方向 - 需要重调整个布局逻辑，比如原本用
flex-direction: row的地方，可能得切到column并配合text-orientation - 移动端兼容性没问题（Chrome/Firefox/Safari/Edge 均支持），但别在复杂表单或文字流密集区域贸然使用
现代替代方案：优先用 vh/vw 而非百分比
如果目标只是「让 margin/padding 随视口变化」，vh 和 vw 更直接、无歧义。比如 margin-top: 5vh 就是视口高度的 5%，和父元素尺寸完全解耦。
立即学习“前端免费学习笔记（深入）”；
-
vh/vw不受嵌套层级影响，也不怕父元素height: auto - 要注意 iOS Safari 中
vh在地址栏收起/展开时可能不重绘，可用min-height: 100dvh+height: 100dvh组合缓解 - 百分比适合「相对父容器流式缩放」，
vh/vw适合「相对屏幕锚定尺寸」，选哪个取决于你的响应逻辑源头在哪
实际项目里最容易忽略的是：百分比 margin/padding 的「参照对象」永远是包含块（containing block）的宽度，而不是你肉眼看到的最近那个父 div 的宽度——如果父元素是 position: absolute，那包含块可能是更上层的定位祖先，甚至根元素。调试时用浏览器开发者工具的「Layout」面板看「Containing Block」提示，比猜更可靠。
