savedata 是 navigator.connection 提供的只读布尔值，反映用户是否启用系统级“数据节省模式”，它不主动省流，仅作为前端决策信号；需三层防护安全读取，并配合图片降级、视频预加载策略等实现真实流量优化。
saveData 是什么，它真的能省流量吗
navigator.connection.saveData 是一个只读布尔值，由浏览器根据用户是否在系统/浏览器层面开启了“数据节省模式”（如 Chrome 的 Data Saver、Android 的 Data Saver、iOS 的 Low Data Mode）来决定。它不控制任何行为，只是告诉你当前环境是否倾向于省流。
- 它不能主动开启省流，也不能强制压缩资源；它只是一个信号
- 值为
true时，通常意味着用户处于移动网络、资费敏感或信号较弱的场景 - 并非所有浏览器都支持：Safari 从 iOS 14.5 / macOS 11.3 才开始支持，旧版 Safari 返回
undefined；IE 不支持
所以别指望靠它“自动省流”，它只负责传递意图——你得自己响应。
怎么安全地读取 saveData 并避免报错
直接访问 navigator.connection 可能在部分环境（如某些 WebView、老版安卓浏览器、禁用 Network Information API 的隐私模式）下抛出 TypeError: Cannot read property 'saveData' of undefined。
必须做三层防护：
- 检查
navigator.connection是否存在 - 检查
navigator.connection.saveData是否为布尔值（有些浏览器返回undefined或字符串） - 建议加个 fallback：当无法判断时，默认不启用省流策略（保守更安全）
const shouldSaveData = () => {
if (!navigator.connection) return false;
const saveData = navigator.connection.saveData;
return saveData === true;
};
不要写成 !!navigator.connection.saveData——这会把 undefined 变成 false，看似没问题，但掩盖了 API 不可用的事实，不利于后续调试。
哪些前端操作值得配合 saveData 做降级
saveData 为 true 时，应优先减少请求体积和请求数量，而不是牺牲核心功能：
- 图片：用
srcset+sizes切换低分辨率图，或 fallback 到webp→jpeg→svg降级链；避免 JS 动态加载高清图 - 视频：默认不自动播放，禁用
preload="auto"，改用preload="metadata" - 字体：跳过自定义字体（用系统字体栈），或只加载
font-display: swap+woff2子集 - 第三方脚本：延迟加载非关键 SDK（如分析、广告），或完全跳过（需业务侧确认）
- 动画：关闭 CSS
prefers-reduced-motion之外的富交互（如轮播图自动切换、粒子动效）
注意：不要在 saveData 下停用错误监控、基础埋点或登录态校验——省流不该以不可观测、不可登录为代价。
服务端也能用？别依赖客户端传的 saveData
有人想在请求头里加 X-Save-Data: on，然后后端据此返回压缩 JSON 或低清图。这不可靠：
- 请求头可被任意篡改，不是可信信号
- 服务端无法验证该 header 是否真实来自浏览器原生 API
- 移动 CDN（如 Cloudflare）虽支持
Save-Data请求头，但仅限于明确开启该特性的边缘规则，且仍依赖客户端真实发送
更稳妥的做法是：前端检测到 saveData === true 后，拼接带标记的 URL（如 ?sd=1），再由后端识别并走轻量逻辑——至少 URL 参数不可伪造（相比 header 更易审计）。
真正难的不是读这个值，而是判断哪些资源可以安全降级、降多少、降完是否影响转化或上报。很多团队卡在这里：测了图片压缩率，却忘了首屏文字渲染延迟 200ms 就让跳出率涨了 3%。
