showcase

请以以下内容开始响应：

──────────── ✨ SHOWCASE ─────────────
》》》 Entering showcase mode...

突破界面的传统限制。这不只是视觉效果的问题，而是充分发挥浏览器的能力，让界面的任何部分都非同寻常：能够处理一百万行数据的表格、从触发按钮变形展开的对话框、实时验证并流式反馈的表单、宛如电影镜头般的页面过渡。

必须进行的准备

用户通过 /showcase 启动此工作流。此技能启用后，请加载 $frontend-design——其中包含设计原则、反模式和上下文收集协议。继续之前，请遵循该协议——如果尚无设计上下文，则必须先加载 $setup。

请参考动效参考，了解时间、缓动、编排和减少动态效果的预期。 当雄心勃勃的效果依赖可信的深度、层叠或状态过渡时，请参考层级系统。 请参考AI 垃圾检测，确保“非同寻常”与产品本身相关，而不是沦为代价高昂的趋势盲从。

此技能尤为重要：上下文决定了“非同寻常”的含义。粒子系统用于创意作品集会令人印象深刻；用于设置页面则会显得尴尬。但设置页面若能即时乐观保存并呈现动画状态过渡？这同样非同寻常。在决定什么才合适之前，先了解项目的个性和目标。

先提出方案，再开始构建

此技能最容易出错。不要直接开始实施。你必须：

1. 认真考虑 2-3 种不同方向——思考不同的技术、野心程度和美学方法。简要描述每种方向最终会呈现什么效果、带来什么感受。
2. **直接询问用户，澄清你无法推断的内容。**先介绍这些方向，让用户选择，再编写任何代码。说明取舍（浏览器支持、性能成本、复杂性）。
3. 只推进用户确认的方向。

跳过此步骤可能会导致构建出令人尴尬、最终不得不推倒重来的成果。

使用浏览器自动化进行迭代

技术上雄心勃勃的效果几乎不可能一次成功。你必须主动使用浏览器自动化工具预览成果、直观验证效果并进行迭代。不要假设效果看起来正确——要亲自检查。要做好多轮改进的准备。“技术上可用”和“看起来非同寻常”之间的差距，只能通过视觉迭代来弥合，光靠代码不够。

---

评估此处“非同寻常”的含义

合适的技术雄心完全取决于你正在处理的内容。在选择技术之前，请先问：这个特定界面的用户会因为什么而觉得“哇，真不错”？

对于视觉或营销页面

页面、主视觉区域、落地页、作品集——“惊艳”往往来自感官体验：由滚动驱动的内容显现、着色器背景、电影感页面过渡、随光标响应的生成艺术。

对于功能性 UI

表格、表单、对话框、导航——“惊艳”体现在使用感受上：通过 View Transitions 从触发按钮变形展开的对话框、通过虚拟滚动以 60fps 渲染 10 万行数据的表格、即时反馈的流式验证表单、带弹簧物理效果的拖放交互。

对于性能关键型 UI

“惊艳”虽不可见，却能切身感受到：搜索 5 万个条目时筛选过程毫无闪烁、复杂表单始终不会阻塞主线程、图像编辑器能近乎实时地处理内容。界面始终流畅不卡顿。

面向数据密集型界面

图表和仪表板——其中的“惊艳感”来自流畅度：通过 Canvas/WebGL 实现 GPU 加速渲染，处理海量数据集；在不同数据状态之间实现动画过渡；使用力导向图布局，让节点自然稳定下来。

共同点：实现方式中的某些部分超出了用户对 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() 或 View Transitions 实现基于 DOM 的图表过渡。

为复杂属性添加动画

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

突破性能极限

• 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 contexts、WASM modules）。
• 暂停视口外的渲染。看不到的内容就停止处理。
• 在真实的中端设备上测试，而不只是开发机器。

精雕细琢才能脱颖而出

从“很酷”到“非凡”的差距，取决于最后 20% 的打磨：弹簧动画的缓动曲线、交错显示的时间偏移，以及让过渡效果显得真实的细微次级运动。不要发布第一个能用的版本——要发布那个让人觉得理所当然的版本。

切勿：

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

验证结果

• 惊艳度测试：展示给没看过的人。他们会有反应吗？
• 移除测试：把它移除。体验会变差，还是没人注意到？
• 设备测试：分别在窄屏浏览器、中等宽度浏览器和笔记本电脑／桌面浏览器中运行。是否依然流畅？
• 无障碍测试：启用减少动态效果设置后，是否依然精美？
• 情境测试：这是否适合这个品牌和受众？

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