box-sizing: border-box 是组件库可维护性的底线，不设它会导致尺寸封装失控、响应式错位、跨团队协作掉血；必须全局启用 , ::before, *::after { box-sizing: border-box; } 并禁止单个组件覆盖，同时严格分离 padding（内部留白）与 margin（外部间距），border 预留透明占位以保障状态切换尺寸稳定。
直接上结论：box-sizing: border-box 是组件库可维护性的底线，不设它，后续所有尺寸封装、响应式适配、跨团队协作都会在暗处持续掉血。
为什么必须全局启用 box-sizing: border-box
现代组件库里，按钮、卡片、输入框这些基础元素几乎都依赖固定宽高 + 内边距的组合。如果沿用默认的 content-box，一个 width: 100% 的按钮加上 padding: 12px 和 border: 1px，实际宽度就超出了父容器——这种“写对了却渲染错”的问题，在调试时根本看不出样式表哪里写错了，只能靠经验盲猜。
更麻烦的是，不同组件作者可能各自加 box-sizing，有的写在组件内部，有的漏掉，有的只写 *::before 忘了 *::after，结果同一个项目里出现两种盒模型混用。最终表现就是：同一套间距规则，在 A 组件里刚好，在 B 组件里挤出滚动条。
所以工程上最省力的做法是：
立即学习“前端免费学习笔记（深入）”；
- 在 CSS 入口文件最顶部，加一行
*, *::before, *::after { box-sizing: border-box; } - 绝不允许单个组件再覆盖这个设置（除非有极特殊需求，且必须加注释说明）
- CI 流程里加 lint 规则，禁止出现
box-sizing: content-box
padding 和 margin 的职责必须物理隔离
组件内部留白用 padding，组件之间留白用 margin——这不是风格偏好，是避免外边距合并（margin collapse）和布局不可预测的硬约束。
比如一个 .card 组件，它的内边距控制标题、内容、底部操作区之间的距离；而两个 .card 并排时的间隙，必须由它们的父容器用 gap 或者给每个 card 设 margin-right 来控制，不能让 card 自己用 margin-bottom 去“推”下一个 card。
常见错误现象：
- 列表项用了
margin-bottom，但最后一项多出多余空白 - Flex 容器里子项用
margin-right实现间距，换到 Grid 布局后失效 - 组件被嵌套进另一个组件后，
margin被父容器的 BFC 截断或合并，视觉间距消失
解决办法很简单：组件自身只管内部结构（padding + border），外部组合交由布局容器（gap、margin 或 Grid/Flex 属性）统一调度。
如何用 border 做轻量级状态反馈而不破坏尺寸
很多组件需要在 focus、error、hover 等状态下加边框强调，但如果默认没预留空间，临时加 border: 2px solid red 就会导致元素突然变宽、触发重排、文字抖动。
正确做法是在组件基础样式里就预留 “视觉边界槽”：
- 用
border: 2px solid transparent占位，保持尺寸稳定 - 状态切换时只改
border-color，不改宽度或样式 - 如果要用虚线/双线等非实线，提前测好对应
border-width，确保所有状态下的总宽度一致
示例：
.input {
padding: 8px 12px;
border: 2px solid transparent; /* 预留空间 */
box-sizing: border-box;
}
.input:focus {
border-color: #007bff;
}
.input.error {
border-color: #dc3545;
}这样无论怎么切状态，.input 的 width/height 都不会变，也不用额外写 JS 去监听尺寸变化。
真正难的不是写对某一个组件，而是让所有组件在任意嵌套层级、任意布局上下文里，尺寸行为都可预期。这要求你从第一行 CSS 就放弃“凭感觉调 margin”，转而建立 box-sizing 为锚点、padding/margin 为分工、border 为状态信道的三层契约——否则组件库越做越大，越容易在某个深夜因为一个按钮多出 2px 而集体失眠。
