<p>calc(100% - 20px) 失效主因是父容器高度未锚定，导致百分比解析为NaN；修复需显式设置父高或改用flex/grid布局，避免依赖calc硬扣像素。</p>
height: calc(100% - 20px) 为什么没生效
不是语法错，而是父容器高度没“锚定”。height 属性对百分比极其苛刻：只要父元素 height 是 auto、fit-content 或未显式设置，子元素的 100% 就会解析为 NaN，整个 calc() 表达式直接被浏览器丢弃——DevTools 里该行样式会被划掉，但不报错。
- 验证方法：打开 DevTools → Elements → 查看 computed styles 中
height是否显示为auto或空白 - 修复路径：给父容器加
height: 100vh、height: 500px，或用display: flex+flex-direction: column触发 BFC 高度继承 - 别依赖
min-height或max-height来“撑高”父容器——它们不构成确定的高度上下文
calc() 里混用 % 和 px 在缩放时反而更偏
缩放（zoom 或系统 DPI 设置）下，calc(50% - 20px) 会左偏加剧，因为 % 按缩放后容器宽计算，而 20px 被二次缩放，抵消量变大。这不是 bug，是单位行为错层。
- 优先用视口单位替代 px：写成
calc(50% - 2vw)，vw与%同属相对单位，缩放时同步变化 - 若必须扣固定视觉尺寸（如按钮内边距），用
rem+clamp()控制范围：padding: clamp(0.5rem, 0.75rem, 1rem) -
transform: scale()完全不影响%的计算基准——它只改变渲染，不改变布局流，所以calc(100% - 16px)仍按原始尺寸算
嵌套容器中百分比误差叠加，calc() 不是万能解
三层嵌套下，每层 width: 33.33% 四舍五入到像素，误差累积可能让三列总宽超 100%，最后一列换行。这时 calc(33.3333% - 1px) 确实比纯百分比稳，但它治标不治本。
- 真正可控的做法是把固定开销一次性扣除：
width: calc((100% - 2px) / 3)（假设左右边框共 2px） - 但更推荐放弃 float + calc 组合：用
display: grid+grid-template-columns: repeat(3, 1fr)，gap 自动处理间距，无精度损失 - 注意：IE9 支持
calc()，但不支持括号内嵌除法写法，calc(100% / 3)在 IE 中无效，必须写成calc(33.3333%)
box-sizing: border-box 并不“覆盖”calc() 计算结果
很多人以为设了 box-sizing: border-box，再写 width: calc(100% / 3) 就万事大吉。其实 calc() 算出的是 content 区域目标宽度，border 和 padding 仍会额外占用空间，导致总宽溢出。
立即学习“前端免费学习笔记（深入）”；
- 正确做法：把 border/padding 显式减进去，比如三列带
padding: 1rem和border: 1px，就写width: calc((100% - 2rem - 2px) / 3) -
border-width默认是绝对像素，不会随 rem/vw 缩放——要响应式就得写成border: calc(1px * 1) solid #000（虽然看起来怪，但有效） - flex/grid 布局天然规避这个问题：它们分配的是“可用空间”，
box-sizing影响自动纳入计算逻辑
实际项目里，calc() 最容易被当“万能胶”硬贴在各种老布局上。它确实能救急，但真正省心的解法，往往藏在是否该换 layout mode 的判断里——尤其是当你开始反复调试 calc(100% - Xpx) 里的 X 值时。
