calc()不能绕过盒模型干扰，它只是提前计算content宽度；必须配合box-sizing:border-box才能使总宽符合预期，否则padding/border仍会叠加导致溢出。
calc() 为什么能绕过盒模型的 padding/border 干扰
直接写 width: 100% 时，padding 和 border 会撑出容器外，这是盒模型默认行为（box-sizing: content-box）。而 calc() 不是“修复”盒模型，而是让你在计算时**主动减去多余尺寸**，把最终值塞进 width 属性里——浏览器只管按你算出的数字渲染，不管你是怎么想的。
关键点：它不改变盒模型规则，只是提前把「内容区宽度」算出来。所以必须配合 box-sizing: border-box 才能真正对齐预期布局，否则 calc 出来的值仍会被 padding/border 叠加。
- 常见错误：只写
width: calc(100% - 20px)却忘了设box-sizing: border-box，结果元素比父容器还宽 - 适用场景：固定边框+动态内边距、左右有图标/按钮需留白、响应式侧边栏固定宽+主内容自适应
- 注意：百分比和像素混用时，
%始终相对于父容器宽度，不是当前元素自身
calc() 中的单位混合与括号优先级陷阱
calc() 支持 +、-、*、/，但运算符前后**必须有空格**，且不能把不同单位直接相加（比如 10px + 1em 合法，10px + 10% 也合法，但 10px + 10 会报错）。
括号只影响运算顺序，不解决单位冲突。最常踩的坑是漏空格或误用括号导致解析失败——浏览器会直接忽略整条声明，控制台不报错，但样式不生效。
立即学习“前端免费学习笔记（深入）”；
- 正确：
width: calc(100% - 2rem - 2px) - 错误：
width: calc(100%-2rem-2px)（缺空格） - 错误：
width: calc((100% - 2rem) - 2px)（括号冗余，虽不报错但易读性差） - 乘除注意：
calc(100% / 3)可用于三等分，但calc(100% * 0.33)更稳妥（避免小数精度问题）
配合 flex/grid 时 calc() 还有必要吗
多数情况下没必要。flex 容器中用 flex: 1 或 flex-grow: 1 就能自动填满剩余空间；grid 中用 fr 单位更直观。calc() 在这些布局里反而容易画蛇添足——比如给 flex 项硬写 width: calc(100% - 200px)，会破坏 flex 的弹性行为。
真正需要 calc() 的场合，往往是**无法用 flex/grid 直接表达的混合约束**：比如一个输入框要占满剩余宽度，但右边紧贴着一个固定宽按钮，且两者之间有 8px 间距。
- 可行方案：
width: calc(100% - 120px - 8px)（按钮宽 112px + 间距 8px） - 更健壮做法：用
display: flex包裹输入框和按钮，再给输入框设flex: 1，完全不用 calc - 结论：优先用布局模型解决，calc 是兜底手段，不是首选解法
IE11 对 calc() 的兼容限制和 fallback 方案
IE11 支持 calc()，但有硬伤：不支持 vh/vw 单位参与运算（calc(100vh - 60px) 会失效），也不支持嵌套函数（calc(100% - var(--gap)) 在 IE11 无效）。
如果项目必须兼容 IE11，别依赖 CSS 变量或视口单位做 calc，老老实实用 px/rem，并配 @supports 做降级：
input {
width: 200px; /* fallback */
}
@supports (width: calc(100% - 20px)) {
input {
width: calc(100% - 20px);
}
}- 注意：
@supports在 IE11 中不被识别，所以 fallback 必须写在前面 - var() 不能出现在 calc 内部 → 改用预处理器变量或重复写死数值
- 移动端基本无此问题，但企业内网环境仍可能遇到 IE11
calc 的本质是“让 CSS 会算术”，但它不会帮你判断逻辑是否合理——写错括号、漏空格、单位混搭不当，都会静默失败。调试时盯住 computed 样式里的 width 值，比看源码更直接。
