必须用 SVG <path> 替代 <rect> 实现流动灯光边框，通过 stroke-dasharray 与 stroke-dashoffset 配合 CSS 动画驱动光点沿路径匀速移动，确保起点明确、长度精准、缩放稳定。
用 SVG + stroke-dasharray 实现流动灯光边框
直接给 <svg> 元素加 border 或 box-shadow 做不出“灯光流动”效果，必须靠 SVG 路径描边的动态控制。核心是把边框变成一条可测量、可分段、可偏移的路径，再用 stroke-dasharray 和 stroke-dashoffset 配合动画驱动“光点”沿路径移动。
常见错误是直接对 <rect> 或 <circle> 动画 stroke 颜色——这只能变色，不是流动；或误用 stroke-width 过渡，引发重排卡顿。
- 先用
<path d="M...Z">显式定义边框路径（比<rect>更可控，尤其带圆角或不规则形状时） - 调用 JS 的
getTotalLength()获取路径总长（如120），这是后续动画比例基准 - 设
stroke-dasharray="30 90"：实线段 30px 模拟“光点”，空白段 90px 控制间隔；总和等于路径全长可实现无缝循环 - 动画
stroke-dashoffset从0→-120，视觉上就是光点从起点匀速跑完一圈
为什么不用 <rect> 直接套 stroke？
<rect> 等基础形状虽支持 stroke，但它的路径拓扑固定，getTotalLength() 返回值在不同浏览器中可能有微小差异（尤其含 rx/ry 时），导致 stroke-dashoffset 动画首尾衔接错位——光点跑到角落会“跳帧”或停顿。
更麻烦的是，<rect> 的描边起点默认在左上角，但圆角矩形的“视觉起点”其实是顶部中间或左上圆弧中点，手动算 stroke-dashoffset 偏移量极其容易偏差。
立即学习“前端免费学习笔记（深入）”；
- 解决方案：用
<path>手动写出四段直线 + 四段圆弧（A命令），明确控制起点和方向 - 或用工具导出 SVG 路径（如 Figma → “Copy as SVG”），确保
d属性中第一个坐标即为动画起点 - 务必在
<path>上加vector-effect="non-scaling-stroke"，否则缩放时虚线密度会变
配合 CSS 动画触发与性能控制
纯 JS 控制 stroke-dashoffset 更新效率低且难维护，推荐用 CSS @keyframes 驱动，但要注意几个关键点：
- 动画名里不要用
linear关键字命名（如@keyframes linear），CSS 解析器会混淆为函数名，报错Invalid keyframe - 设
animation: dashflow 4s linear infinite，时间值需匹配stroke-dasharray总长 —— 若总长 120px，想光点每秒跑 30px，就设 4s - 避免在动画中同时改
stroke颜色：颜色过渡会触发重绘，而dashoffset是合成层属性，更高效 - 移动端快速悬停进出时，加
animation-play-state: paused在:hover里，防止动画堆叠卡住
兼容性与 fallback 处理
IE 早已不支持 stroke-dasharray 动画，Safari 12+ 开始稳定支持，但旧版 Safari 对 getTotalLength() 返回值精度偏低（±2px）。若需兼容 Safari 11 或更低版本，必须降级：
- 检测
SVGElement.prototype.getTotalLength是否存在，不存在则回退到静态双色边框（border: 2px solid #0af+box-shadow发光） - 不要依赖
will-change: stroke-dashoffset：实测在部分 Chrome 版本中反而增加 GPU 内存占用，不如直接用transform: translateZ(0)强制图层提升 - 若 SVG 边框需响应容器尺寸变化，监听
resize时重新调用getTotalLength()并重设stroke-dasharray，别用 CSSvw/vh单位写死数值
真正难的不是让光跑起来，而是让它在各种缩放、旋转、高 DPI 屏幕下始终严丝合缝地贴着边框走——路径定义和长度计算必须一手抓死，别交给浏览器猜。
