calc()中单位混用需满足量纲一致且上下文有参考基准，如10px+1em合法，而10px+20%在父尺寸未定义时可能失效；推荐用clamp()、媒体查询或em/rem替代复杂calc。
calc() 里混用单位会直接失效
浏览器对 calc() 的单位混合非常敏感——不是“能算就行”，而是“单位类型必须可比”。比如 calc(10px + 1em) 合法，因为都是长度；但 calc(10px + 20%) 在某些场景下会出问题：当父容器宽高未定义时，% 缺失参考基准，整个表达式可能被忽略或退化为 0。
- 百分比单位只在有明确参考尺寸的上下文中才可靠（如父元素设置了
width或height） - 避免在
padding或margin中写calc(5% + 1rem)——不同方向的百分比参考不同（水平参考 width，垂直参考 height），容易导致意外缩放 - 移动端视口变化频繁，
vw/vh虽灵活，但 iOS Safari 对vh的处理有历史 bug（滚动时视口高度变化，vh值卡旧），建议搭配min-height: 100dvh用
padding 用 calc 动态计算时的盒模型陷阱
很多人以为 padding: calc(5% + 10px) 就能“响应式内边距”，但忘了 box-sizing 的影响。默认 content-box 下，这个 calc 算出来的是纯 padding 值；可一旦父容器用了 border-box，它不影响 padding 计算逻辑，但会改变整体尺寸感知——尤其嵌套多层时，视觉误差会累积。
- 始终显式声明
box-sizing: border-box，避免跨浏览器差异（IE8+ 都支持） -
padding四个方向不建议共用一个calc表达式，例如padding: calc(2% + 4px)实际等价于padding: calc(2% + 4px) calc(2% + 4px) calc(2% + 4px) calc(2% + 4px)，但左右和上下参考基准不同，结果未必对称 - 若需不对称，拆开写：
padding-left: calc(3% + 8px); padding-top: calc(1vh + 6px);
哪些单位组合 calc 能稳定工作
不是所有单位都能自由加减。CSS 规范只允许相同“量纲”的值参与运算。长度单位之间可以混用，但不能和无单位数、时间、角度等混搭。
- ✅ 安全组合：
px/em/rem/vw/vh/%（仅当上下文有明确参考时） - ❌ 报错或静默失败：
calc(10px + 2s)、calc(100% - 20px)（在 flex 容器子项中且父无 width 时）、calc(1fr + 10px)（fr是网格专用单位，不能用于padding） - ⚠️ 注意
%在padding-bottom中参考的是父元素宽度（不是高度！），这是 CSS 历史行为，别指望它随内容高度变化
替代 calc 的更稳方案
如果只是想让 padding 随屏幕缩放，calc 不是唯一解，有时反而增加维护成本。现代布局中，更推荐用原生响应能力兜底。
立即学习“前端免费学习笔记（深入）”；
- 用
clamp(12px, 4vw, 24px)替代简单线性伸缩，它天然防过小/过大，且无需依赖父尺寸 - 媒体查询仍是 padding 响应最可控的方式：
@media (max-width: 768px) { .card { padding: 8px; } }，尤其适合断点明确的设计 - 如果 padding 要跟随字体大小变化，优先用
em或rem，比如padding: 1em 1.5em，比calc(1rem + 4px)更轻量、更可预测
真正难的不是写出一个能跑的 calc 表达式，而是判断它在各种设备、缩放、嵌套深度、父容器状态下的表现是否一致——多数时候，少一层动态计算，就少一层不可控。
