html无adaptive loading内置特性，需组合设备内存、网络类型、视口尺寸等信号分层决策加载；srcset+sizes实现零js图片自适应；loading="eager/lazy"控制时机；intersectionobserver+import()实现js/css逻辑化自适应。
HTML 本身没有 Adaptive Loading 这个内置特性，所谓“自适应加载”是组合多个原生能力实现的策略性行为——不是加一个属性就完事，而是根据设备内存、网络类型、视口尺寸、元素可见性等信号，分层决定加载什么、何时加载、怎么加载。
用 srcset + sizes 做图片自适应加载
这是最稳定、兼容性最好（IE9+）、零 JS 即可生效的图片自适应方案。关键不在“动态换图”，而在 HTML 解析阶段就让浏览器选对资源。
-
sizes必须写清楚这张图在不同断点下占多少宽度，比如sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 33vw"，否则浏览器只能瞎猜 -
srcset优先用w单位（如logo-800w.jpg 800w），而不是只写2x；x只响应设备像素比（DPR），不响应视口宽度变化 - 如果后端返回的是带参数的 CDN 图片（如
/img?id=123&w=800），srcset仍可用，但所有 URL 必须真实存在且尺寸准确，否则 fallback 到src时可能拉错分辨率 - 首屏关键图（如 logo、banner）必须加
loading="eager"，否则 Chrome 可能因 LCP 优化逻辑延迟加载，导致实际渲染变慢
用 loading="lazy" 控制非首屏资源时机
这是真正意义上“按需加载”的起点，但它不可编程、不可监听，纯由浏览器内部策略驱动。
- 仅对
<img>和<iframe></iframe>生效，其他资源（如<script></script>、<link rel="stylesheet">）不支持 - Safari 直到 v15.4 才支持
loading="lazy"对<iframe></iframe>的控制，旧版 Safari 会直接忽略该属性并立即加载 - 配合
decoding="async"能减少图像解码阻塞主线程，尤其适合瀑布流页面中密集排布的图片 - 别指望靠它做“加载中”状态反馈——你无法监听
loadstart或error，失败时浏览器也不会重试
用 IntersectionObserver + import() 实现 JS/CSS 自适应加载
当“自适应”需要逻辑判断（比如：只在用户滚动到模块、且设备内存 ≥ 2GB 时才加载交互组件），就必须靠 JS 主动控制。
-
navigator.deviceMemory可读取设备内存等级（如2表示 ≤2GB），但该值只在 HTTPS 环境下有效，HTTP 页面返回undefined -
navigator.connection.effectiveType（如'4g'、'slow-2g'）和saveData（用户是否开启“省流量模式”）可用于降级策略，但部分 Android WebView 不支持 - 动态
import()加载的模块默认是异步执行的，但首次调用仍会触发网络请求；若想进一步控制，需结合IntersectionObserver的rootMargin提前触发（如'0px 0px 300px 0px'） - CSS 文件不能直接
import()，得用document.createElement('link')插入并监听onload，否则样式注入时机不可控
别把 Adaptive Loading 当成开关，它本质是信号链路
真正容易被忽略的是：这些 API 返回的值本身就有局限性和延迟。比如 navigator.hardwareConcurrency 在某些低端 Android 设备上始终返回 2，navigator.connection 在桌面端多数为 undefined，而 IntersectionObserver 的回调也不是实时的——它在浏览器空闲时段批量执行。
所以实际落地时，不要依赖单个信号做激进决策（例如“内存
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
