整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
视频分割软件哪个好？
1、视频编辑大师
视频编辑大师是一款专业的视频编辑软件，包含视频合并专家、AVI MPEG视频合并专家、视频分割专家、视频截取专家、RMVB视频合并专家的所有功能，是视频爱好者必备的工具。
2、视频剪切合并器
软件名称：
视频剪切合并器是一款目前剪切视频速度最快、支持无损切割视频、最好用的免费视频剪切合并工具。剪切一个100MB大小的视频文件只需要10秒左右时间，是目前最快的视频剪切工具。它可以对AVI、MP4、 FLV、 MOV、 RMVB、3GP、WMV等视频格式进行任意时间段的剪切，还支持多个视频文件的合并。频剪切合并器操作非常简单，只需要将你的视频文件用视频剪切合并器打开，选择好你想剪切的视频起始位置和结束位置，点击开始剪切按钮，立刻搞定！支持无损剪切AVI、 MP4、 FLV、 MOV、RMVB、3GP、WMV等各种视频格式，剪切后视频清晰度，画面大小等不变。视频合并支持任意的不同视频格式之间的合并，比如你可以把FLV格式和MP4格式的视频合并在一起，功能非常强大。
会声会影(Ulead Video Studio)10是一套功能强大、有趣好用的个人家庭影片剪辑软件。通过它完整强大的编辑模式您可以剪辑出个人风格，点缀个人影片。和会声会影8比较，会声会影10速度提升了很大，转换和输入输出视频简直是得心应手！支持更多的格式，采集、编辑、加字幕、输出、刻盘...那是相当的好用啊。
4、易杰视频分割器
易杰视频分割器是一款功能强大的视频分割工具，它可以帮助您将几乎所有的视频格式，如：RM、RMVB、VOB、DAT、VCD、SVCD、ASF、MOV、QT、MPEG、MPG、WMV、MP4、3GP、M4V、AVI、FLV、MKV、MOD、TOD、MTS、M2TS、TS、F4V、DV等视频格式按照您设置的时间分割成小的视频文件，可以输出FLV、AVI、VCD、SVCD、DVD、WMV等多种视频格式，支持多个视频文件批量分割。软件具有分割简单、快速、高画质等特点，还可以支持分割完成后自动关机。
接：https://juejin.im/book/5b936540f265da0a9624b04b
《高性能网站建设指南》的作者 Steve Souders 曾在一篇博客中提到：
我的大部分性能优化工作都集中在 JavaScript 和 CSS 上，从早期的 Move Scripts to the Bottom 和 Put Stylesheets at the Top 规则。为了强调这些规则的重要性，我甚至说过，“JS 和 CSS 是页面上最重要的部分”。
几个月后，我意识到这是错误的。图片才是页面上最重要的部分。
我关注 JS 和 CSS 的重点也是如何能够更快地下载图片。图片是用户可以直观看到的。他们并不会关注 JS 和 CSS。确实，JS 和 CSS 会影响图片内容的展示，尤其是会影响图片的展示方式（比如图片轮播，CSS 背景图和媒体查询）。但是我认为 JS 和 CSS 只是展示图片的方式。在页面加载的过程中，应当先让图片和文字先展示，而不是试图保证 JS 和 CSS 更快下载完成。
这段话可谓字字珠玑。此外，雅虎军规和 Google 官方的最佳实践也都将图片优化列为前端性能优化必不可少的环节——图片优化的优先级可见一斑。
就图片这块来说，与其说我们是在做“优化”，不如说我们是在做“权衡”。因为我们要做的事情，就是去压缩图片的体积（或者一开始就选取体积较小的图片格式）。但这个优化操作，是以牺牲一部分成像质量为代价的。因此我们的主要任务，是尽可能地去寻求一个质量与性能之间的平衡点。
2019 年，图片依然很大
这里先给大家介绍 HTTP-Archive 这个网站，它会定期抓取 Web 上的站点，并记录资源的加载情况、Web API 的使用情况等页面的详细信息，并会对这些数据进行处理和分析以确定趋势。通过它我们可以实时地看到世界范围内的 Web 资源的统计结果。
截止到 2018 年 8 月，过去一年总的 web 资源的平均请求体积是这样的：
而具体到图片这一类的资源，平均请求体积是这样的：
当然，随着我们工程师在性能方面所做的努力越来越有成效，平均来说，不管是资源总量还是图片体积，都在往越来越轻量的方向演化。这是一种值得肯定的进步。
但同时我们不得不承认，如图所示的这个图片体积，依然是太大了。图片在所有资源中所占的比重，也足够“触目惊心”了。为了改变这个现状，我们必须把图片优化提上日程。
时下应用较为广泛的 Web 图片格式有 JPEG/JPG、PNG、WebP、Base64、SVG 等，这些格式都是很有故事的，值得我们好好研究一把。此外，老生常谈的雪碧图（CSS Sprites）至今也仍在一线的前端应用中发光发热，我们也会有所提及。
不谈业务场景的选型都是耍流氓。下面我们就结合具体的业务场景，一起来解开图片选型的神秘面纱！
在计算机中，像素用二进制数来表示。不同的图片格式中像素与二进制位数之间的对应关系是不同的。一个像素对应的二进制位数越多，它可以表示的颜色种类就越多，成像效果也就越细腻，文件体积相应也会越大。
一个二进制位表示两种颜色（0|1 对应黑|白），如果一种图片格式对应的二进制位数有 n 个，那么它就可以呈现 2^n 种颜色。
关键字：有损压缩、体积小、加载快、不支持透明
JPG 的优点
JPG 最大的特点是有损压缩。这种高效的压缩算法使它成为了一种非常轻巧的图片格式。另一方面，即使被称为“有损”压缩，JPG的压缩方式仍然是一种高质量的压缩方式：当我们把图片体积压缩至原有体积的 50% 以下时，JPG 仍然可以保持住 60% 的品质。此外，JPG 格式以 24 位存储单个图，可以呈现多达 1600 万种颜色，足以应对大多数场景下对色彩的要求，这一点决定了它压缩前后的质量损耗并不容易被我们人类的肉眼所察觉——前提是你用对了业务场景。
使用场景
JPG 适用于呈现色彩丰富的图片，在我们日常开发中，JPG 图片经常作为大的背景图、轮播图或 Banner 图出现。
两大电商网站对大图的处理，是 JPG 图片应用场景的最佳写照：
打开淘宝首页，我们可以发现页面中最醒目、最庞大的图片，一定是以 .jpg 为后缀的：
京东首页也不例外：
使用 JPG 呈现大图，既可以保住图片的质量，又不会带来令人头疼的图片体积，是当下比较推崇的一种方案。
JPG 的缺陷
有损压缩在上文所展示的轮播图上确实很难露出马脚，但当它处理矢量图形和 Logo 等线条感较强、颜色对比强烈的图像时，人为压缩导致的图片模糊会相当明显。
此外，JPEG 图像不支持透明度处理，透明图片需要召唤 PNG 来呈现。
关键字：无损压缩、质量高、体积大、支持透明
PNG 的优点
PNG（可移植网络图形格式）是一种无损压缩的高保真的图片格式。8 和 24，这里都是二进制数的位数。按照我们前置知识里提到的对应关系，8 位的 PNG 最多支持 256 种颜色，而 24 位的可以呈现约 1600 万种颜色。
PNG 图片具有比 JPG 更强的色彩表现力，对线条的处理更加细腻，对透明度有良好的支持。它弥补了上文我们提到的 JPG 的局限性，唯一的 BUG 就是体积太大。
PNG-8 与 PNG-24 的选择题
什么时候用 PNG-8，什么时候用 PNG-24，这是一个问题。
理论上来说，当你追求最佳的显示效果、并且不在意文件体积大小时，是推荐使用 PNG-24 的。
但实践当中，为了规避体积的问题，我们一般不用PNG去处理较复杂的图像。当我们遇到适合 PNG 的场景时，也会优先选择更为小巧的 PNG-8。
如何确定一张图片是该用 PNG-8 还是 PNG-24 去呈现呢？好的做法是把图片先按照这两种格式分别输出，看 PNG-8 输出的结果是否会带来肉眼可见的质量损耗，并且确认这种损耗是否在我们（尤其是你的 UI 设计师）可接受的范围内，基于对比的结果去做判断。
应用场景
前面我们提到，复杂的、色彩层次丰富的图片，用 PNG 来处理的话，成本会比较高，我们一般会交给 JPG 去存储。
考虑到 PNG 在处理线条和颜色对比度方面的优势，我们主要用它来呈现小的 Logo、颜色简单且对比强烈的图片或背景等。
此时我们再次把目光转向性能方面堪称业界楷模的淘宝首页，我们会发现它页面上的 Logo，无论大小，还真的都是 PNG 格式：
主 Logo：
较小的 Logo：
颜色简单、对比度较强的透明小图也在 PNG 格式下有着良好的表现：
关键字：文本文件、体积小、不失真、兼容性好
SVG（可缩放矢量图形）是一种基于 XML 语法的图像格式。它和本文提及的其它图片种类有着本质的不同：SVG 对图像的处理不是基于像素点，而是是基于对图像的形状描述。
SVG 的特性
和性能关系最密切的一点就是：SVG 与 PNG 和 JPG 相比，文件体积更小，可压缩性更强。
当然，作为矢量图，它最显著的优势还是在于图片可无限放大而不失真这一点上。这使得 SVG 即使是被放到视网膜屏幕上，也可以一如既往地展现出较好的成像品质——1 张 SVG 足以适配 n 种分辨率。
此外，SVG 是文本文件。我们既可以像写代码一样定义 SVG，把它写在 HTML 里、成为 DOM 的一部分，也可以把对图形的描述写入以 .svg 为后缀的独立文件（SVG 文件在使用上与普通图片文件无异）。这使得 SVG 文件可以被非常多的工具读取和修改，具有较强的灵活性。
SVG 的局限性主要有两个方面，一方面是它的渲染成本比较高，这点对性能来说是很不利的。另一方面，SVG 存在着其它图片格式所没有的学习成本（它是可编程的）。
SVG 的使用方式与应用场景
SVG 是文本文件，我们既可以像写代码一样定义 SVG，把它写在 HTML 里、成为 DOM 的一部分，也可以把对图形的描述写入以 .svg 为后缀的独立文件（SVG 文件在使用上与普通图片文件无异）。
将 SVG 写入 HTML：
将 SVG 写入独立文件后引入 HTML:
<img src="文件名.svg" alt="">
在实际开发中，我们更多用到的是后者。很多情况下设计师会给到我们 SVG 文件，就算没有设计师，我们还有非常好用的 在线矢量图形库。对于矢量图，我们无须深究过多，只需要对其核心特性有所掌握、日后在应用时做到有迹可循即可。
关键字：文本文件、依赖编码、小图标解决方案
Base64 并非一种图片格式，而是一种编码方式。Base64 和雪碧图一样，是作为小图标解决方案而存在的。在了解 Base64 之前，我们先来了解一下雪碧图。
前置知识：最经典的小图标解决方案——雪碧图（CSS Sprites）
雪碧图、CSS 精灵、CSS Sprites、图像精灵，说的都是这个东西——一种将小图标和背景图像合并到一张图片上，然后利用 CSS 的背景定位来显示其中的每一部分的技术。
MDN 对雪碧图的解释已经非常到位：
图像精灵（sprite，意为精灵），被运用于众多使用大量小图标的网页应用之上。它可取图像的一部分来使用，使得使用一个图像文件替代多个小文件成为可能。相较于一个小图标一个图像文件，单独一张图片所需的 HTTP 请求更少，对内存和带宽更加友好。
我们几乎可以在每一个有小图标出现的网站里找到雪碧图的影子（下图截取自京东首页）：
和雪碧图一样，Base64 图片的出现，也是为了减少加载网页图片时对服务器的请求次数，从而提升网页性能。Base64 是作为雪碧图的补充而存在的。
理解 Base64
通过我们上文的演示，大家不难看出，每次加载图片，都是需要单独向服务器请求这个图片对应的资源的——这也就意味着一次 HTTP 请求的开销。
Base64 是一种用于传输 8Bit 字节码的编码方式，通过对图片进行 Base64 编码，我们可以直接将编码结果写入 HTML 或者写入 CSS，从而减少 HTTP 请求的次数。
我们来一起看一个实例，现在我有这么一个小小的放大镜 Logo：
它对应的链接如下：
https://user-gold-cdn.xitu.io/2018/9/15/165db7e94699824b?w=22&h=22&f=png&s=3680
按照一贯的思路，我们加载图片需要把图片链接写入 img 标签：
<img src="https://user-gold-cdn.xitu.io/2018/9/15/165db7e94699824b?w=22&h=22&f=png&s=3680">
浏览器就会针对我们的图片链接去发起一个资源请求。
但是如果我们对这个图片进行 Base64 编码，我们会得到一个很长很长的字符串，我们可以直接用这个字符串替换掉上文中的链接地址。你会发现浏览器原来是可以理解这个字符串的，它自动就将这个字符串解码为了一个图片，而不需再去发送 HTTP 请求。
Base64 的应用场景
上面这个实例，其实源自我们 掘金 网站 Header 部分的搜索栏 Logo：
既然 Base64 这么棒，我们何不把大图也换成 Base64 呢？
这是因为，Base64 编码后，图片大小会膨胀为原文件的 4/3（这是由 Base64 的编码原理决定的）。如果我们把大图也编码到 HTML 或 CSS 文件中，后者的体积会明显增加，即便我们减少了 HTTP 请求，也无法弥补这庞大的体积带来的性能开销，得不偿失。
在传输非常小的图片的时候，Base64 带来的文件体积膨胀、以及浏览器解析 Base64 的时间开销，与它节省掉的 HTTP 请求开销相比，可以忽略不计，这时候才能真正体现出它在性能方面的优势。
因此，Base64 并非万全之策，我们往往在一张图片满足以下条件时会对它应用 Base64 编码：
Base64 编码工具推荐
这里最推荐的是利用 webpack 来进行 Base64 的编码——webpack 的 url-loader 非常聪明，它除了具备基本的 Base64 转码能力，还可以结合文件大小，帮我们判断图片是否有必要进行 Base64 编码。
除此之外，市面上免费的 Base64 编解码工具种类是非常多样化的，有很多网站都提供在线编解码的服务，大家选取自己认为顺手的工具就好。
关键字：年轻的全能型选手
WebP 是今天在座各类图片格式中最年轻的一位，它于 2010 年被提出， 是 Google 专为 Web 开发的一种旨在加快图片加载速度的图片格式，它支持有损压缩和无损压缩。
WebP 的优点
WebP 像 JPEG 一样对细节丰富的图片信手拈来，像 PNG 一样支持透明，像 GIF 一样可以显示动态图片——它集多种图片文件格式的优点于一身。
WebP 的官方介绍对这一点有着更权威的阐述：
与 PNG 相比，WebP 无损图像的尺寸缩小了 26％。在等效的 SSIM 质量指数下，WebP 有损图像比同类 JPEG 图像小 25-34％。 无损 WebP 支持透明度（也称为 alpha 通道），仅需 22％ 的额外字节。对于有损 RGB 压缩可接受的情况，有损 WebP 也支持透明度，与 PNG 相比，通常提供 3 倍的文件大小。
我们开篇提到，图片优化是质量与性能的博弈，从这个角度看，WebP 无疑是真正的赢家。
WebP 的局限性
WebP 纵有千般好，但它毕竟太年轻。我们知道，任何新生事物，都逃不开兼容性的大坑。现在是 2018 年 9 月，WebP 的支持情况是这样的：
坦白地说，虽然没有特别惨（毕竟还有亲爹 Chrome 在撑腰），但也足够让人望而却步了。
此外，WebP 还会增加服务器的负担——和编码 JPG 文件相比，编码同样质量的 WebP 文件会占用更多的计算资源。
WebP 的应用场景
现在限制我们使用 WebP 的最大问题不是“这个图片是否适合用 WebP 呈现”的问题，而是“浏览器是否允许 WebP”的问题，即我们上文谈到的兼容性问题。具体来说，一旦我们选择了 WebP，就要考虑在 Safari 等浏览器下它无法显示的问题，也就是说我们需要准备 PlanB，准备降级方案。
目前真正把 WebP 格式落地到网页中的网站并不是很多，这其中淘宝首页对 WebP 兼容性问题的处理方式就非常有趣。我们可以打开 Chrome 的开发者工具搜索其源码里的 WebP 关键字：
我们会发现检索结果还是挺多的（单就图示的加载结果来看，足足有?200?多条），下面大家注意一下这些 WebP 图片的链接地址（以其中一个为例）：
<img src="//img.alicdn.com/tps/i4/TB1CKSgIpXXXXccXXXX07tlTXXX-200-200.png_60x60.jpg_.webp" alt="手机app - 聚划算" class="app-icon">
.webp 前面，还跟了一个 .jpg 后缀！
我们现在先大胆地猜测，这个图片应该至少存在 jpg 和 webp 两种格式，程序会根据浏览器的型号、以及该型号是否支持 WebP 这些信息来决定当前浏览器显示的是 .webp 后缀还是 .jpg 后缀。带着这个预判，我们打开并不支持 WebP 格式的 Safari 来进入同样的页面，再次搜索 WebP 关键字：
Safari 提示我们找不到，这也是情理之中。我们定位到刚刚示例的 WebP 图片所在的元素，查看一下它在 Safari 里的图片链接：
<img src="//img.alicdn.com/tps/i4/TB1CKSgIpXXXXccXXXX07tlTXXX-200-200.png_60x60.jpg" alt="手机app - 聚划算" class="app-icon">
我们看到同样的一张图片，在 Safari 中的后缀从 .webp 变成了 .jpg！看来果然如此——站点确实是先进行了兼容性的预判，在浏览器环境支持 WebP 的情况下，优先使用 WebP 格式，否则就把图片降级为 JPG 格式（本质是对图片的链接地址作简单的字符串切割）。
此外，还有另一个维护性更强、更加灵活的方案——把判断工作交给后端，由服务器根据 HTTP 请求头部的 Accept 字段来决定返回什么格式的图片。当 Accept 字段包含 image/webp 时，就返回 WebP 格式的图片，否则返回原图。这种做法的好处是，当浏览器对 WebP 格式图片的兼容支持发生改变时，我们也不用再去更新自己的兼容判定代码，只需要服务端像往常一样对 Accept 字段进行检查即可。
由此也可以看出，我们 WebP 格式的局限性确实比较明显，如果决定使用 WebP，兼容性处理是必不可少的。
css3的animation想必大家都知道吧，那 steps 逐帧动画你知道吗？对于我来说，实际工作及练习中也很少用到这种跳跃式变化的动画，而它start和end的解释又比较“不说人话”，以前用到steps动画的时候，常常是靠调试，来回设置start和end，主打的就是瞎猫碰上死耗子。虽然之前也看过关于他们区别的文章，但都是半知半解，过两天就剩零知零解了。最近忙里偷闲，我终于打算一探究竟了，我倒要看看start和end到底有什么区别！ 顺便写几个小demo造福一方～
animation的工作原理是通过将元素的CSS样式从一个状态改变为另一个状态时（我们称为线性变化），浏览器会在每个关键帧之间插入补间动画，所以动画效果是连贯性的，这也就是我们常用的 补间动画。
而steps()逐帧动画则是跳跃式变化，如果说补间动画是一个滑坡式的变化，那么逐帧动画就是阶梯式变化，它的变化没有中间过程。补间动画就像你看的普通动画片，而逐帧动画就像是那种定格动画。
语法:
animation-timing-function: steps(number, [end | start])参数说明：
什么叫在间隔的起点或终点发生变化呢？光看文字十有八九看不懂，下面就用示例代码来说明。
上图是我ps的一张图，尺寸为200*750，共5个色块，每个色块高度150。 在示例代码中我将以这张图为背景，每一帧将背景上升一个色块的高度。关键代码如下：
animation: ani 5s 2s steps(5,start) infinite backwards;
@keyframes ani{
100%{
background-position:0px -750px;
}
}在设置动画前的初始状态：
再直接来看看动画末态的情况： 一个色块150px，所以动画末态是背景图片向上移动750px。
为了完整的看到动画效果，我设置了2秒的动画延迟
我们设置的steps的第一个参数number为 5 ，也就是把整个动画过程切割成5个片段，如下图：
在实验之前先来分析一下，既然是片段，那必然有片段的起点和终点，可以把补间动画看作点，而逐帧动画则是面。那么这五个片段的起点终点是哪呢，如下图：
你会发现，动画是由6个点切成段五段，带着这个思路开始下面的实验。
先来看一下设置 start 的效果:
你会发现色块1怎么不显示了，甚至在动画没开始前，也就是延时阶段直接就显示了【2】，变化过程为： 2 - 3 - 4 - 5 - 空
分析一下就可以想到，start是在间隔的起点发生阶越变化，即开始直接就发生变化了，第一段直接阶越到了第一段结束的位置。
再来看下设置 end 的效果：
你发现动画变正常了，动画过程是从【1】到【5】。 再分析一下，因为end是在间隔终点发生阶越变化，即每一段都会在其开始阶段进行停留，这一段结束后才会发生变化直接阶越到下一段的开始状态。
总结：
可以将补间动画和 steps 逐帧动画类比于点和线的区别，steps切割开的每个动画片段就是一条样式不变的线，而线都有首尾两个点。
设置 start 的 steps 的动画总是在开始发生变化，即逐帧显示每一段的终点；
而设置 end 的 steps 的动画总是在结束发生变化，即逐帧显示每一段的起点；
其实很简单的道理，为什么总是记不住呢，因为他和人的惯性思维恰好相反。设置start总觉得是显示每一段的开头，可它恰好相反，start是开头发生变化，显示的都是每一段的结尾。
另一种理解思路：
steps(number, [end | start]) 是将动画分为number段，共有number + 1帧画面。start就是抛弃第一帧画面执行动画，end就是抛弃最后一帧画面执行动画。
注意： 第二个参数还有两个内置值，step-start等同于steps(1,start)，动画分成1步，2个节点，抛弃第一个节点，即显示结尾节点的状态；同理step-end等同于steps(1,end)。
jump-start：在每个时间间隔开始的时候跳1步到下一状态位置； jump-end：在每个时间间隔结束的时候跳1步到下一状态位置； jump-both：在每个时间间隔开始和结束的时候跳1步到下一状态位置，跳步次数会比预设的多一次； jump-none：在每个状态位置停留够一个时间间隔才跳到下一位置，跳步次数会比与预设的少一次
上面我只设置了动画100%时的状态，那如果我设置了多个关键帧的状态呢，那还是以整个动画过程切割成number段吗？
我们再来做几个实验：
我们将动画时间由5秒改成10秒（为了方便观察，我们设置steps第二个参数为end，放弃第一帧画面），然后将原先的动画末态改到50%，并在动画100%时增加边框。·
animation: ani 10s 2s steps(5,end) infinite backwards;
@keyframes ani{
50%{
background-position:0px -750px;
}
100%{
border: 100px solid red;
}结果如下图：
观察后发现，在10秒的完整动画期间：background-position的变化过程是图像显示由1到5，再由5到1，共变化了 【10】 次，而我设置的steps的number参数是 【5】，这就打破了上面我说的以整个动画过程切割成number段的假说。
同时可以观察到，border的变化过程共进行了5次，因为我们只在100%的时候设置了border。
得出结论： steps的number参数并不是将整个动画过程切割成number段，而是对于某个css样式来说，每一段关键帧的变化切割成number段。
假想：上面我们只在动画100%的时候设置了100px的boder，如果我们在50%的时候也设置border，并且状态恰好是100%的一半，这样对于动画0%到100%是一个流畅的线性变化。请问这时候动画还会被切成5段吗？
观察发现，动画被切成了10段。
得出结论： 即使将几个关键帧的css变化设置的具有规律性，但是steps仍然会将每段关键帧的变化切割成number段，即只要在这个关键帧里设置了某个css，那么对于这个css来说，这个关键帧就会被视为steps动画的端点。
那既然每段关键帧都会被steps切割成number段，那每段的steps动画执行的时间怎么划分呢？其实想想就能想到，应该是按照关键帧占整个动画过程的比例分割整个动画时间。
如下图设置boder：【0%-50%】宽度由0到100，【50%-75%】宽度由100到0，【75%-100%】宽度由0到100
很明显可以观察到，border宽度变化的时间为 2:1:1，即验证了我上面的推论。
下面我举几个steps() 动画的使用场景。
用一张人物动作关键帧的长图，和上面的案例一样，通过修改背景图片位置，实现动物或人物的动作变化。作为一名蒸爱粉，我给哥哥做了一个跳舞的动画：
打字机的原理是用一个和文字总宽度一样的div覆盖文字，并用这个div的边框设置steps()动画实现光标效果，然后减小div宽度（每一帧减小一个文字的宽度），让下面文字漏出来就好了～\
点击运行查看效果～
我这里提供了两种实现方案，准确来说是三种：
方案1: var() css变量 + counter-reset计数器 + @property规则 + steps()逐帧动画
使用css变量和counter-reset计数器来实现倒计时的数字，只要设置动画，在5秒内将变量由5变为0即可实现倒计时，但是变量的变化是不会被浏览器添加补间动画的，即只会在5秒后直接变成0，而不会有中间，5-4-3-2-1-0的过程，这时我们再利用@property关键字为这个变量配置规则，实现数字变化的动态过程！
而最后出现的 "Go" 可以利用step-end逐帧动画，在5秒后将文字修改成 "Go"，或者利用@counter-style关键字自定义计数器规则，在变量变化到0的时候，定义一个symbols符号。
如果你不了解counter-reset、@property和@counter-style，可以查看以下两篇文章：
CSS counter-reset 属性
mdn 关于@property API 说明 mdn 关于@counter-style 说明
点击运行查看效果～
方案2: 只用steps()逐帧动画
其实这个就很简单了，所有的数字和最后的 "GO" 都在html里写死并设置等高，然后就可以向上面移动图片位置一样移动这些数字进行显示了。
点击运行查看效果～
平常工作中可以用到steps()逐帧动画的场景也有很多：
原文链接：https://juejin.cn/post/7242145254056214583
*请认真填写需求信息，我们会在24小时内与您取得联系。
