原生marquee或ellipsize="marquee"不可靠，因其为单次滑出→清空→重载→再滑入，存在视觉断层，且依赖焦点、无法控速/停顿/方向，不支持多行与图文混排；iOS及主流移动端浏览器已弱化或忽略支持。
为什么直接用 marquee 或 ellipsize="marquee" 不行
原生跑马灯（如 Android 的 TextView 设置 ellipsize="marquee"，或 HTML 的废弃 标签）本质是「单次滑出→清空→重载→再滑入」，中间有视觉断层；且依赖焦点、无法控制速度/停顿/方向，也不支持多行、图文混排。移动端 Safari 和 Chrome 对原生 marquee 支持早已弱化甚至忽略，iOS 上基本无效。
@keyframes + transform: translateX() 实现真正无缝滚动
核心思路是：让文本内容宽度 > 容器宽度，用 translateX 把它从右向左匀速拖动；当位移达到「负的文本宽度」时，立刻跳回 0，利用动画循环（animation-iteration-count: infinite）和时间函数（linear）掩盖跳变，人眼感知为连续滚动。
关键点：
- 必须设置
white-space: nowrap防止换行破坏宽度计算 - 容器需
overflow: hidden，否则滚动过程会看到溢出部分 - 动画时长要和文本宽度匹配：比如文本宽 600px，想 10s 滚完一圈，就设
animation-duration: 10s - 不能用
left/right动画——重排开销大，卡顿明显；transform走合成层，60fps 更稳
示例代码：
.marquee {
white-space: nowrap;
overflow: hidden;
width: 200px;
}
.marquee span {
display: inline-block;
animation: scroll-left 8s linear infinite;
}
@keyframes scroll-left {
0% { transform: translateX(100%); }
100% { transform: translateX(-100%); }
}
⚠️ 注意：100% 是相对父容器宽度，不是文本自身。若文本极长，建议用 JS 测量真实 scrollWidth 后动态设动画时长，否则容易“滚太快”或“卡半截”。
双份文本拼接法：解决跳变感最可靠的方案
上面的 translateX(100%) → translateX(-100%) 在动画终点仍可能因渲染精度或 timing 函数微小误差出现 1px 卡顿。生产环境更推荐「双文本首尾相接」方案：在 DOM 中放两份相同文本，让它们连成一条长带，动画只做匀速平移，无需重置。
做法：
- HTML 写两次文本：
新闻标题一 ｜ 新闻标题二新闻标题一 ｜ 新闻标题二 - CSS 中给外层设
width: 200px; overflow: hidden，内层两份文本用display: inline-block并排 - 动画只对整个内层容器做
transform: translateX(-50%)，刚好把第二份文本完全拖进可视区，第一份刚滚出，视觉无缝
优点：不依赖 JS、无跳帧风险、兼容性好（IE10+）。缺点：DOM 略冗余，但对现代移动设备毫无压力。
移动端适配与容易踩的坑
在 iOS 和安卓 WebView 中，以下问题高频出现：
-
transform: translateX()在某些旧版 UC 或 QQ 浏览器里需加-webkit-transform前缀（虽然现在多数已不需要） - 文字缩放（用户主动放大字体）会导致
100%计算失准，建议用vw或固定 px 值控制容器宽度，避免百分比依赖 - 滚动中触发页面其他动画（比如下拉刷新）可能抢占主线程，导致跑马灯掉帧；可加
will-change: transform提前提示合成 - 不要在
:hover上触发跑马灯（移动端无 hover），改用focus-within或 JS 监听visibilitychange控制启停
真正难的不是写出来，而是让不同机型、不同系统版本、不同缩放设置下都保持匀速不跳帧。建议上线前至少在 iOS 16+、Android 12+ Chrome、鸿蒙 NEXT WebView 三端实机验证滚动节奏是否一致。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
