accept属性仅提供前端提示，无法真正识别动态gif；必须结合javascript客户端帧解析与服务端深度校验（如gif签名、多帧检测）才能确保上传的是合法动态gif。
仅靠 accept 属性无法真正限制“只能上传动态 GIF”——它连静态 GIF 都分不清，更别说判断是否含多帧。 浏览器不解析 GIF 帧结构，accept="image/gif" 只匹配 MIME 类型，用户仍可选中任意 .gif 文件（包括单帧、损坏或伪装成 GIF 的文件）。真要筛动态 GIF，必须结合客户端校验 + 服务端深度检测。
accept 属性只影响文件选择框的默认过滤
设置 accept="image/gif" 后，系统文件对话框会默认只显示 .gif 文件，但用户能手动切换到“所有文件”并选中任意后缀（如 evil.jpg 改名为 test.gif）；即使后缀和 MIME 都对，也可能是静帧 GIF 或已损坏。这不是 bug，是浏览器设计使然——accept 仅为 UX 提示，无安全约束力。
用 JavaScript 检查 GIF 是否含多帧（客户端粗筛）
可通过解析 GIF 文件头和逻辑屏幕描述符，快速判断是否至少有两帧。关键点：
- 读取文件前 10 字节：GIF87a / GIF89a 签名必须存在
- 跳过逻辑屏幕描述符（固定 7 字节）、全局色表（长度由标志位决定），定位第一个图像分块（
0x2C） - 继续搜索后续是否还有第二个
0x2C（图像分块起始）或0x21（扩展块，如图形控制扩展0xF9常用于动画） - 注意：不能只依赖
file.type === "image/gif"，伪造 MIME 成本极低
简例（使用 FileReader 读取 ArrayBuffer）：
const checkIsAnimatedGif = (file) => {
return new Promise((resolve) => {
const reader = new FileReader();
reader.onload = () => {
const buf = reader.result;
const view = new DataView(buf);
// 检查签名
if (view.getUint32(0, false) !== 0x47494638 || // GIF8
(view.getUint16(4, false) !== 0x3761 && view.getUint16(4, false) !== 0x3961)) { // 7a or 9a
resolve(false);
return;
}
let pos = 13; // 跳过逻辑屏幕描述符（7字节）+ 全局色表（最长256×3=768，但实际由标志位决定；保守起见，此处仅示意，真实需解析）
let frameCount = 0;
while (pos = 2);
};
reader.readAsArrayBuffer(file.slice(0, 1024)); // 只读前1KB足够定位前两帧
});
};
服务端必须做魔术字节 + 帧解析（不可省略）
前端校验可被绕过，服务端才是最终防线。重点不是“是不是 .gif”，而是“是不是合法多帧 GIF”：
- 拒绝
Content-Type不为image/gif的请求（但需配合原始文件头校验，防 header 伪造） - 读取文件前 6 字节确认
GIF8[79]a签名 - 用库（如 Node.js 的
gifwrap或 Python 的PIL.Image）解析帧数，len(gif.n_frames) > 1才接受 - 若解析失败（如 CRC 错误、截断、非标准扩展），直接拒收——动态 GIF 对格式鲁棒性极低
- 不要依赖扩展名或用户传来的
filename，重命名存储时用随机名 +.gif后缀
为什么不用 canvas 或 URL.createObjectURL 预览判断？
因为 <img> 加载 GIF 时，浏览器自动解码并播放，但你无法通过 JS 获取当前是否“在动”或“有几帧”。HTMLImageElement 没有帧数 API；canvas.drawImage() 只画第一帧；createObjectURL 生成的地址也无法触发帧信息提取。这类方案看似直观，实则完全无效——它连“是不是 GIF”都验证不了，更别说“是不是动态”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
