savedata 是 navigator.connection 的布尔属性，表示用户是否启用数据节省模式，但需先判断存在性才能安全读取；它可驱动图片降级、禁用视频自动播放等真实省流行为，但应结合 effectivetype 和 downlink 避免强网下过度降级，且须监听 onchange 事件响应模式切换。
saveData 是什么，它真的能被可靠读取吗
saveData 是 navigator.connection 对象上的一个布尔属性，表示用户是否在系统或浏览器中启用了“数据节省模式”（如 iOS 的低数据模式、Android 的数据节省程序、Chrome 的“数据节省”扩展等）。它不是开发者手动开关的配置，而是由用户主动开启后，由浏览器透出的真实偏好信号。
但要注意：这个值只在支持 Network Information API 的浏览器中存在，且部分安卓 WebView 或旧版 Safari（iOS 14.5 之前）完全不暴露 connection 对象。所以必须先做存在性判断：
if ('connection' in navigator && 'saveData' in navigator.connection) {
const isSavingData = navigator.connection.saveData;
// ✅ 安全使用
} else {
// ❌ 回退策略：按默认网络类型处理，或忽略省流逻辑
}
如何用 saveData 触发真实省流行为，而不是只改个文案
仅检测 saveData 布尔值没用，关键是要让它驱动具体资源加载决策。常见可落地的点包括：
- 跳过非关键图片的
src，改用srcset中最低清版本，或直接用占位符 SVG - 禁用自动播放视频（尤其是带音轨的），或强制降为静音 + poster 图片
- 关闭第三方分析脚本（如 Google Analytics、Sentry 的采样率设为 0）
- 将 JSON API 请求的
Accept头改为application/vnd.api+json;v=2等轻量格式（如果后端支持） - 对字体文件启用
font-display: swap并跳过preload
注意：不要用 saveData 去禁用所有图片——有些是内容核心（比如商品主图），应保留，只是压缩尺寸和质量。
为什么不能只依赖 saveData，还要结合 effectiveType 和 downlink
saveData 只回答“用户想省流量”，但不回答“当前网络有多差”。例如：用户开着 Wi-Fi 但启用了省流模式，此时带宽充足（downlink > 10），你却把所有图都 fallback 成 base64 小图标，反而增加 JS 体积和首屏渲染压力。
更合理的组合判断是：
const conn = navigator.connection; const isSaving = conn?.saveData ?? false; const isWeak = conn?.effectiveType === '2g' || conn?.effectiveType === '3g'; const isSlow = conn?.downlink <p>这样既尊重用户意愿，又避免在强网下过度降级体验。</p> <h3>服务端也要配合：Save-Data 请求头比前端 JS 更早生效</h3> <p>前端 JS 执行时页面可能已开始加载资源，而浏览器会在发起首个请求时就带上 <code>Save-Data: on</code> 请求头（Chrome / Opera / Yandex 支持）。这意味着服务端可以比 JS 更早介入：</p>
- Node.js（Express）中可用
req.headers['save-data'] === 'on'判断，直接返回精简 HTML 模板 - Nginx 可通过
map $http_save_data $save_data { "on" 1; default 0; }注入变量，控制静态资源路径（如指向/lite/子目录） - CDN（如 Cloudflare）支持基于请求头的缓存键（Cache Key）分叉，让
Save-Data请求命中不同缓存版本
纯前端省流是补救，服务端响应才是第一道防线。尤其对 SSR 应用，JS 还没执行，HTML 已经发出去了——这时候靠 saveData 属性已经晚了。
真正容易被忽略的是：用户切换省流模式时，connection 对象不会触发重载，但 change 事件会触发。如果你只在初始化时读一次 saveData，后续用户中途开启省流，你的策略就失效了。务必监听 navigator.connection.onchange 并重新评估策略。
