border-box 是从 IE6 的怪异模式里翻回来的，它默认不继承——你抄了十年的全局重置，只写对了一半

先说结论：box-sizing: border-box 救过无数人的布局，但有两个细节几乎没人讲清楚——它是从 IE 的「怪异模式」里翻案回来的历史妥协；而且它默认不继承，你抄来的那一行全局重置，大概率只对了一半。

content-box 的默认行为：width 不是你以为的宽度

CSS 标准里 box-sizing 的初始值和默认值都是 content-box。你写的 width: 200px 指的是内容区 200px，padding 和 border 是在外面额外加上的：

.card {
  width: 200px;
  padding: 20px;
  border: 5px solid black;
}
/* content-box（默认）：实际渲染宽度 = 200 + 20*2 + 5*2 = 250px */
/* border-box：实际渲染宽度 = 200px，内容区被压缩到 150px */

MDN 的例子更直白：.box { width: 350px; border: 10px solid black; } 在 content-box 下渲染出 370px，在 border-box 下渲染出 350px，内容区只剩 330px。

两列布局是最经典的翻车现场：

.container { width: 400px; display: flex; }
.item {
  width: 50%;          /* 200px */
  padding: 10px;       /* 左右再各加 10px */
}
/* 每个 item 实际占 220px，两列 440px > 400px，第二个必然掉行 */

它其实是 IE6 的遗产，当年还被骂过

CSS-Tricks 在《Box Sizing》里把这段历史写得很清楚：在 content-box 之外，早期 IE（<= IE6）在 quirks mode 下的盒模型是 width = 元素的可见/渲染宽度——padding 和 border 被塞进 width 里面，从宽高里扣，而不是往外撑。这就是当年大家嘲笑的「怪异盒模型」。

后来 W3C 把这套计算方式正式收编成 box-sizing: border-box（CSS3 UI 规范）。也就是说：今天你在项目里全局写下的那一行，用的是被嫌弃了十几年的 IE 行为——历史赢了工程直觉。CSS-Tricks 甚至为此搞了个「International Box-Sizing Awareness Day」，可见这件事在当年有多痛。

第一个坑：它默认不继承，你的全局重置可能是抄错的

这是最隐蔽的一条。box-sizing 的继承行为是：规定上不继承（not inherited）。也就是说下面这种写法，只对元素自身生效，对后代无效：

/* ❌ 只写了 *，很多人以为万事大吉 */
* { box-sizing: border-box; }
/* 问题：* 选不到伪元素，::before / ::after 仍然是 content-box */

而你在各种「最佳实践」文章里看到的标准写法，其实是两层：

/* ✅ 官方推荐写法（MDN / CSS-Tricks 一致） */
html {
  box-sizing: border-box;
}
*, *::before, *::after {
  box-sizing: inherit;   /* 关键在 inherit，不是在 border-box */
}

注意这里的细节：html 上设值，然后所有元素（含伪元素）都写 inherit。这样做的好处是可撤销——某个第三方组件、某个 1:1 复刻的设计稿区块需要 content-box 时，你只要在那个子树根节点写一句 box-sizing: content-box，整棵子树就跟着切回去，不用 !important 硬怼。

而项目里最常见的 bug 恰恰是漏了继承链：

/* 只在业务根节点设，第三方组件挂在 body 下 */
.app { box-sizing: border-box; }
.app * , .app *::before, .app *::after { box-sizing: inherit; }

/* 某个自定义元素 <my-widget> 内部渲染在 shadow DOM / 或挂在 body 下 */
/* 结果：组件内部全走 content-box，宽度集体多出 padding */

排查这类问题别靠眼睛，直接开 DevTools 选中元素看 Computed 面板——盒模型可视化的那几层会直接告诉你它现在算的是哪个模型。

第二个坑：border-box 解决宽度，但解决不了百分比高度

这是 border-box 被过度神化的地方。它让 width 变得可预测，但对 height 的百分比没救。

Stack Overflow 上有个经典问题：父元素 height: 500px; padding: 20px; border: 50px（含 border-box 声明），子元素 height: 100%，结果子元素根本没有 500px 高。原因在于：百分比高度是相对「包含块」计算的，而包含块是父元素的内容边界（content edge），不是它的 border-box 边界。

.parent {
  box-sizing: border-box;
  height: 500px;
  padding: 20px;
  border: 50px solid blue;
}
.parent .child {
  height: 100%;   /* = 父元素 content 区高度 360px，不是 500px */
}

border-box 只改变「你声明的 height 从哪里算」，不会让子元素的百分比基准跟着变大。所以子元素想要撑满父元素，正确做法是绕开百分比：

/* 更稳的写法 */
.parent { display: flex; }
.child { flex: 1; }          /* 或 align-self: stretch */

/* 或者 grid */
.parent { display: grid; }
.child { grid-row: 1 / -1; }

另外，CSS 新增的 height: stretch 就是冲着这个坑去的——它按包含块拉伸，margin 会被考虑，且 box-sizing 取什么值都不影响，不会因为 padding/border 多出溢出。不过目前支持还很窄（主要在 Chrome 系），可以当渐进增强用。

第三个坑：Grid / flex 里 border-box 救不了 min-content

minmax(0, 1fr) 这个写法现在很常见，但很多人只是背下来了，不知道它和盒模型的关系。

Grid 轨道的默认 min-width: auto，意味着轨道至少要有内容的 min-content 宽度。一个不换行的长 URL、一串长订单号，就能把 1fr 的列顶宽，布局直接崩。这时候你加 box-sizing: border-box 是没用的——border-box 解决的是「我声明的宽度包含哪些部分」，minmax(0, 1fr) 解决的是「这个轨道最小能到多小」，两个问题正交。

/* 防御式写法 */
.grid {
  display: grid;
  grid-template-columns: minmax(0, 1fr) minmax(0, 1fr);
  gap: 16px;              /* gap 是刚性占位，先从可用空间里扣掉 */
}

还有两个同源细节值得记一下：fr 分配的是「扣除固定值之后的剩余空间」，所以 gap 越多、固定像素列越多，1fr 拿到的就越少；容器宽度是小数时（比如 799.5px）浏览器舍入后两列可能差 1px，看起来「不等宽」。这些都不是 border-box 能管的。

该怎么做：一份能直接抄的落地清单

1. 重置用官方版：html { box-sizing: border-box } + *, *::before, *::after { box-sizing: inherit }，别只写 *，也别用 !important。
2. 需要 content-box 的子树显式切回：在子树根节点写 box-sizing: content-box，配合上面的 inherit 一次性生效。
3. 高度别赌百分比：撑满用 flex/grid，或用 height: stretch 做渐进增强；min-height: 100dvh 比 height: 100vh 在移动端靠谱。
4. 宽度别赌 calc：两列等宽用 grid-template-columns: minmax(0, 1fr) minmax(0, 1fr)，不用 width: calc(50% - 20px) 手动减。
5. 排查先看 Computed：DevTools 的盒模型图会直接告诉你当前元素算的是 content-box 还是 border-box，比读代码快十倍。
6. 移动端多一层警惕：老版本 Android WebView 对 border-box 有历史 bug，关键容器该显式声明就显式声明；跨端场景也别盲目信全局重置——viewport 与容器查询单位（cqw/cqh）配合时，尺寸基准完全不同。

说到底，box-sizing: border-box 不是魔法，它只是把「加法模型」换成了「减法模型」。真正的可预测性来自三件事：继承链写对、百分比别乱赌、Grid 轨道显式给下限。这三件做齐了，你的布局才会从「改一个 padding 崩一片」变成真正可控。