calc()中var(--gap)含百分比会导致单位混用或参照系漂移，因浏览器拒绝跨单位运算且%依赖上下文；应避免CSS变量存纯%，改用无单位数值或视口单位。
calc()里用var(--gap)但--gap是百分比值，为什么结果不对
因为var(--gap)返回的是原始字符串，如果--gap: 50%，那var(--gap)就是"50%"；但calc(100px - var(--gap))会变成calc(100px - 50%)——单位混用（px vs %），浏览器直接拒绝解析，整条规则静默失效。
这不是变量没生效，而是calc()语法层面不接受跨单位算术运算。加减运算只允许同类型单位（如%和%，或px和px），不能混合。
- ✅ 正确：—gap: 20px; width: calc(100% - var(--gap))
- ✅ 正确：—gap: 10%; width: calc(100% - var(--gap))
- ❌ 失效：—gap: 20px; height: calc(100vh - var(--gap))
- ❌ 失效：—gap: 10%; width: calc(100px - var(--gap))
为什么--gap: 50%在calc(100% - var(--gap))里看似合法却仍出错
表面看都是%单位，应该能算，但问题出在“计算时机”和“上下文依赖”上：100%的基准是父容器宽度，而var(--gap)里的50%也是相对它自己的父容器——但这两个“父容器”可能不是同一个元素。
尤其当变量定义在:root，却被用在嵌套很深的子元素calc()中时，%的参照系早已漂移。浏览器不会帮你对齐上下文，它只是机械拼接字符串再解析。
立即学习“前端免费学习笔记（深入）”；
- 避免在
var()中存纯百分比值，除非你100%确认所有使用点的包含块一致 - 更稳妥的做法是把比例逻辑交给
fr（Grid）或flex（Flex），它们天然处理相对分配 - 真要用百分比变量，优先设为无单位数字（如
--ratio: 0.5），然后写calc(100% * var(--ratio))——乘法允许数值与%混用
Sass/Less中$gap: 50%参与calc()为何编译后错得离谱
预处理器看到$gap: 50%，会把它当“带单位的值”直接代入，比如calc(100% - $gap) → calc(100% - 50%)。这看起来没问题，但Sass可能进一步优化成calc(50%)，而这个结果再被浏览器解析时，已脱离原始意图——你本想减去一个变量，结果变成了硬编码差值。
更危险的是，如果$gap在不同作用域被重定义（比如局部覆盖了全局），编译结果会不可预测。
- ❌ 绝对不要写
calc(100% - $gap)（Sass）或calc(100% - @gap)（Less） - ✅ Sass正确写法：
width: calc(100% - #{$gap}); - ✅ Less正确写法：
width: calc(~"100% - @{gap}"); - ⚠️ 注意：插值后的字符串必须保留空格，
~"100%-@{gap}"会因缺空格而失效
移动端Safari里百分比CSS变量突然失效的隐藏原因
iOS Safari（尤其是16+）对calc()中含百分比变量的解析有缓存行为：当页面触发滚动、键盘弹出或地址栏收放时，视口高度变化导致100vh重算，但var(--gap)若含%，其内部参照可能卡在旧尺寸，造成视觉偏移或归零。
这不是bug，是渲染管线在快速重排时对相对单位的取舍策略——它宁可跳过可疑计算，也不返回错误值。
- 关键信号：仅在滚动/键盘/横竖屏切换后复现，刷新页面又正常
- 临时规避：把
--gap: 10%改成--gap: 8vh（用视口单位替代，且dvh更稳） - 长期解法：放弃在
calc()中让CSS变量携带%单位，改用JS动态注入内联样式，或用container queries替代
真正容易被忽略的是：百分比变量的“%”不是魔法符号，它绑定在声明那一刻的包含块上；一旦DOM结构或布局模式变化（比如从普通流进Flex容器），那个%就已失效——你看到的不是计算错误，是参照系早被悄悄替换了。
