前端无法校验压缩包内文件格式，因file api仅能获取压缩包元信息，无法解压读取内部文件头或扩展名，所有此类校验必须由后端完成。
不能直接校验压缩包内文件格式——浏览器在前端无法解压并读取 ZIP/RAR 内部文件头或扩展名，所有“校验压缩包里是不是图片/PDF”类需求，必须由后端完成。
为什么前端做不到压缩包内文件校验
浏览器的 File API 只能拿到用户选中的压缩包本身（如 report.zip），它的 file.type 是 application/zip 或空字符串，file.size 是整个压缩包体积。ZIP 文件内部结构（如包含 photo.jpg 或 payload.exe）完全不可见，JavaScript 无权自动解压、遍历或读取其内容。
常见错误现象：
- 试图用
new JSZip()在前端解压 ZIP 并检查内部文件名 → 失败率高：大文件卡顿、不支持加密 ZIP、移动端兼容性差、无法读取二进制魔数 - 仅校验压缩包后缀为
.zip就放行 → 用户可把恶意脚本打包成safe.zip，内部全是.js或.exe - 上传前用
FileReader读取 ZIP 文件头 → 只能确认“这是 ZIP”，无法知道里面有什么
accept 和前端 JS 校验只能管到压缩包本身
accept 属性对压缩包类型的作用非常有限：
-
accept=".zip,.rar"：只影响文件选择器默认过滤，用户仍可切到“所有文件”选任意后缀 -
accept="application/zip"：部分安卓 WebView 忽略该值，file.type返回空字符串 - 即使
file.type === "application/zip"，也无法证明内部文件安全
前端可做的合理校验只有：
- 检查
file.name.toLowerCase().endsWith('.zip')（同时兼容.ZIP、.Zip） - 限制压缩包总大小（如
file.size ） - 清空
input.value防止重复选同一文件时事件不触发
后端才是压缩包内文件校验的唯一可靠位置
真正有效的方案是：上传完整 ZIP 到后端 → 临时解压 → 对每个内部文件做独立校验 → 拒绝含非法类型或危险扩展名的条目。
关键实现点：
- Node.js：用
node-stream-zip流式读取条目名，配合file-type读取每个文件前 12 字节判断真实 MIME，禁止.html、.js、.exe等扩展名出现在 ZIP 内 - Python：用
zipfile.ZipFile获取namelist()，再用python-magic检查每个文件内容魔数，不信任filename后缀 - Java：用
java.util.zip.ZipInputStream遍历条目，配合Tika.detect()校验真实类型 - 必须重命名内部文件（如
user_upload_abc123.jpg），防止路径穿越（../../etc/passwd）
如果业务强依赖前端提示“压缩包里有违规文件”，只能妥协方案
这类需求本质违背浏览器安全模型，但若 UI 必须提前反馈，可考虑：
- 要求用户先上传 ZIP，后端快速扫描（不存盘），返回内部文件列表和风险标记（如 “发现 script.js”），前端弹窗提示并允许取消提交
- 用 WebAssembly 加载轻量 ZIP 解析器（如
fflate），仅提取文件名列表（不读内容），再做后缀白名单过滤 —— 仍不可信，但比纯盲传好一点 - 明确告知用户：“系统仅检查压缩包外层，内部文件安全性由您自行负责”，把责任边界写进协议
压缩包内文件的真实类型永远藏在服务端字节流里，前端看到的只是个黑盒容器。任何试图绕过这层隔离的设计，都会在真实攻击场景中失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
