Front-End-Checklist 动画性能规范只用 transform 与 opacity 驱动 60fps 合成器动画【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist在 CSS 动效开发中一个高频误区是用top、left、width、height等布局属性做动画导致每帧都触发完整的浏览器渲染管线。本篇以 Front-End-Checklist 仓库中animation-performance规则规则文档、Skill 定义、内容集 MDX为骨架讲透浏览器渲染管线、属性选择的原则以及位移/尺寸动画的 transform 化改造、will-change与prefers-reduced-motion的工程化落地。读完你将掌握一套可评审、可复现的 60fps 动画写法并能直接对照仓库源码与测试验证标准进行实践。规则速览一条高优 CSS 性能规则该规则在仓库中的定位非常明确priority: high、difficulty: intermediate、estimatedTime: 20分钟属于css分类下的performance子类规则原始出处为 frontendchecklist.io见 SKILL.md 的 frontmatter 与 MDX 元数据。其核心主张用一句话概括只用 CSStransform与opacity做动画让动效跑在 GPU 合成器线程上维持 60fps避免动画top、left、width、height这类会触发布局的属性。仓库同时为这条规则提供了两种载体本质同一份知识、两种用途面向人类的规则页packages/content/rules/en/css/animation-performance.mdx 是内容集content collection中的正式规则条目带完整的 frontmattertldr、whyItMatters、relatedRules、tools、prompts、aiContext面向 Agent 的 Skillskills/animation-performance/SKILL.md 把规则拆成Check找出动画了布局属性的选择器→Fix改用 transform 等价物→Explain讲清渲染管线与 GPU 合成器→Code Review在渲染 UI 中断言违规选择器四个可执行步骤references/rule.md 则承载完整的代码示例与验证清单。浏览器渲染管线为什么属性选择决定帧率规则文档开篇就给出了理解一切的模型——浏览器渲染页面的四步管线Style → Layout → Paint → Composite每一步的含义Style样式计算匹配选择器、解析 CSS 规则得到每个元素的最终样式Layout布局/回流根据盒模型计算几何位置与尺寸Paint绘制把像素绘制到多个图层Composite合成把图层在 GPU 上按合成器线程拼合输出。动画某条属性时浏览器必须重跑管线中该属性所依赖的环节。动画「错误」的属性会让管线每一帧从头到尾完整重跑一遍而动画transform和opacity只会触发最后一步 Composite——因为这两类属性的变化不需要重新计算几何、也不需要重新绘制像素浏览器可以只对已有图层做平移、缩放、旋转和透明度合成。仓库规则把属性明确分成三档见 rule.md 与 animation-performance.mdxLayout-triggering properties避免动画触发完整重排: width, height, margin, padding, top, left, right, bottom, border-width, font-size, display, position Paint-triggering properties可接受但不理想触发重绘: color, background-color, box-shadow, border-color, outline, text-shadow Compositor-only properties动画最优只走合成: transform (translate, scale, rotate, skew) opacity filter (on composited layers)实战中记住这条判断链即可先问会不会触发 Layout再问会不会触发 Paint只有transform/opacity能跳过两者直达合成。为什么重要主线程竞争与掉帧规则文档的whyItMatters字段MDX 元数据与正文都强调了后果动画width、height、top、margin等布局属性每帧都要执行样式重算、布局、绘制、合成而这些全部跑在主线程上主线程同时还要执行 JavaScript两者争抢资源长任务会直接导致掉帧、卡顿、CLS布局偏移而transform/opacity的动画完全跳过布局与绘制运行在独立的 GPU 合成器线程上即使主线程被 JS 占满动效依然能保持流畅的 60fps。这也是为什么看起来只是换一个属性的改动实际影响的是整页交互流畅度。实战改造一位移动画 left → translateX规则文档给出了最典型的坏→好对照rule.md/* ❌ Bad: animates layout properties — triggers full reflow each frame */ .slide-in { animation: slideIn 300ms ease-out; } keyframes slideIn { from { left: -100%; } to { left: 0; } } /* ✅ Good: translate() is compositor-only */ .slide-in { animation: slideIn 300ms ease-out; } keyframes slideIn { from { transform: translateX(-100%); } to { transform: translateX(0); } }改动要点left: -100% → 0每帧触发回流reflow元素从左滑入时布局系统需要每帧重算几何translateX(-100%) → translateX(0)是纯合成操作浏览器只需在合成器线程平移已绘制的图层视觉结果一致性能开销却从全管线降为仅合成。实战改造二尺寸动画 width/height → scale同理尺寸动画用scale()替代rule.md/* ❌ Animates width/height — expensive */ .expand { animation: expand 300ms ease; } keyframes expand { from { width: 0; height: 0; } to { width: 200px; height: 200px; } } /* ✅ Use scale() */ .expand { width: 200px; height: 200px; animation: expand 300ms ease; } keyframes expand { from { transform: scale(0); } to { transform: scale(1); } }要点尺寸动画的本质是从 0 放大到目标尺寸把静态尺寸写死在元素上用scale(0 → 1)表达动画过程注意scale()放大的是视觉尺寸元素的布局占位不受影响。若你的需求是展开后挤压周围内容如手风琴折叠面板那必须动画height——此时应认识到这是有意的布局动画并评估范围与代价见下文仓库真实实践。常用高性能动效模式规则文档给出三个可直接复用的高频模式rule.md/* Fade in */ .fade-in { animation: fadeIn 300ms ease; } keyframes fadeIn { from { opacity: 0; } to { opacity: 1; } } /* Slide up and fade in */ .slide-up { animation: slideUp 400ms cubic-bezier(0.16, 1, 0.3, 1); } keyframes slideUp { from { opacity: 0; transform: translateY(16px); } to { opacity: 1; transform: translateY(0); } } /* Button press */ .button:active { transform: scale(0.97); }淡入淡出只动画opacity零布局代价上滑 淡入opacity与translateY组合两者都是合成友好属性cubic-bezier(0.16, 1, 0.3, 1)是典型的快入慢出ease-out 变体缓动常用于入场动效按钮按压:active时scale(0.97)用变换表达按下反馈不需要动画帧循环。will-change谨慎使用的层提升提示will-change用于在动画开始前提示浏览器把元素提升到独立合成层rule.md/* Hint to browser to promote this element to its own layer before animation starts */ .animated-card { will-change: transform; } /* ⚠️ Dont apply to too many elements — each layer uses GPU memory */ /* Apply just before animation, remove after */使用边界规则文档明确强调不要批量滥用每个独立合成层都占用 GPU 内存几十个will-change元素可能反而拖垮低端设备按需开启、用完即关最理想的做法是在动画即将开始的时刻用 JS 加上、动画结束后移除避免常驻层很多时候浏览器能自动判定并提升动画中的合成属性will-change只在出现闪烁、卡顿等可观测问题时作为优化手段而非默认配置。尊重用户偏好prefers-reduced-motion无障碍是这条规则不可分割的一部分。规则文档给出两种实现方式rule.md/* ✅ Always honor the users motion preferences */ .slide-in { animation: slideIn 400ms ease; } media (prefers-reduced-motion: reduce) { .slide-in { animation: none; /* Provide a non-animated alternative if needed */ } } /* Or use the safe pattern */ media (prefers-reduced-motion: no-preference) { .slide-in { animation: slideIn 400ms ease; } }两种写法的语义差异值得说明reduce分支禁用默认开启动效仅在用户系统开启减少动态效果时关闭改动面最小no-preference分支启用默认无动效只有用户未声明减少动效时才开启对动效敏感用户更安全规则文档建议若动效被禁用且内容依赖动画传递状态需提供非动画替代方案。仓库真实实践一合成友好写法与不得已的布局动画Front-End-Checklist 自己的前端apps/web就是这条规则的活教材。在 apps/web/app/globals.css 的 Animation Motion 区块中两种模式并存正确示范——marquee 走translateY/* Mentions section marquee (vertical scroll) */ keyframes mentions-marquee { from { transform: translateY(0); } to { transform: translateY(-50%); } }滚动跑马灯用transform: translateY(-50%)实现位移正是规则推荐的合成友好写法帧率不受主线程负载影响。需要权衡的案例——手风琴动画heightkeyframes accordion-down { from { height: 0; opacity: 0; } to { height: var(--radix-accordion-content-height); opacity: 1; } } keyframes accordion-up { from { height: var(--radix-accordion-content-height); opacity: 1; } to { height: 0; opacity: 0; } }这里动画了height配合 Radix 折叠面板的--radix-accordion-content-height变量属于规则明示应避免的布局属性。但从源码结构看这属于规则文档所说的不得不影响布局的场景——折叠展开必须挤压周围内容height动画是语义正确的实现。opacity的加入则至少把透明度部分放在合成器线程。这类案例说明规则不是教条而是提供成本排序——能合成就合成必须布局时则限制范围、控制时长此处 200ms、并保持层与状态的确定性。仓库真实实践二工程化的 reduced-motion 降级仓库对 reduced motion 的落地是全局兜底而非逐个选择器处理apps/web/app/globals.css/* Respect reduced motion */ media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: 0.01ms; animation-iteration-count: 1; transition-duration: 0.01ms; scroll-behavior: auto; } }这段全局规则的工程智慧用*通配覆盖所有元素包括伪元素避免遗漏不直接display: none动画而是把animation-duration压到 0.01ms 且只执行一次、transition-duration压到 0.01ms——保留动画的完成态与元素可见性同时把动效时间压缩到人眼不可感知scroll-behavior: auto同时禁用平滑滚动。如果需要在 JS 侧感知用户偏好仓库提供了 hydration 安全的 React Hookapps/web/hooks/use-reduced-motion-preference.tsuse client import { useSyncExternalStore } from react const reducedMotionQuery (prefers-reduced-motion: reduce) function subscribeToReducedMotion(onStoreChange: () void) { const mediaQuery window.matchMedia(reducedMotionQuery) mediaQuery.addEventListener(change, onStoreChange) return () mediaQuery.removeEventListener(change, onStoreChange) } function getReducedMotionSnapshot() { return window.matchMedia(reducedMotionQuery).matches } function getServerReducedMotionSnapshot() { return false } export function useReducedMotionPreference() { return useSyncExternalStore( subscribeToReducedMotion, getReducedMotionSnapshot, getServerReducedMotionSnapshot ) }实现要点基于useSyncExternalStore订阅window.matchMedia((prefers-reduced-motion: reduce))用户实时切换系统设置时 Hook 会同步更新getServerReducedMotionSnapshot在 SSR 阶段返回false作为服务端回退值避免 hydration mismatch仓库另有非 React 的轻量读取实现apps/web/lib/accessibility/preferences.ts直接返回window.matchMedia(...).matches。配合 CSS 的no-preference分支写法可以实现JS 感知偏好 CSS 兜底禁用的双保险。在 Front-End-Checklist 生态中的位置规则即代码这条规则在仓库中不是孤立的文档而是一套可被人类与 Agent 共同消费的结构化数据见 animation-performance.mdx 的 frontmatter结构化摘要tldr字段沉淀四条要点只有 transform/opacity 可免布局合成、will-change 谨慎使用、优先 CSS 而非 JS 动画库、尊重 prefers-reduced-motion关联规则relatedRules列出协作评审对象——css-containmentCSS 包含性同样限制动画元素渲染范围、viewport-zoom影响布局的动画会干扰缩放无障碍、dimensions、view-transitions同属 css 质量评审范畴推荐工具Chrome DevTools Rendering 面板可开启 Paint flashing / Layer borders 可视化调试与 MDNprefers-reduced-motion参考页Agent 提示词check/fix/explain/codeReview四段提示词让 AI Agent 能按找违规→给修复→讲原理→审代码的流程直接参与评审这也正是 skills/animation-performance/SKILL.md 中 Quick Reference 与四步工作流的来源。验证清单上线前逐条确认规则文档给出了明确的验证步骤rule.md检查渲染 UI在受规则影响的所有断点与交互状态下检查渲染结果确认动画在响应式布局下不越界、不错位核对计算样式在 DevTools 中确认 computed styles 与预期修复一致例如元素最终transform值、opacity值多端测试上线前至少在一个移动端视口和一个桌面端视口实测动画流畅度面向结果验证如果规则影响动效、对比度或布局稳定性直接验证这些用户可见的结果例如 reduced-motion 用户是否看到瞬时完成的等价状态。小结回到规则的核心心智模型渲染管线 Style → Layout → Paint → Composite动画每帧重跑越靠前的环节主线程负担越重把动画收敛到只触发 Composite 的transform/opacity动效就交给 GPU 合成器线程60fps 才有保障。落地时只需四步自查位移用translate、尺寸用scale、透明度用opacity、will-change按需开关再叠加prefers-reduced-motion的全局降级就能同时兼顾性能与无障碍。Front-End-Checklist 仓库的 规则文档、MDX 内容 与 前端源码实践 互为印证是值得反复对照的参考基准。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Front-End-Checklist 动画性能规范：只用 transform 与 opacity 驱动 60fps 合成器动画
Front-End-Checklist 动画性能规范只用 transform 与 opacity 驱动 60fps 合成器动画【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist在 CSS 动效开发中一个高频误区是用top、left、width、height等布局属性做动画导致每帧都触发完整的浏览器渲染管线。本篇以 Front-End-Checklist 仓库中animation-performance规则规则文档、Skill 定义、内容集 MDX为骨架讲透浏览器渲染管线、属性选择的原则以及位移/尺寸动画的 transform 化改造、will-change与prefers-reduced-motion的工程化落地。读完你将掌握一套可评审、可复现的 60fps 动画写法并能直接对照仓库源码与测试验证标准进行实践。规则速览一条高优 CSS 性能规则该规则在仓库中的定位非常明确priority: high、difficulty: intermediate、estimatedTime: 20分钟属于css分类下的performance子类规则原始出处为 frontendchecklist.io见 SKILL.md 的 frontmatter 与 MDX 元数据。其核心主张用一句话概括只用 CSStransform与opacity做动画让动效跑在 GPU 合成器线程上维持 60fps避免动画top、left、width、height这类会触发布局的属性。仓库同时为这条规则提供了两种载体本质同一份知识、两种用途面向人类的规则页packages/content/rules/en/css/animation-performance.mdx 是内容集content collection中的正式规则条目带完整的 frontmattertldr、whyItMatters、relatedRules、tools、prompts、aiContext面向 Agent 的 Skillskills/animation-performance/SKILL.md 把规则拆成Check找出动画了布局属性的选择器→Fix改用 transform 等价物→Explain讲清渲染管线与 GPU 合成器→Code Review在渲染 UI 中断言违规选择器四个可执行步骤references/rule.md 则承载完整的代码示例与验证清单。浏览器渲染管线为什么属性选择决定帧率规则文档开篇就给出了理解一切的模型——浏览器渲染页面的四步管线Style → Layout → Paint → Composite每一步的含义Style样式计算匹配选择器、解析 CSS 规则得到每个元素的最终样式Layout布局/回流根据盒模型计算几何位置与尺寸Paint绘制把像素绘制到多个图层Composite合成把图层在 GPU 上按合成器线程拼合输出。动画某条属性时浏览器必须重跑管线中该属性所依赖的环节。动画「错误」的属性会让管线每一帧从头到尾完整重跑一遍而动画transform和opacity只会触发最后一步 Composite——因为这两类属性的变化不需要重新计算几何、也不需要重新绘制像素浏览器可以只对已有图层做平移、缩放、旋转和透明度合成。仓库规则把属性明确分成三档见 rule.md 与 animation-performance.mdxLayout-triggering properties避免动画触发完整重排: width, height, margin, padding, top, left, right, bottom, border-width, font-size, display, position Paint-triggering properties可接受但不理想触发重绘: color, background-color, box-shadow, border-color, outline, text-shadow Compositor-only properties动画最优只走合成: transform (translate, scale, rotate, skew) opacity filter (on composited layers)实战中记住这条判断链即可先问会不会触发 Layout再问会不会触发 Paint只有transform/opacity能跳过两者直达合成。为什么重要主线程竞争与掉帧规则文档的whyItMatters字段MDX 元数据与正文都强调了后果动画width、height、top、margin等布局属性每帧都要执行样式重算、布局、绘制、合成而这些全部跑在主线程上主线程同时还要执行 JavaScript两者争抢资源长任务会直接导致掉帧、卡顿、CLS布局偏移而transform/opacity的动画完全跳过布局与绘制运行在独立的 GPU 合成器线程上即使主线程被 JS 占满动效依然能保持流畅的 60fps。这也是为什么看起来只是换一个属性的改动实际影响的是整页交互流畅度。实战改造一位移动画 left → translateX规则文档给出了最典型的坏→好对照rule.md/* ❌ Bad: animates layout properties — triggers full reflow each frame */ .slide-in { animation: slideIn 300ms ease-out; } keyframes slideIn { from { left: -100%; } to { left: 0; } } /* ✅ Good: translate() is compositor-only */ .slide-in { animation: slideIn 300ms ease-out; } keyframes slideIn { from { transform: translateX(-100%); } to { transform: translateX(0); } }改动要点left: -100% → 0每帧触发回流reflow元素从左滑入时布局系统需要每帧重算几何translateX(-100%) → translateX(0)是纯合成操作浏览器只需在合成器线程平移已绘制的图层视觉结果一致性能开销却从全管线降为仅合成。实战改造二尺寸动画 width/height → scale同理尺寸动画用scale()替代rule.md/* ❌ Animates width/height — expensive */ .expand { animation: expand 300ms ease; } keyframes expand { from { width: 0; height: 0; } to { width: 200px; height: 200px; } } /* ✅ Use scale() */ .expand { width: 200px; height: 200px; animation: expand 300ms ease; } keyframes expand { from { transform: scale(0); } to { transform: scale(1); } }要点尺寸动画的本质是从 0 放大到目标尺寸把静态尺寸写死在元素上用scale(0 → 1)表达动画过程注意scale()放大的是视觉尺寸元素的布局占位不受影响。若你的需求是展开后挤压周围内容如手风琴折叠面板那必须动画height——此时应认识到这是有意的布局动画并评估范围与代价见下文仓库真实实践。常用高性能动效模式规则文档给出三个可直接复用的高频模式rule.md/* Fade in */ .fade-in { animation: fadeIn 300ms ease; } keyframes fadeIn { from { opacity: 0; } to { opacity: 1; } } /* Slide up and fade in */ .slide-up { animation: slideUp 400ms cubic-bezier(0.16, 1, 0.3, 1); } keyframes slideUp { from { opacity: 0; transform: translateY(16px); } to { opacity: 1; transform: translateY(0); } } /* Button press */ .button:active { transform: scale(0.97); }淡入淡出只动画opacity零布局代价上滑 淡入opacity与translateY组合两者都是合成友好属性cubic-bezier(0.16, 1, 0.3, 1)是典型的快入慢出ease-out 变体缓动常用于入场动效按钮按压:active时scale(0.97)用变换表达按下反馈不需要动画帧循环。will-change谨慎使用的层提升提示will-change用于在动画开始前提示浏览器把元素提升到独立合成层rule.md/* Hint to browser to promote this element to its own layer before animation starts */ .animated-card { will-change: transform; } /* ⚠️ Dont apply to too many elements — each layer uses GPU memory */ /* Apply just before animation, remove after */使用边界规则文档明确强调不要批量滥用每个独立合成层都占用 GPU 内存几十个will-change元素可能反而拖垮低端设备按需开启、用完即关最理想的做法是在动画即将开始的时刻用 JS 加上、动画结束后移除避免常驻层很多时候浏览器能自动判定并提升动画中的合成属性will-change只在出现闪烁、卡顿等可观测问题时作为优化手段而非默认配置。尊重用户偏好prefers-reduced-motion无障碍是这条规则不可分割的一部分。规则文档给出两种实现方式rule.md/* ✅ Always honor the users motion preferences */ .slide-in { animation: slideIn 400ms ease; } media (prefers-reduced-motion: reduce) { .slide-in { animation: none; /* Provide a non-animated alternative if needed */ } } /* Or use the safe pattern */ media (prefers-reduced-motion: no-preference) { .slide-in { animation: slideIn 400ms ease; } }两种写法的语义差异值得说明reduce分支禁用默认开启动效仅在用户系统开启减少动态效果时关闭改动面最小no-preference分支启用默认无动效只有用户未声明减少动效时才开启对动效敏感用户更安全规则文档建议若动效被禁用且内容依赖动画传递状态需提供非动画替代方案。仓库真实实践一合成友好写法与不得已的布局动画Front-End-Checklist 自己的前端apps/web就是这条规则的活教材。在 apps/web/app/globals.css 的 Animation Motion 区块中两种模式并存正确示范——marquee 走translateY/* Mentions section marquee (vertical scroll) */ keyframes mentions-marquee { from { transform: translateY(0); } to { transform: translateY(-50%); } }滚动跑马灯用transform: translateY(-50%)实现位移正是规则推荐的合成友好写法帧率不受主线程负载影响。需要权衡的案例——手风琴动画heightkeyframes accordion-down { from { height: 0; opacity: 0; } to { height: var(--radix-accordion-content-height); opacity: 1; } } keyframes accordion-up { from { height: var(--radix-accordion-content-height); opacity: 1; } to { height: 0; opacity: 0; } }这里动画了height配合 Radix 折叠面板的--radix-accordion-content-height变量属于规则明示应避免的布局属性。但从源码结构看这属于规则文档所说的不得不影响布局的场景——折叠展开必须挤压周围内容height动画是语义正确的实现。opacity的加入则至少把透明度部分放在合成器线程。这类案例说明规则不是教条而是提供成本排序——能合成就合成必须布局时则限制范围、控制时长此处 200ms、并保持层与状态的确定性。仓库真实实践二工程化的 reduced-motion 降级仓库对 reduced motion 的落地是全局兜底而非逐个选择器处理apps/web/app/globals.css/* Respect reduced motion */ media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: 0.01ms; animation-iteration-count: 1; transition-duration: 0.01ms; scroll-behavior: auto; } }这段全局规则的工程智慧用*通配覆盖所有元素包括伪元素避免遗漏不直接display: none动画而是把animation-duration压到 0.01ms 且只执行一次、transition-duration压到 0.01ms——保留动画的完成态与元素可见性同时把动效时间压缩到人眼不可感知scroll-behavior: auto同时禁用平滑滚动。如果需要在 JS 侧感知用户偏好仓库提供了 hydration 安全的 React Hookapps/web/hooks/use-reduced-motion-preference.tsuse client import { useSyncExternalStore } from react const reducedMotionQuery (prefers-reduced-motion: reduce) function subscribeToReducedMotion(onStoreChange: () void) { const mediaQuery window.matchMedia(reducedMotionQuery) mediaQuery.addEventListener(change, onStoreChange) return () mediaQuery.removeEventListener(change, onStoreChange) } function getReducedMotionSnapshot() { return window.matchMedia(reducedMotionQuery).matches } function getServerReducedMotionSnapshot() { return false } export function useReducedMotionPreference() { return useSyncExternalStore( subscribeToReducedMotion, getReducedMotionSnapshot, getServerReducedMotionSnapshot ) }实现要点基于useSyncExternalStore订阅window.matchMedia((prefers-reduced-motion: reduce))用户实时切换系统设置时 Hook 会同步更新getServerReducedMotionSnapshot在 SSR 阶段返回false作为服务端回退值避免 hydration mismatch仓库另有非 React 的轻量读取实现apps/web/lib/accessibility/preferences.ts直接返回window.matchMedia(...).matches。配合 CSS 的no-preference分支写法可以实现JS 感知偏好 CSS 兜底禁用的双保险。在 Front-End-Checklist 生态中的位置规则即代码这条规则在仓库中不是孤立的文档而是一套可被人类与 Agent 共同消费的结构化数据见 animation-performance.mdx 的 frontmatter结构化摘要tldr字段沉淀四条要点只有 transform/opacity 可免布局合成、will-change 谨慎使用、优先 CSS 而非 JS 动画库、尊重 prefers-reduced-motion关联规则relatedRules列出协作评审对象——css-containmentCSS 包含性同样限制动画元素渲染范围、viewport-zoom影响布局的动画会干扰缩放无障碍、dimensions、view-transitions同属 css 质量评审范畴推荐工具Chrome DevTools Rendering 面板可开启 Paint flashing / Layer borders 可视化调试与 MDNprefers-reduced-motion参考页Agent 提示词check/fix/explain/codeReview四段提示词让 AI Agent 能按找违规→给修复→讲原理→审代码的流程直接参与评审这也正是 skills/animation-performance/SKILL.md 中 Quick Reference 与四步工作流的来源。验证清单上线前逐条确认规则文档给出了明确的验证步骤rule.md检查渲染 UI在受规则影响的所有断点与交互状态下检查渲染结果确认动画在响应式布局下不越界、不错位核对计算样式在 DevTools 中确认 computed styles 与预期修复一致例如元素最终transform值、opacity值多端测试上线前至少在一个移动端视口和一个桌面端视口实测动画流畅度面向结果验证如果规则影响动效、对比度或布局稳定性直接验证这些用户可见的结果例如 reduced-motion 用户是否看到瞬时完成的等价状态。小结回到规则的核心心智模型渲染管线 Style → Layout → Paint → Composite动画每帧重跑越靠前的环节主线程负担越重把动画收敛到只触发 Composite 的transform/opacity动效就交给 GPU 合成器线程60fps 才有保障。落地时只需四步自查位移用translate、尺寸用scale、透明度用opacity、will-change按需开关再叠加prefers-reduced-motion的全局降级就能同时兼顾性能与无障碍。Front-End-Checklist 仓库的 规则文档、MDX 内容 与 前端源码实践 互为印证是值得反复对照的参考基准。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考