可爱的玩家们
2024年北京时间4月24日凌晨，Apex更新了平行步枪威望皮解锁的最后一组瓦尔基里任务，Valkyrie&&Flatline——are both my favorites.
任务在凌晨2点发布，有心的玩家花2个小时左右基本可以完成6000伤害以及助飞队友的任务，为了尽快完成瓦尔基里存活25个毒圈的任务，很多玩家开始了单飞冒险。
在天空之城遇到不少志同道合的小伙伴
奥林匹斯轮换结束后，越来越多的玩家开始加入瓦鸡单飞的队伍
这是4：30左右的风暴点：
太酷了！！！
终于拿到”最高等级“，这种白金紫有点Lakers的风格哦
PS:这个gif动图大小是135MB（已修剪）,而原MP4视频只有11MB
MP4视频和GIF动图基于完全不同的技术和压缩算法，这是导致文件大小差异的主要原因。以下几个因素可以解释为什么一个GIF动图会比其来源的MP4视频大很多：
- 压缩算法：MP4通常使用高效的视频压缩编码，如H.264或H.265，这些算法非常擅长在保持视频质量的同时大幅减小文件大小。相比之下，GIF使用LZW压缩算法，这种算法没有专门为视频设计，不如H.264或H.265高效。
- 颜色深度：GIF限于256色的限制，而现代视频通常有上千万种颜色。虽然这听起来像是GIF文件应该较小，但实际上，GIF需要更多的帧来模仿视频中的色彩变化，这反而会增加文件的大小。
- 帧率：GIF通常以较高的帧率存储每一帧图像，这意味着它可能包含比视频更多的单独图像帧，尤其是如果视频在编码时使用了帧间压缩技术（比如仅存储帧与帧之间的差异）。
- 帧内与帧间压缩：视频编码技术通常采用帧内压缩（压缩单独帧）和帧间压缩（压缩连续帧之间的差异）的组合。GIF没有帧间压缩能力，每一帧都是完整存储的，没有考虑与前后帧的关联。
- 分辨率：转换过程中可能无意间增加了GIF的分辨率，或者来自MP4的高分辨率视频在转换为GIF时没有适当的缩减分辨率，导致文件体积的增加。
- 循环播放：GIF经常被设置为无限循环，如果转换时包含了整个视频的多次循环，文件大小也会相应增加。
emm…
本来不必上传这个动图到git仓库的（直接从我图床上读取），我还是上传了，结果这个太大的文件（初始文件244MB超过了github支持的极限100MB）卡在历史提交记录中把网站维护的通道堵住了，我只好尝试下载git-filter-repo来删除历史记录，搞了半天，装好了文件，环境变量也没有问题，就是无法识别git-filter-repo,只好去看原文档，原来windows用户要把git-filter-repo文件的第一行中的python3修改为python才可以被环境识别。是shebang的问题
Shebang（也称为 hashbang、pound bang 或者 bang line）是由一串特殊字符组成的字符序列，在Unix和类Unix操作系统中，它用于在文本文件的第一行告诉系统如何执行该文件中的脚本。通常，一个shebang行看起来像这样：
bash复制#!/bin/bash或者
bash复制#!/usr/bin/env python这里的 #! 是shebang的实际标记，后面跟着的路径指向了用于解释脚本其余部分的解释器。在第一个例子中，/bin/bash 指的是Bash shell的路径，这意味着该文件应该用Bash来执行。在第二个例子中，/usr/bin/env 是一个常见的Unix程序，它用于在系统的环境中查找 python 解释器，并使用第一个找到的 python 程序来执行脚本。
Shebang行一定要出现在脚本文件的第一行，而且其前面不能有任何其他字符。当执行标有shebang的脚本文件时，操作系统会解析shebang行，然后使用指定的解释器来运行脚本中的代码。
例如，如果你有一个名为 script.sh 的文件，并且第一行是 #!/bin/bash，当你在Unix上运行这个脚本时（通过将其作为命令输入或者点击它），系统会调用 /bin/bash 来执行脚本中的命令。
这种机制允许相同的脚本文件在不同的系统中使用不同的解释器，而不需要更改脚本内容，只需要确保shebang行指向正确的解释器路径。可以提高代码的复用性
一旦删除了历史记录就好像真的没有提交过似的，（江南你最好记得楚子航）它要求操作者确认风险以及可能带来的严重后果
