真正“只加载”需将各断点背景图拆至独立css文件，通过按需加载；@media包裹或css变量均无法阻止预加载。
background-image在不同断点下如何真正“只加载”？
它根本不会自动“只加载”。background-image写在CSS里，浏览器会按规则预加载——哪怕媒体查询没生效，只要CSS被解析，且该规则匹配（哪怕暂时不可见），图片就可能被取。所谓“响应式背景图节省带宽”，必须靠显式控制资源请求时机。
- 用
@media包裹background-image只是隐藏样式，不阻止加载（Chrome DevTools 的 Network 面板能验证） - 真正规避预加载，得让图片URL只出现在当前生效的CSS规则中，且该规则不被提前解析到无关断点里
- 推荐做法：把各尺寸背景图拆到独立CSS文件中，按
media属性异步加载，或用picture+img替代（但这是HTML层方案）
用link[rel=stylesheet][media]按需加载断点CSS
这是最可控、兼容性好、且真能阻止非目标尺寸图片加载的方式。核心是把每个断点的背景图声明，放到独立CSS文件里，并通过<link>的media属性触发条件加载。
-
small.css里只写.hero { background-image: url("hero-400w.jpg"); }，并在HTML中：<link rel="stylesheet" href="small.css" media="(max-width: 480px)">
-
medium.css对应(min-width: 481px) and (max-width: 768px)，里面只放hero-768w.jpg的声明 - 注意：所有
<link>必须放在中，且不能加preload或prefetch，否则会破坏按需逻辑 - 缺点：多一个HTTP请求；好处：Safari / Firefox / Chrome 全部原生支持，无JS依赖，首屏无冗余图片请求
CSS容器查询（@container）目前还不能用于背景图懒加载
有人想用@container配合background-image做更精细的尺寸适配，但现实是：容器查询不触发资源加载时机控制，且background-image仍会在容器满足条件前就被预取（尤其当容器本身有固定宽高时）。
- 目前（2024年中）
@container对background-image的“按需加载”毫无帮助，它只影响样式计算，不影响资源获取生命周期 - 若容器尺寸由JS动态设置，而CSS里又写了
background-image，浏览器大概率在JS执行前就发出了图片请求 - 真要靠容器尺寸切换图片，得用
Element#style.backgroundImage+ResizeObserver手动控制，但这就脱离了纯CSS路径
为什么不要用CSS变量+calc()拼接URL来“动态”换图？
类似background-image: url(var(--bg-sm));这种写法看起来灵活，但实际完全不可控——变量值一变，浏览器立刻发起新请求，旧图未必释放，且无法与断点解耦。
立即学习“前端免费学习笔记（深入）”；
- CSS变量不是惰性求值，一旦声明并被引用，浏览器就会尝试解析和加载
url()里的地址 - 即使你用
@media去改--bg-sm的值，原url()请求已发出，新请求又追加，反而造成双重加载 - 更隐蔽的问题：构建工具（如PostCSS）可能提前内联变量，导致所有尺寸图片URL都硬编码进最终CSS，彻底失去按需意义
复杂点在于：图片是否加载，不取决于你“写了什么条件”，而取决于浏览器解析CSS时“实际看到什么URL”。任何试图用CSS机制绕过这个事实的做法，都会在真实网络环境下漏掉带宽优化的关键窗口。
