calc()混用em与绝对单位会失效，因em不可归一化；padding-top中百分比始终参照父宽而非自身高；calc()不支持函数嵌套和变量运算；旧版Safari需避免简写中使用calc()。
calc() 里混用单位会直接失效
浏览器遇到 calc(10px + 2em) 这类混合单位表达式不会报错，但整个值会被当作无效声明丢弃，表现为内边距回退到初始值（通常是 0）。CSS 的 calc() 要求参与运算的每个项必须是可归一化的长度单位——也就是最终能转成相同物理量纲的值。像素、百分比、rem、vh 等可以混用，但 em 是相对当前字体大小的动态单位，在计算时无法与绝对单位对齐，尤其在嵌套字体缩放场景下行为不可控。
实操建议：
- 统一用
rem或px做基础单位，比如padding: calc(1rem + 0.5vw) - 避免在
calc()中写em，若需响应字体变化，改用rem并确保根字体大小可控 - 用浏览器开发者工具检查 computed 样式，如果看到
padding显示为initial或空白，大概率是calc()表达式被静默忽略
百分比在 padding-top/bottom 上的特殊行为
当把 calc() 用于 padding-top 或 padding-bottom 且含百分比时，这个百分比始终相对于**包含块的宽度**，而非高度——这是 CSS 盒模型规范决定的，和是否用 calc() 无关。比如 padding-top: calc(10% + 16px)，其中 10% 是按父容器宽度算的，不是当前元素自身高度。
这容易导致预期外的垂直留白过大或过小，尤其在宽屏设备上。
实操建议：
- 如果目标是根据视口高度动态调整上下内边距，改用
vh单位：padding-top: calc(5vh + 1rem) - 需要真正基于元素自身高度？只能靠 JS 驱动，CSS 无解
- 测试时拉伸窗口宽度，观察
padding-top是否随宽度变化——这是验证是否踩中该陷阱的最快方式
calc() 不支持函数嵌套和变量计算
calc() 内部不能调用其他 CSS 函数，比如 min()、max()、clamp() 或自定义 --var 的数学运算。写成 calc(max(1rem, 2vw)) 或 calc(var(--base) * 2) 都会失败。
虽然现代浏览器已支持 min()/max() 作为独立函数（如 padding: max(1rem, 4vw)），但它们和 calc() 是并列关系，不是子集。
实操建议：
- 用
clamp()替代复杂条件逻辑：padding: clamp(1rem, 2.5vw, 2rem) - 变量参与计算要先赋值为具体数值：
--pad-base: 1rem;，然后padding: calc(var(--pad-base) + 0.5rem) - 注意：Sass/Less 等预处理器的数学运算是编译时完成的，和运行时
calc()无关，别混淆两者阶段
移动端 Safari 对 calc() 的早期兼容性坑
iOS 13.3 之前版本不支持在 padding 简写属性中使用 calc()，例如 padding: calc(1rem) calc(2rem); 会整体失效；但拆成 padding-top、padding-right 等单独声明就正常。
现在虽已基本淘汰旧系统，但若项目仍需兼容 iOS 13.2 及更早，这点仍可能暴露。
实操建议：
- 优先使用长属性而非简写：
padding-top: calc(1rem); padding-right: calc(2rem); - 用 caniuse 查目标用户覆盖范围，确认是否真有必要降级
- 真要简写又保兼容？用 CSS 自定义属性兜底：
padding: var(--pad-y) var(--pad-x);，再用 JS 动态设置变量值
最常被忽略的是百分比参照基准的错觉——你以为 10% 在 padding-top 里是按高度算的，其实它永远盯住父容器宽度。这点不厘清，再复杂的 calc() 表达式都只是在错误方向上努力。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
