float+百分比宽度计算基准是父容器content width，width:33.33%仅作用于减去padding/border后的可用宽度；必须配合box-sizing:border-box确保padding/border包含在宽度内，否则易因总宽超100%导致错行。
float + 百分比宽度的计算基准是父容器 content width
浮动元素的 width: 33.33% 不是按父容器总宽（含 padding/border）算，而是严格基于父容器的 content area 宽度。比如父容器设了 padding: 20px，那子元素的 33.33% 就只在减去这 40px 后的剩余宽度里计算。
这意味着：若忽略这点，在带 padding 的容器里直接写 width: 25% × 4，实际总宽大概率 超过 100%，第二行元素就会掉下去——不是代码写错，是盒模型默认行为导致的。
- 父容器
width: 100%且无 padding/border → 子元素width: 25%× 4 刚好填满 - 父容器有
padding: 10px→ 子元素实际可分配 content width 变小，25% × 4 会溢出 - 解决路径只有两个：
box-sizing: border-box（推荐）或手动调低百分比（不推荐，难维护）
必须用 box-sizing: border-box，否则 padding 和 border 会撑破布局
默认 box-sizing: content-box 下，width: 33.33% 只管内容区，padding: 10px 和 border: 1px solid 会额外加在右边，四列加起来轻松突破 100%。
加了 box-sizing: border-box 后，width: 33.33% 就变成“包含 padding + border 的总宽”，这才是你真正想要的等分语义。
立即学习“前端免费学习笔记（深入）”；
- 所有浮动子元素都必须设
box-sizing: border-box，不能只设父容器 - 通配符写法
* { box-sizing: border-box; }最省事，但要注意重置第三方组件样式风险 - 如果用了 rem/em 单位配合 font-size 调整，
box-sizing不影响换算逻辑，仍按最终像素值生效
清除浮动不能只靠 overflow: hidden，要理解它为什么“有效”
overflow: hidden 在父容器上能防止高度塌陷，是因为它创建了新的块级格式化上下文（BFC），强制容器把浮动子元素纳入高度计算。但它不是“清除浮动”的本意，而是一种副作用利用。
真正需要清除的场景是：浮动子元素之后还有非浮动兄弟元素，比如页脚。这时 overflow: hidden 不起作用，必须用 clear: both 或伪元素 clearfix。
- 仅防塌陷 →
overflow: hidden或display: flow-root（现代写法） - 需让后续元素不被浮动干扰 → 必须在后续元素上加
clear: both，或在浮动容器末尾插入::after { content: ""; display: table; clear: both; } -
float元素自身不能设clear，它只对后续兄弟元素生效
三列等分写 33.33% 还是 33.333333%？精度问题真实存在
浏览器对小数位的渲染精度有限，尤其在 IE8–IE11 和部分旧安卓 WebView 中，33.33% × 3 = 99.99%，剩 0.01% 空隙可能引发最后一列换行；而 33.333333% × 3 = 99.999999%，更接近 100%，但也不能完全避免。
这不是 CSS 写法错误，是浮点数精度 + 渲染引擎取整策略共同导致的。现代浏览器基本已优化，但老项目仍需留意。
- 稳妥做法：三列用
width: calc(100% / 3)，浏览器原生支持且精度更高（IE10+） - 兼容极旧环境（IE8）：改用
width: 33%× 3 +width: 34%补最后一列，视觉误差几乎不可见 - 别依赖 JS 动态计算宽度来修复——浮动本身是纯 CSS 布局机制，混入 JS 会破坏可维护性
实际最易被忽略的是：浮动布局中，子元素 margin 无法参与等分计算。它永远是“额外加在 width 外”的，所以等分布局里想留间隙，必须用 padding + background-clip: content-box，或者干脆放弃 float 改用 flex。
