用@keyframes定义三段式缩放+透明度动画最直接：0%缩至0.95/0.8→30%达1.15/1→80%回1.02→100%归1/0.98，配0.9s非对称缓动与infinite both，兼顾真实感与兼容性。
用 @keyframes 定义缩放+透明度变化是最直接的方式
心跳本质是“收缩→舒张→短暂停顿”的节奏，CSS 里没法模拟生理搏动，但用 scale() 和 opacity 组合就能骗过眼睛。关键不是“跳”，而是“先快缩再慢回、带点余震感”。
常见错误是只写 scale(1.2) 往返，结果像机械振动，没有真实心跳的弹性。真正有效的是三段式节奏：快速收缩（0%→30%）、缓慢回弹（30%→80%）、微小二次波动（80%→100%）。
- 起始帧设为
scale(0.95) opacity(0.8)，避免从全尺寸开始显得突兀 - 30% 处缩到
scale(1.15) opacity(1)，制造“泵血”感 - 80% 回到
scale(1.02)，留一点余压，不是完全归零 - 100% 回到原态，但加
opacity(0.98)模拟毛细血管微循环的视觉衰减
animation 的时长和缓动必须匹配生理节奏
真实心跳间隔约 0.8–1.2 秒，但动画不能卡死这个值——人眼对重复节奏敏感，固定周期容易看出循环破绽。更稳妥的是用 0.9s 基础时长，配合 cubic-bezier(0.2, 0.8, 0.4, 1) 这类非对称缓动，让收缩快、回弹慢。
另一个坑是盲目套用 infinite。如果元素可能被 JS 频繁显隐，没加 animation-fill-mode: forwards 就会导致隐藏后再显示时从头闪一下。
立即学习“前端免费学习笔记（深入）”；
- 推荐写法：
animation: heartbeat 0.9s cubic-bezier(0.2, 0.8, 0.4, 1) infinite both - 如果需要暂停/重启，别用
display: none，改用visibility: hidden或opacity: 0，否则动画状态会重置 - 移动端要注意
transform触发硬件加速，但过度使用will-change: transform反而增加内存开销
兼容性问题集中在旧版 Safari 和 IE
IE 完全不支持 @keyframes，Safari 9–13 对 cubic-bezier() 的高阶参数支持不稳定，尤其 cubic-bezier(0.2, 0.8, 0.4, 1) 在 Safari 12 下可能退化成线性。
不需要 polyfill，但得降级处理：给 Safari 加前缀，对 IE 则直接 fallback 到静态样式。
- Safari 12–13 必须写两遍：
@-webkit-keyframes heartbeat { ... }和@keyframes heartbeat { ... } - IE11 及以下可加条件注释或用
@supports not (animation-name: heartbeat)关闭动画，只保留基础颜色呼吸效果 - 不要依赖
animation-play-state: paused做交互控制——部分安卓 WebView 对该属性响应延迟明显
性能陷阱：别在大量元素上同时跑心跳
每个心跳动画都会触发 layout → paint → composite 流程。如果页面有 20 个带心跳的按钮，低端安卓机可能掉帧。真正影响性能的不是缩放本身，而是 opacity 变化迫使浏览器频繁合成图层。
解决方案不是减少动画，而是用更轻量的替代路径。
- 优先用
transform: scale()+filter: blur(0.5px)替代opacity，模糊比透明度变化对 GPU 更友好 - 对非焦点元素（比如列表中未 hover 的项），用
animation-play-state: paused冻结，只在 hover 时激活 - 如果心跳只是状态提示，考虑用 CSS 变量控制单个动画实例，通过 JS 切换
--pulse-scale值，比启停多个 animation 实例更省
最常被忽略的一点：动画时间轴和用户操作不同步。比如点击按钮触发心跳，但没清空之前的动画状态，就会出现“叠加抖动”。每次手动触发动画前，记得先 element.style.animation = 'none' 强制重置，再设回完整 animation 值。
