calc()中100% - 20px不生效主因是计算基准缺失或被更高优先级规则覆盖，如父容器无width、box-sizing为content-box、缺少空格、flex-grow干扰等。
calc() 里 100% - 20px 为什么有时不生效
不是语法错了，而是计算基准缺失或被更高优先级规则覆盖。常见现象是元素宽度没变、溢出父容器，甚至完全无视声明。
- 父容器没设
width或max-width：百分比单位需要明确的基准，display: inline、浮动未清除、或 flex 容器未设flex-shrink: 0都会导致100%算出 0 -
box-sizing是默认content-box：如果父容器有padding或border，100%指的是 content 区域宽度，减完20px后仍可能撑破盒子 - 写成
calc(100%-20px)（缺空格）：所有浏览器都会直接忽略整条声明，控制台无报错但样式不应用 - 用在
flex子项时忘了关flex-grow：只要flex: 1或flex-grow: 1存在，width就会被 flex 布局算法覆盖，calc()白写
混合单位加减运算的合法组合有哪些
浏览器对加减运算的单位一致性要求很实在：两边必须能映射到同一类尺寸基准，否则直接丢弃声明。不是“不推荐”，是部分环境会彻底失效。
-
100% - 20px✅ 大多数现代浏览器支持，但旧版 Safari（15.4 之前）对字体加载时机敏感，建议搭配min-width: 0防塌陷 -
50vw + 1rem✅ 视窗单位和相对单位可混，前提是 rem 基准稳定（避免字体加载延迟导致初始值为 16px） -
100vh - 2rem⚠️ iOS 15–16 Safari 初始渲染可能为 0，换成100vh - 32px更稳 -
100px + 1em❌ 多数安卓 WebView 和旧 Safari 直接忽略，因 px 和 em 缺乏统一换算上下文
用 calc() 实现“主内容区减侧边栏”时容易漏掉什么
这不是单纯写个 width: calc(100% - 240px) 就完事。真实布局中，侧边栏往往带 padding/border，主内容区还可能要避让 fixed 导航栏。
- 侧边栏若为
position: fixed，主内容区得额外加margin-left: 240px，否则文字重叠——calc()只管宽度，不管定位侵占 - 父容器若有
padding: 0 16px，主内容区应写width: calc(100% - 240px - 32px)，把左右内边距也扣掉 - 如果侧边栏宽来自 CSS 变量，如
--sidebar-width: 240px，务必确保变量定义含单位：--sidebar-width: 240px✅，--sidebar-width: 240❌（后者导致calc(100% - var(--sidebar-width))语法错误） - 别依赖
calc()自动响应子元素数量变化：比如 tab 数量变，每个 tab 宽度要均分剩余空间，必须由 JS 更新--tab-count变量，纯 CSS 数不了子元素个数
哪些地方 calc() 看似生效实则被吞掉了
最常被忽略的是布局上下文优先级。它不是万能补丁，而是一个依赖前提的计算工具。
- 用在
grid-template-columns里写calc(100% - 200px) 200px：如果网格容器本身是width: fit-content，100%基准为 0，整行塌陷 - 在 Flex 项目中设
flex-basis: calc(50% - 10px)：遇到换行（flex-wrap: wrap）时，单行宽度突变，calc基准跟着跳，视觉错位 -
font-size: calc(16px + 0.5vw)在 font-display: swap 下可能闪动：字体加载前用默认字号渲染，加载后才重算，需配合size-adjust或预设 fallback - 嵌套
calc(calc(100% - 20px) / 3)虽语法合法，但增加解析负担且无实际收益，直接写calc((100% - 20px) / 3)更清晰
真正难的不是写对一个 calc() 表达式，而是判断它所处的布局上下文是否提供了稳定、可预期的计算基准——这往往需要 inspect 元素盒模型、检查祖先链的 display 和 sizing 属性，而不是只盯着那行 CSS。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
