<p>优先用box-sizing: border-box让width包含padding，使calc(100% - 20px)真正代表总宽减留白；若必须content-box，则将padding移至子元素，避免在padding自身用calc反向补偿。</p>
calc() 里怎么处理 padding 导致的宽度溢出？
直接在 width 上写 calc(100% - 20px) 很容易失效——因为 padding 不属于 content-box 的计算范围，而默认盒模型是 content-box。这时候你减掉的 20px 实际上没抵消 padding 占用的空间，容器依然会撑破父级。
真正要解决的不是“怎么算”，而是“在哪一层面算”。关键在于：让 calc() 的结果作用于 content 区域，同时把 padding 留给盒模型自己消化。
- 优先用
box-sizing: border-box—— 这样width就包含 padding 和 border，calc(100% - 20px)才真正代表“总宽减去固定留白” - 如果必须保持
content-box（比如第三方组件限制），就把 padding 挪到子元素上，父容器只用calc()控制 content 宽度 - 避免在
padding自身用calc()去“反向补偿”，这会让层级和继承变得不可控
calc() 中混用单位时为什么总是报错？
常见错误是写成 calc(100% - 1rem + 2px) —— 看似合理，但 CSS 解析器要求加减运算中**所有值必须可归一化为同一维度**，而 % 是相对单位、px 和 rem 是绝对/根相对单位，它们不能直接相加减。
正确做法是确保参与运算的项类型一致：
立即学习“前端免费学习笔记（深入）”；
-
%只跟%运算：calc(100% - 10%) - 绝对单位之间运算：
calc(200px - 16px)或calc(2rem - 0.5rem) - 想混用？必须用
vw/vh替代 % 做基准，比如calc(100vw - 32px)（前提是父容器宽度等于视口）
flex 或 grid 布局下 calc() 宽度还生效吗？
生效，但容易被忽略约束条件：当父容器是 display: flex 且子项未设置 flex-shrink: 0 时，即使你写了 width: calc(100% - 40px)，浏览器仍可能为了填满剩余空间而拉伸它——calc() 只设初始 width，不阻止 flex 的弹性行为。
实操要点：
- 加
flex-shrink: 0锁定尺寸，防止被压缩 - 用
min-width替代width更稳妥，比如min-width: calc(100% - 40px)，避免内容撑开时失守 - grid 中若列定义用了
fr单位，calc()对width几乎无效，应改用grid-template-columns: calc(100% - 40px) 40px
移动端适配时 calc() 的坑在哪？
最常踩的是 viewport 缩放导致 % 基准漂移。比如 iPhone Safari 在双击放大后，100% 不再等于视口宽度，calc(100% - 20px) 就会突然变小或溢出。
应对策略很实际：
- 用
100vw替代100%，它始终锚定视口宽度，不受缩放影响 - 避免在
padding或margin里用calc()配合%，尤其不要写padding-left: calc(5% + 10px)—— 移动端百分比基于父宽，而父宽可能因字体渲染微调而抖动 - 测试时手动双指缩放页面，观察是否出现意外换行或滚动条，这是
calc()失效的典型信号
calc() 本身没问题，问题永远出在“你假设的基准”和“浏览器实际采用的基准”是否一致。尤其是 padding 和 box-sizing 的组合，稍不注意就变成隐形布局断裂点。
