overdrive

请以以下内容开头：

──────────── ⚡ OVERDRIVE ─────────────
》》》 Entering overdrive mode...

突破界面的传统限制。这不仅关乎视觉效果，更关乎充分发挥浏览器的能力，让界面的任何部分都显得非同寻常：能够处理一百万行数据的表格、从触发按钮变形展开的对话框、实时验证并流式反馈的表单、如电影般流畅的页面转场。

必须的准备工作

调用 /impeccable — 其中包含设计原则、反模式和上下文收集协议。继续之前，请遵循该协议 — 如果目前还没有设计上下文，必须先运行 /impeccable teach。

对这项技能尤为重要：上下文决定了什么才称得上“非同寻常”。粒子系统用于创意作品集会让人印象深刻，用在设置页面上却会显得尴尬。不过，设置页面若能即时乐观保存并带有动画状态转场，同样非同寻常。在决定采用什么方案之前，请先了解项目的个性和目标。

先提方案，再动手实现

这项技能最容易用错。不要直接开始实现。你必须：

1. 认真考虑 2-3 种不同方案——考虑不同的技术、雄心程度和美学方向。简要描述每种方案最终呈现的视觉效果和体验。
2. **直接询问用户，澄清你无法推断的内容。**先展示这些方案，并在编写任何代码之前征求用户的选择。说明各方案的权衡（浏览器支持、性能开销、复杂度）。
3. 仅按用户确认的方案继续。

跳过这一步，可能会做出令人尴尬、最终只能丢弃的设计。

借助浏览器自动化迭代

技术上复杂的效果几乎不可能一次就做好。你必须主动使用浏览器自动化工具预览成果、直观验证效果并进行迭代。不要想当然地认为效果不错——要实际检查。做好多轮调整的准备。只有通过视觉迭代，而非单靠代码，才能弥合“技术上能用”和“视觉上非同寻常”之间的差距。

---

评估此处的“非同寻常”意味着什么

技术上的雄心应该达到什么程度，完全取决于你正在处理的内容。选择技术之前，请先问自己：怎样才能让这个特定界面的用户觉得“哇，真不错”？

对于视觉或营销类界面

页面、主视觉区域、落地页、作品集——令人惊艳之处往往在于感官体验：由滚动驱动的内容显现、着色器背景、电影感页面转场、会随光标响应的生成式艺术。

对于功能型 UI

表格、表单、对话框、导航——令人惊艳之处在于使用感受：借助 View Transitions 从触发按钮变形展开的对话框、通过虚拟滚动以 60fps 渲染 100k 行数据的表格、即时响应的流式验证表单、带有弹簧物理效果的拖放交互。

对于性能关键型 UI

令人惊艳之处虽不可见，却能让人切实感受到：搜索 50k 个项目时毫无卡顿，复杂表单不会阻塞主线程，图像编辑器能够近乎实时地处理图像。整个界面始终流畅响应。

对于数据密集型界面

图表和仪表板——令人惊艳之处在于流畅：通过 Canvas/WebGL 加速渲染海量数据，在不同数据状态间进行动画转场，让力导向图自然稳定下来。

共同点：实现方式超出了用户对 Web 界面的预期。技术应服务于体验，而非本末倒置。

工具集

按目标组织，而非按技术名称分类。

让过渡效果更具电影感

• View Transitions API（同一文档：所有浏览器；跨文档：Firefox 不支持）——在不同状态间实现共享元素变形。例如，列表项展开为详情页，按钮变形为对话框。这是最接近原生 FLIP 动画的方案。
• @starting-style（所有浏览器）——仅用 CSS 就能让元素从 display: none 变为可见，并包含入场关键帧
• 弹簧物理效果——用质量、张力和阻尼实现自然运动，而非 cubic-bezier。可用库：motion（原名 Framer Motion）、GSAP，或自行实现弹簧求解器。

让动画跟随滚动位置

• 滚动驱动动画（animation-timeline: scroll()）——纯 CSS，无需 JS。视差、进度条、渐显序列都由滚动位置驱动。（Chrome/Edge/Safari；Firefox：仅支持实验性标志——始终提供静态后备方案）

渲染超越 CSS 的效果

• WebGL（所有浏览器）——着色器效果、后期处理、粒子系统。可用库：Three.js、OGL（轻量级）、regl。适用于 CSS 无法实现的效果。
• WebGPU（Chrome/Edge；Safari 部分支持；Firefox：仅支持实验性标志）——新一代 GPU 计算。功能比 WebGL 更强，但浏览器支持有限。始终回退到 WebGL2。
• Canvas 2D / OffscreenCanvas——自定义渲染、像素处理，或通过 Web Workers + OffscreenCanvas 将繁重的渲染任务完全移出主线程。
• SVG 滤镜链——位移贴图、湍流、形态学运算，可实现自然有机的扭曲效果。可用 CSS 动画。

让数据鲜活起来

• 虚拟滚动——对于包含数万条数据的表格/列表，仅渲染可见行。简单场景无需库；复杂场景可用 TanStack Virtual。
• GPU 加速图表——对于数据量过大、无法用 SVG/DOM 渲染的数据集，使用 Canvas 或 WebGL 渲染数据可视化。可用库：deck.gl、基于 regl 的自定义渲染器。
• 数据过渡动画——在图表状态之间实现变形，而非直接替换。可使用 D3 的 transition()，或用于基于 DOM 的图表的 View Transitions。

为复杂属性添加动画

• @property（所有浏览器）——注册带有类型的自定义 CSS 属性，从而为渐变、颜色及 CSS 通常无法插值的复杂值添加动画。
• Web Animations API（所有浏览器）——以 CSS 的性能运行由 JavaScript 驱动的动画。可组合、可取消、可反向播放，是实现复杂编排的基础。

挑战性能极限

• Web Workers——将计算任务移出主线程。繁重的数据处理、图像操作、搜索索引等任何会造成卡顿的任务都适用。
• OffscreenCanvas——在 Worker 线程中渲染。复杂视觉效果在后台渲染，同时主线程保持空闲。
• WASM——为计算密集型功能提供近乎原生的性能。适用于图像处理、物理模拟、编解码器。

与设备交互

• Web Audio API——空间音频、音频响应式可视化、声音反馈。启动时需要用户手势。
• 设备 API——方向、环境光、地理位置。谨慎使用，并始终征得用户许可。

注意：这项技能旨在提升界面的感受，而非改变产品的功能。添加实时协作、离线支持或新的后端功能属于产品决策，而非 UI 增强。重点是让现有功能带来非凡体验。

有章法地实现

渐进增强不容妥协

每种技术都必须能够平滑降级。即使没有增强效果，体验也必须依然出色。

@supports (animation-timeline: scroll()) {
  .hero { animation-timeline: scroll(); }
}

if ('gpu' in navigator) { /* WebGPU */ }
else if (canvas.getContext('webgl2')) { /* WebGL2 fallback */ }
/* CSS-only fallback must still look good */

性能规则

• 目标是 60fps。若低于 50fps，则简化效果。
• 始终尊重 prefers-reduced-motion。提供精美的静态替代方案。
• 仅在接近视口时才延迟初始化占用资源较多的功能（WebGL 上下文、WASM 模块）。
• 暂停视口外的渲染。停止所有不可见内容的渲染。
• 在真实的中端设备上测试，不要只在自己的开发机器上测试。

精雕细琢方显不凡

“很酷”和“非凡”之间的差距，在于最后 20% 的打磨：弹簧动画的缓动曲线、交错显现时的时间偏移，以及让过渡效果充满真实感的细微次级运动。不要交付第一个能用的版本，要交付让人觉得理所当然的版本。

绝不要：

• 忽略 prefers-reduced-motion——这是无障碍要求，不是建议
• 发布会让中端设备卡顿的效果
• 在没有可用回退方案的情况下使用前沿 API
• 未经用户明确选择就添加声音
• 用技术上的野心掩盖薄弱的设计基本功——先用其他技能解决这些问题
• 叠加多个相互争抢的非凡时刻——专注才能产生冲击力，过度则只会制造噪音

验证效果

• 惊艳度测试：展示给没见过的人看。他们会有反应吗？
• 移除测试：把它去掉。体验会变差，还是根本没人注意到？
• 设备测试：在手机、平板和 Chromebook 上运行。依然流畅吗？
• 无障碍测试：启用减少动态效果后，依然美观吗？
• 情境测试：这符合该品牌和受众的特点吗？

请记住：“技术上的非凡”不在于使用最新的 API，而在于让界面实现用户原以为网站做不到的事。