calc()仅计算content区尺寸，总宽受box-sizing影响；混用%与vw/vh易失效；transform不改变%基准；嵌套calc和变量增加调试难度；优先用flex/grid替代手算。
calc() 不改变盒模型，只提供 width/height 的值；box-sizing 才决定这个值怎么分配到 content、padding、border 上。
calc() 算出来的是 content 区宽度，不是总宽
很多人写 width: calc(100% - 40px) 后加了 padding: 10px 和 border: 2px，发现元素撑出父容器——这是因为 calc() 输出的仍是 content 宽度目标值，而默认 box-sizing: content-box 下，总宽 = content + padding + border。
- 想让“总宽 = 100% - 40px”，必须配合
box-sizing: border-box - 如果用了
box-sizing: border-box，就别在calc()里再手动减 padding/border，否则会重复扣除 - 若用
content-box，又想控制总宽，就得把所有尺寸都塞进calc()：比如width: calc(100% - 2 * 10px - 2 * 2px)（对应左右 padding + border）
百分比和 vw/vh 混用容易失效
calc(100% - 2rem) 很稳，但 calc(100vw - 2rem) 在旧版 Safari 或某些 iOS 场景下可能计算错——因为 % 依赖父容器宽度，vw 是视口宽度，两者布局阶段的求值时机不同。
- 优先用同类型单位混算：
calc(100% - 2em)或calc(100vw - 2rem) - 跨上下文需求（如“占满视口但扣 header 高度”），改用
max-width+width: 100%组合，或用container查询配合clamp() - iOS 15.4 之前，
calc(100vw - var(--gap))中的--gap若定义在:root，可能被忽略；得定义在组件自身选择器里才可靠
transform 缩放后，calc() 的 % 基准不变
给父容器加了 transform: scale(0.8)，子元素写 width: calc(100% - 16px)，百分比仍按缩放前的父宽计算——视觉上内容变小了，但留白、点击区域全偏了。
-
transform不影响布局流，所以%基准永远是原始尺寸 - 如果需要响应式缩放下的精确留白，要么改用固定单位（如
px或rem），要么把缩放逻辑移到 layout 层（比如用scale()替代transform的同时，动态重设font-size或容器尺寸） - 绝对定位居中时也一样：
left: calc(50% - 50px)在未设position: relative的父容器里，基准是 viewport，不是视觉所见的父块
嵌套 calc() 和变量会让调试变困难
calc(calc(100% / var(--cols)) - calc(2 * 1em)) 这类三层嵌套，浏览器能解析，但一旦某个变量未定义或环境变量（如 env(safe-area-inset-bottom)）缺失，整条声明会静默失效，毫无报错提示。
- 避免三层以上嵌套，拆成 CSS 自定义属性更可控，比如先定义
--col-width: calc(100% / var(--cols))，再用width: calc(var(--col-width) - 2em) -
calc()本身开销极小，但频繁依赖动态值（尤其是跨层级变量 + 环境变量）会让布局行为变得不可预测 - 注意
border-width默认是固定像素，不会随 rem/vw 缩放；要响应式就得显式写成border: calc(1px * 1) solid #000（虽然看起来傻，但有效）
真正难的不是写对 calc 表达式，而是判断它该不该出现——很多时候 flex 或 grid 天然处理了盒模型分配，比手算 width 更稳、更易维护。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
