旧版安卓（如Android 4.4 WebView、微信6.5.22前）不支持calc()混用单位，必须手动书写层叠fallback：固定值在前、calc()在后；Sass/Less无法运行时降级，flex/padding-top/JS注入--vh等是更可靠的替代方案。
calc() 在旧版安卓（特别是 Android 4.4 WebView 和微信 6.5.22 之前）中不支持混用单位，比如 calc(100% - 1rem) 会整条声明被忽略——这不是 Sass/Less 能 polyfill 的问题，预处理器编译时根本不知道运行时环境，加前缀或生成备用值也无济于事。
旧版安卓 WebView 根本不解析 calc() 表达式
Android 4.4 的 WebView 基于 Chromium 30，对 calc() 的支持极弱：不识别带空格的加减运算、拒绝跨单位计算（% + px 可行，% + rem 直接失效）、vw/vh 混用更大概率崩溃。Sass/Less 编译后输出仍是 CSS，无法绕过浏览器引擎限制。
- 不要在
.scss里写@include calc-fallback(...)类宏——它不会生成运行时判断逻辑 - 避免用
#{...}或calc-units()函数试图“转换单位”——rem 在编译期是未知数，无法转成 px - Webpack 的
postcss-csso或autoprefixer也不会为calc()注入 fallback，它们只处理属性名和选择器
真正有效的降级必须发生在 CSS 层叠顺序中
唯一可靠的方式是手动书写层叠 fallback：固定值写在前，calc() 写在后，靠浏览器“跳过不认识的值”机制生效。Sass 可以帮你减少重复，但不能替代这个顺序逻辑。
- 正确写法（Sass 中可封装 mixin，但本质仍是两行 CSS）：
width: 320px;<br>width: calc(100% - 48px);
- 错误写法（试图用 Sass 计算出“等效 px”）：
$base-font-size: 16px; width: calc(100% - #{$base-font-size * 2});—— 这只是把32px写死，失去响应性，且未解决 rem 场景 - 若必须用 rem，fallback 应基于设计稿基准（如 1rem = 16px），写成
width: 288px; width: calc(100% - 2rem);，而非依赖 Sass 动态计算
遇到微信 6.5.22 之前版本必须放弃 calc() 主逻辑
该版本不支持 vmin/vmax，对 calc() 中除法（/）和复杂括号嵌套也极不稳定。此时应切换布局方案，而非强撑 calc()。
立即学习“前端免费学习笔记（深入）”；
- 宽度减去固定边距？改用
display: flex+padding或margin，IE10+ 和 Android 4.4 都支持flex（需加-webkit-前缀） - 需要等比容器？放弃
height: calc(100% * 0.5625)，改用padding-top: 56.25%占位 +position: absolute子元素 - 动态视口高度？JS 注入
--vh自定义属性，再用height: calc(var(--vh, 100vh) - 60px)，Android 4.4 支持var()（需加-webkit-）
最易被忽略的一点：很多团队以为加了 Sass mixin 就“兼容了”，结果在微信内测机上整块区域消失——因为 calc() 失效后 fallback 没写，或者写反了顺序。真正在意兼容性，就得接受“CSS 层叠即 polyfill”这个事实，而不是寄希望于构建工具替你兜底。
