父元素的padding看似失效实为高度塌陷所致，因浮动子元素脱离文档流，父容器无法正确计算高度；需通过BFC（如overflow:hidden、clearfix或flow-root）解决塌陷，padding方能正常生效。
父元素的 padding 看似没生效，其实不是失效了，而是被浮动子元素“绕开”了——因为浮动元素已脱离文档流，不再参与父容器的内边距撑开逻辑。
为什么 padding-bottom / padding-right 看起来没用
浮动子元素会脱离普通文档流，但仍在页面中占据物理空间。父容器计算自身尺寸时，只考虑普通流中的内容（文字、非浮动块等），padding 本身是作用于容器“内部边界”的，而浮动子元素根本不“触碰”这个边界——它们像浮在半空的纸片，既不顶 padding-top，也不压 padding-bottom，更不挤 padding-right（尤其当右浮动时）。
-
padding-top和padding-left通常还能看到效果，因为浮动元素从左上角开始布局，初始位置仍受其约束 -
padding-bottom几乎完全不可见：浮动子元素不会向下“拉伸”父容器，父容器高度塌陷后，padding-bottom就悬在了空白里 -
padding-right在右浮动场景下易被误判：若只有一个右浮动块，它紧贴父容器右边缘，padding-right像被忽略；其实是它没东西可推，自然不体现
真正要解决的是高度塌陷，不是 padding 本身
所有“padding 失效”的表象，根源都是父容器高度塌陷。只要父容器能正确包裹浮动子项，padding 就会自然起作用。关键不是加 padding，而是让父容器“看见”子项。
- 优先用
overflow: hidden或overflow: auto给父容器——简单、兼容 IE6+，且不增加 DOM 节点 - 若父容器本身需内容溢出（如下拉菜单、tooltip），禁用
overflow: hidden，改用伪元素清除：.clearfix::after { content: ""; display: table; clear: both; } -
display: flow-root是现代标准解法（Chrome 64+/Firefox 58+），但 IE 完全不支持，上线前必须查项目兼容矩阵 - 别给父容器设固定
height：它无法响应子项内容变化，一加就成硬编码陷阱
margin 与 padding 混用时的典型错觉
很多人试图用子元素的 margin-bottom 代替父容器的 padding-bottom，结果发现没效果——这是因浮动子元素的垂直 margin 不会触发父容器重绘高度，且可能和兄弟元素发生折叠。
立即学习“前端免费学习笔记（深入）”；
- 浮动子元素的
margin-bottom只影响下一个浮动兄弟的顶部位置，对非浮动后续元素或父容器高度无实质贡献 - 若在浮动子元素后加一个
clear: both的空div，它的margin-top可能会和前面浮动块的margin-bottom折叠，反而导致间距不准 - 想控制底部留白，最稳方式是：确保父容器已通过 BFC 正常撑高，然后直接设
padding-bottom——它不会折叠、不依赖渲染顺序、语义清晰
真正容易被忽略的点是：padding 是否生效，永远取决于父容器有没有正确高度；而高度是否正确，又取决于你选的清除方式会不会意外裁剪内容、是否兼容目标环境、以及是否和现有滚动/定位逻辑冲突。别只盯着 padding 写多少，先确认父容器的 computed height 是不是你预期的值。
