按理说，

想必各位看官老爷们都在Apple官网上看过这样一种动效：滚到某个区域。再往下滚轮，这块区域会被“钉”在视口中央，开始播放动画——直到动效结束，页面才会继续往下翻。往上滚，动画会倒放回去。效果如下👇

经典「Pin + 横向滚动」效果

这就是我们今天的主角：经典的 Pin 与横向滚动组合。

为什么叫 Pin + 横向滚动？

这个名字其实是两个动作的字面拼接，拆开看就懂了。

• Pin = 钉住
• 横向滚动 = 在 Pin 的期间，内容横着移动

Pin 的作用：

• 当页面滚动到某个区域时把这个区域固定在视口里不动。

横向滚动：

• 鼠标动作这方面，竖向滚轮。
• 视觉反馈的观点是，画面横向切换。

我知道这里有人就要问了：你不是说横向滚动吗。你的截图里明明是 C3 动画，大骗子…，

直接开始咱来做个简单 Demo

先给到三个容器，将页面分为上中下三个区域；先搭骨架，只能看到空白，内容接下来补；pin-section 是撑高的外壳，提供滚动距离。

接下来再在 pin-section 中塞入内容。pin-wrap 就是视口高度的“舞台”，被钉住内部四张卡片横向排成一长条，当滚轮时通过 JS 拉它平移。

&
&
&
&
&
&
&说起来，
&话说回来，
&，

布局完成后补上 JS 代码，就可以 Demo 效果。

const section = document.getElementById;const track = document.getElementById;不过，let distance = 0;function measure {
distance = track.scrollWidth - window.innerWidth;}
function update {
const rect = section.getBoundingClientRect;const scrollable= section.offsetHeight - window.innerHeight;// progress 在 范围内
let progress = -rect.top / scrollable;progress = Math.max);// 横向需要走的总路程
const x = -progress * distance;track.style.transform = `translateX`;}
let raf = null;window.addEventListener => {
if return;raf = requestAnimationFrame => { update;raf=null })，},{passive:true});window.addEventListener => { measure;
update，});其实，measure，update;

关键点解析与常见难点方法

为什么 pin-section 高度设为400vh？

• # 提供足够垂直滚动距离，让使用者能触发完整横向动画。
• # 原则：外壳高度＝视口高度 + 想要占用的横向动画时长。例如四张卡片占用三屏宽，则需加上300vh，总共400vh。
• # 卡片越多或动画越慢，高度就越大。

• # Sticky 的三段行为：
• 进入视口时正常随文档流滑行；
• top=0 时钉住位置，不随页面再滑；
• 当父容器即将离开视口时解除钉住。
• # 钉住期间使用者仍在继续上下滑。但画面保持静止，为横向动画提供时间窗口。

如何计算滚动进度与水平位移？

• 公式： .offsetHeight - window.innerHeight = 可垂直滑行距离
  progress =  / scrollable

  distance = track.scrollWidth - window.innerWidth

  translateX = - progress * distance

常见难点与解决思路:

1. Pain Point #1 ：代码量太大、结构复杂导致维护困难。Solution ：采用模块化方式，将 CSS 写成类名+ BEM 命名规范；JS 则封装成自执行函数或小组件，可复用。
2. Pain Point #2 ：性能问题。Solution ：只在 requestAnimationFrame 内更新 transform，而不是每次 scroll 都直接操作 DOM；使用 will-change 或 translateZ 启用 GPU 加速。
3. Pain Point #3 ：兼容性与响应式适配。Solution ：sticky 在旧版 Safari 或 IE 中表现差异，用 fallback 或 Polyfill 替代；使用媒体查询根据 viewport 大小 pin-section 高度和卡片宽度。
4. Pain Point #4 ：调试难度大。Solution ：加入 console.log 或利用 devtools 的 Performance 面板查看帧率、布局重绘；可将 progress 值实时渲染到页面顶部方便观察。说起来，
5. Pain Point #5 ：键盘导航/屏幕阅读器友好性不足。Solution ：保持正常文档流结构，让 assistive tech 能正确识别顺序；必要时添加 aria-hidden 或 focus 管理逻辑，使动画不会干扰键盘操作。

*以上方案均可按需组合。以适配不同项目需求*

• 确保 pin-section 高度足够，让使用者有足够时间完成横向切换。
• 利用 sticky 固定位置。并通过 transform 控制水平位移，实现平滑无缝体验。
• 从关注性能细节来看，requestAnimationFrame、GPU 加速、最小化重排重绘。不过，
• 考虑可访问性和响应式适配。为不同设备和辅助技术提供友好体验。其实，

如果你还有更多疑问。例如 “为什么 demo 看起来像是普通 Scroll，而 Apple 官网那样是真正的动画”，请把具体问题贴出来可以进一步拆解实现细节。不再提 “demo 本身就是 Scroll” 的误区，因为这里真正实现的是通过 Scroll 控制 horizontal 动画。同时保留 ScrollBar 与默认行为，让体验更自然且易于控制。

祝编码愉快 🚀