box-sizing: content-box 是浏览器默认值，width 仅指内容区宽度，边框和内边距额外增加；border-box 则使 width 包含内容、内边距和边框，内容区自动收缩。
box-sizing: border-box 和 content-box 的宽度到底算谁的
默认情况下，width 只管内容区，边框和内边距是额外加上的。比如设 width: 200px; padding: 10px; border: 2px solid #000;，最终元素占位是 224px —— 这就是 box-sizing: content-box（浏览器默认值）的逻辑。
改成 box-sizing: border-box 后，width 就变成“总宽”，内边距和边框往里挤，内容区自动收缩。这是现代布局最常用的模式，尤其在栅格、卡片、表单控件中。
- 全局重置推荐写法：
* { box-sizing: border-box; }，但注意它会影响所有元素，包括button、input等原生控件的默认渲染，某些旧版 iOS Safari 对textarea的box-sizing支持不一致 - 不要只在容器上设
border-box而漏掉子元素，否则父子尺寸计算会错位，常见于 flex 项或 grid item 内部嵌套 -
box-sizing不继承，必须显式设置或靠通配符覆盖
width: 100% 在不同父容器下的实际表现差异
width: 100% 不是“填满屏幕”，而是“填满包含块（containing block）的内容区宽度”。这个“包含块”是谁，直接决定结果：
- 普通块级父容器（如
div）：取父元素content box宽度，不含父的padding和border - 定位元素（
position: absolute）：包含块是最近的「已定位祖先」的padding box，即含 padding 不含 border - 表格单元格（
td）：width: 100%可能被表格算法忽略，优先服从table-layout和列宽约束 - Flex 项目：如果父容器是
display: flex，width: 100%默认无效（flex 用flex-basis主导），除非显式设flex: none或flex-shrink: 0
calc() 里混用百分比和像素时的盒模型陷阱
calc(100% - 20px) 看似安全，但它的 100% 是基于包含块的 content width 计算的 —— 如果父元素有 padding，而子元素又用了 box-sizing: border-box，这个减法就可能让内容区窄过预期，甚至触发横向滚动。
立即学习“前端免费学习笔记（深入）”；
- 典型翻车场景：侧边栏固定宽 + 主内容区
width: calc(100% - 240px)，但父容器有padding: 20px，导致主内容实际可用宽度少于预期 - 更稳的写法是把 padding 移到更外层容器，或改用
margin隔离，避免在calc()中和padding交叉影响 - 注意
calc()不支持em或rem与百分比混合单位相加减（会报语法错误），只能同类型运算
min-width / max-width 与 box-sizing 的协作边界
min-width 和 box-sizing 控制后的那个宽），不是内容区宽。这点容易误解。
- 当
box-sizing: border-box且width: 200px; padding: 20px;时，min-width: 180px仍会生效 —— 因为 200px 已经是总宽，180px 小于它，不会触发收缩；但若内容撑大到 220px，min-width: 180px就不起作用了 -
max-width在响应式中常配合width: 100%使用，但它限制的是最终渲染宽度，不受父元素padding影响，所以不会“意外截断”内边距 - 慎用
min-width: 100%：它会让元素至少和包含块一样宽，但在 flex 或 grid 中可能破坏弹性行为，尤其当父容器本身宽度不固定时
盒模型的尺寸分配不是线性叠加，而是多层嵌套的“解释权”争夺 —— 哪个属性先占位、哪个后裁剪、哪个阶段读取父容器尺寸，这些时机差一点，视觉就差一截。调样式时盯着 computed style 里的 “width”、“border-box width”、“content-box width” 三项对比看，比猜快得多。
