backdrop-filter 在 iOS 低电量模式下被系统级强制禁用，WebKit 直接跳过渲染路径，不分配 GPU 资源且不降级；检测需用 JS 判断（非 @supports），降级应采用 class 控制的静态通透样式。
backdrop-filter 在 iOS 低电量模式下不是“失效”，而是被系统级强制禁用——它和 blur() 值大小、CSS 写法都无关，是 Safari WebKit 主动丢弃该渲染路径的结果。
低电量模式直接关闭 backdrop-filter 的 GPU 合成通道
iOS 低电量模式（Battery Saver）会全局限制图形子系统的资源调度策略：Safari WebKit 在检测到 lowPowerMode 启用时，会跳过所有需要离屏纹理 + 高斯卷积的合成操作。这意味着即使你写了 -webkit-backdrop-filter: blur(4px)、background-color: rgba(255,255,255,0.1)、也触发了层叠上下文，浏览器在解析阶段就直接忽略该属性，不分配任何 GPU 资源，也不降级为 CPU 渲染——它就是“不存在”。
这个行为从 iOS 15 开始稳定存在，且不会抛出任何警告或错误日志；开发者调试时看到的只是“样式生效但无视觉变化”，容易误判为写法问题。
如何检测并可靠降级
不能依赖 @supports (backdrop-filter: blur(1px))，因为低电量模式下该检测仍返回 true（属性名识别成功，但运行时被屏蔽）。必须用 JS 检测系统状态：
立即学习“前端免费学习笔记（深入）”；
- 使用
navigator?.batteryAPI（iOS 16.4+ 支持，但需用户授权，不可靠） - 更稳妥的是监听
webkitBatteryStatus事件（已废弃）或改用 UA + 时间戳启发式判断——但最实用的是直接读取matchMedia('(prefers-reduced-data: reduce)')或matchMedia('(prefers-contrast: high)')，它们在低电量模式下常同步触发 - 生产环境推荐：在页面初始化时执行一次
document.body.classList.add('low-power-mode')，由 native bridge 注入（如 WKWebView 中通过evaluateJavaScript注入布尔值）
降级样式必须写在 JS 控制的 class 下，例如：
.glass { background: rgba(255, 255, 255, 0.12); }
.glass.low-power-mode { background: rgba(255, 255, 255, 0.28); backdrop-filter: none; -webkit-backdrop-filter: none; }
为什么 overflow: hidden 会加剧这个问题
低电量模式本身已禁用 backdrop-filter，但若元素父容器还带 overflow: hidden，会导致两个叠加失效：
- backdrop-filter 被系统跳过 → 无模糊
- 因父级裁剪，半透背景
rgba()在边缘处与底层内容混合异常 → 出现灰边、色块或透明窟窿
此时仅移除 overflow: hidden 并不能恢复模糊，但能修复视觉断裂。真正要做的，是在低电量模式下彻底放弃毛玻璃，改用静态通透感：background: linear-gradient(135deg, rgba(255,255,255,0.08), rgba(255,255,255,0.12)) + 极细描边。
别指望 iOS 17+ 改变这个逻辑
截至 2026 年 10 月，iOS 17.6 和 iOS 18 beta 均未开放低电量模式下的 backdrop-filter 权限。Apple 明确将其归类为“高能耗图形操作”，与 ProMotion 屏幕刷新率锁定、视频解码降频同级处理。试图用 transform: translateZ(0) 或 will-change: filter 强行唤醒 GPU 无效，反而可能触发更激进的资源回收。
真正难的不是绕过限制，而是让设计师接受：低电量模式下的 UI 不是“降质版”，而是另一套能耗感知设计语言——它本就不该有毛玻璃。
