calc()能算但不一定生效，根本原因在于盒模型、父容器约束或单位混用导致的隐性冲突：父容器无明确width使百分比失效；inline元素不支持width；content-box下padding/border撑出额外宽度。
直接说结论：calc() 能算，但“能算”不等于“一定生效”——多数宽度计算失效，根本原因不在表达式本身，而在盒模型、父容器约束或单位混用时的隐性冲突。
为什么 calc(100% - 20px) 有时没反应？
表面看语法没问题，实际常被以下三点卡住：
- 父容器未设
width或为auto，导致百分比基准丢失（100%没参照） - 目标元素是
display: inline，而width对 inline 元素无效 -
box-sizing是默认的content-box，但 padding/border 会撑出额外宽度，让calc结果被视觉上“覆盖”
最稳妥做法：给目标元素加 display: block 或 inline-block，并显式声明 box-sizing: border-box。
vw 和 rem 混合计算为什么在 Safari 里不准？
不是语法错，是浏览器实现差异。Safari 15.4 之前对 vw - rem 的浮点精度截断更激进，比如 calc(100vw - 2rem) 可能被算成 100vw（rem 部分被舍掉）。
- 优先用
px替代rem做减法，例如calc(100vw - 32px) - 若必须用
rem，确保:root的font-size是固定值（不用 JS 动态改），否则重排不触发重新计算 - 加
min-width: 0强制 Safari 重新评估表达式（小技巧，但有效）
怎么避免媒体查询 + calc 的冗余写法？
别把 @media (max-width: 768px) { width: calc(100% - 32px); } 和 @media (min-width: 769px) { width: calc(100% - 64px); } 拆开写——既难维护，又漏断点。
- 用
min()直接表达逻辑：width: calc(100% - min(32px, 4vw))，小屏用固定值，大屏随视口缩边距 - 需要上下限？套
clamp()：width: clamp(320px, calc(100% - 2rem), 1200px) - 注意：
min()和clamp()在 Safari 15.4+、Firefox 91+ 才稳定，旧版得回退到媒体查询 +calc组合
真正容易被忽略的点：calc 表达式里的空格是硬性要求——calc(100%-20px) 会失败，必须写成 calc(100% - 20px)；另外，它只作用于**可接受长度值的 CSS 属性**，比如 width、font-size、margin，但不能用于 z-index 或 opacity 这类非长度属性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
