CSS的calc()函数，表面上看似简单，实际使用时却隐藏着不少“暗坑”。它在浏览器中的执行逻辑，总结起来其实就一句话：遇到错误时不会直接报错，而是默默地把整条声明废弃掉。当你发现页面布局出现异常，却怎么也找不到原因时，问题很可能就出在那些不起眼的空格上。
首先聊聊最经典的“空格陷阱”。浏览器对calc()的语法检查极其严格——+和-运算符的两侧必须保留空格，否则整条声明会被直接静默丢弃，DevTools中只会显示一句冷冰冰的Invalid property value，既不抛出错误，也不给出任何提示。来看几个典型例子：
calc(100% - 20px)✅ 正确写法，运行正常calc(100%-20px)❌ 完全失效，即使Safari 16也无法识别calc(100% -20px)❌ 同样无效，减号后面缺少了空格- 至于
*和/，虽然规范允许不加空格，但为了统一和避免团队协作中的误写，建议统一加上：calc(1rem * 2)，这样能有效减少歧义和手误
接下来是乘除运算中的“纯数字”限制。calc()不允许单位与单位之间进行相乘或相除——20px * 20px或100vh / 20px都属于非法表达式。它只接受“带单位的值 × 纯数字”或“带单位的值 ÷ 纯数字”这种组合：
calc(var(--gap) * 2)✅ 没有问题，前提是--gap: 20pxcalc(var(--gap) * var(--scale))⚠️ 存在风险，--scale必须定义为纯数字（例如1.5），绝对不能附带单位calc(100% * 0.8)❌ 注意，百分比不属于“可缩放单位”，不能用于乘除——它只能参与加减运算- 如果确实需要实现比例缩放，建议将逻辑拆分：定义
--base: 100%和--ratio: 0.8两个变量，通过JavaScript或在构建阶段计算好具体数值，不要强行塞进calc()
接下来是嵌套calc()的兼容性问题。像calc(calc(100% - 20px) / 3)这种写法，在Safari 15.4之前的版本中完全不支持，而且不会自动降级——样式会直接消失。更棘手的是，@supports (width: calc(0px))无法检测出嵌套能力，它只关心顶层是否支持calc()。替代方案其实很简单：利用CSS自定义属性来存储中间结果。例如--content-width: calc(100% - var(--gap))，然后在元素中写width: calc(var(--content-width) / 3)。另外，clamp()中也不建议嵌套多层calc()，像clamp(320px, calc((100vw - 200px) / 3 * 2), 600px)这种写法解析负担较大，动画时容易卡顿。在Grid布局中也要特别注意：calc(1fr - 20px)这种写法，由于1fr是动态分配的份额，减去像素后可能变为0甚至负值，实际效果完全不可控。
最后聊聊单位混用的问题。calc(1rem + 20px)或calc(100vh - env(safe-area-inset-bottom))在现代浏览器中运行良好，但在IE11、Android 4.4 WebView、部分鸿蒙旧版内核中，整条样式规则会被静默丢弃——而且@supports也无法检测出来。如果确实需要兼容这些老旧环境，只能在构建阶段进行降级处理。PostCSS流程必须严格按照postcss-custom-properties → postcss-calc（设置preserve: false）的顺序执行，顺序一旦出错，降级效果就等于零。移动端安全区适配更不要只依赖env()加calc()，需要额外加一层padding-bottom: 16px作为兜底方案。至于侧边栏留白这类场景，优先考虑Flex或Grid布局——flex: 1配合固定宽度的sidebar，比calc(100% - 240px)要健壮得多。
归根结底，问题的难点不在于函数本身，而在于浏览器对“非法表达式”的处理方式：不是报错，而是默默跳过。当你看到布局出现异常时，第一反应不应该是逻辑错了，而是去检查空格、单位、嵌套层级以及目标环境真实的支持范围。这才是解决问题的关键。
