首屏大图轮播必须同步解决视觉冲击力、加载速度与移动端交互可靠性三件事；首图须设 loading="eager"（或省略该属性），禁用 lazy 加载以防 lcp 延迟 2–5 秒； 需按 max-width 由窄到宽排序并配 fallback ；dom 应采用三层轨道结构，配合 touch 事件与 aria-live 实现无障碍、低耗、流畅轮播。
首屏大图轮播不是“加个轮播插件就完事”，而是必须同时解决三件事：视觉冲击力、首屏加载速度、移动端交互可靠性。不处理好这三点，再炫的动效也会被用户划走。
为什么首屏大图不能用 loading="lazy"
浏览器对 loading="lazy" 的实现逻辑是：等元素进入视口才触发加载。但首屏大图本就在视口内——如果误加了这个属性，多数现代浏览器（Chrome 94+、Edge 94+）会跳过初始加载，导致 LCP（最大内容绘制）延迟 2–5 秒，用户看到白屏或骨架占位符时间明显变长。
- 首图必须显式设为
loading="eager"，或直接省略该属性（默认即 eager） - 轮播中非首张图可配合
IntersectionObserver按需加载，但首图绝不参与懒加载流程 - 若使用
<picture></picture>，<img>标签仍需单独设置loading="eager"，<source></source>不继承该行为
<picture></picture> 分端图源怎么写才不翻车
企业官网首屏大图常需在手机、平板、桌面三端呈现不同构图，<picture></picture> 是语义和性能兼顾的选择，但写错 media 查询顺序或漏掉 fallback 就会降级成单图硬撑。
- media 条件必须从窄到宽排列（否则 Safari 会忽略后续匹配项）：
max-width: 768px→min-width: 769pxandmax-width: 1200px→min-width: 1201px - 最后一个
<source></source>后必须跟一个<img>作为 fallback，且其src必须指向可用图（不能为空或 404） - 桌面端高清图建议补充
srcset和sizes，例如：srcset="hero-2560.jpg 2560w, hero-2560@2x.jpg 5120w" sizes="(min-width: 1201px) 2560px, 100vw"
轮播 DOM 结构要带“轨道层”，别直接操作 <img>
很多初学者把图片平铺在 <ul></ul> 里，靠 JS 切换 active class 控制显示。这种结构在移动端手势滑动、无缝循环、动画卡顿修复上几乎无法扩展。
- 必须分三层：
<section class="carousel"></section>（语义容器）→<div class="carousel-viewport">（裁剪视口）→ <code><div class="carousel-track">（可位移轨道） <li>所有 <code><img>都放在.carousel-track内，用transform: translateX()移动整个轨道，而非逐个 show/hide 图片 - 移动端需监听
touchstart/touchmove/touchend并禁用默认滚动（event.preventDefault()），否则 iOS 上会触发页面回弹 - 默认开启自动播放，但首次交互（点击/触摸/键盘操作）后立即暂停，并记录状态（如 localStorage）避免下次刷新又启动
- 监听
document.visibilityState，切到后台标签页时暂停，切回前台再恢复（防止用户切走后还在跑定时器） - 给轮播容器加
aria-live="polite"，并在切换时用aria-label动态更新当前图描述，例如：aria-label="第 2 张图：城市天际线，当前播放中"
自动播放要不要开？开的话怎么防干扰
自动播放在首屏确实能提升信息触达率，但若处理不当，会打断用户阅读、消耗电量、甚至触发无障碍阅读器反复播报。
真正难的不是让图动起来，而是让动的过程不抢焦点、不阻塞渲染、不浪费流量、不忽略键盘用户——这些细节堆在一起，才是首屏轮播是否“可用”的分水岭。
