应显式声明input的accept属性为".tar,.tar.gz,.zip,.bz2,.7z"，上传前校验file.size>0及文件后缀，前端轻量预检EOCD或ustar签名，后端必须二次校验并返回含checksum、extractable、error的JSON结果。
上传系统备份文件时如何避免 MIME 类型被浏览器拦截
浏览器对 .tar.gz、.zip 等备份文件类型默认不信任，直接用 <input type="file"> 选中后可能触发安全策略（尤其在 Chrome 119+），导致 File 对象为空或 size === 0。这不是代码写错了，是浏览器主动过滤。
实操建议：
立即学习“前端免费学习笔记（深入）”；
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 显式声明
accept属性，例如：<input type="file" accept=".tar,.tar.gz,.zip,.bz2,.7z" />（注意：不要写application/x-tar这类 MIME，兼容性差且现代浏览器常忽略） - 上传前检查
file.size > 0和file.name是否含预期后缀，防止空文件或伪装文件绕过 - 若后端用 Nginx，确认未配置
types { }或default_type application/octet-stream;导致响应头污染上传流程
前端自动校验备份包完整性的可行方式
纯前端无法可靠验证压缩包内部结构（比如 tar 的 header 校验、zip 的 EOCD 定位），但可做轻量级预检，避免上传明显损坏的文件。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 对
.zip：读取末尾 22 字节，检查是否为0x504B0506（EOCD signature），用file.slice(file.size - 22, file.size)+ArrayBuffer解析 - 对
.tar或.tar.gz：跳过 gzip header（若存在），读取 tar header 块（512 字节），验证第 148–155 字节是否为 ASCII"ustar"（注意字节序和 padding） - 必须配合后端二次校验——前端校验只是快速失败，不能替代服务端的
tar -t或unzip -t
上传后如何让后端返回结构化校验结果并反馈给用户
用户传完就关页面，或网络中断，会导致“以为上传成功但实际校验失败”。关键不是传上去，而是让结果可感知。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 上传接口返回 JSON，强制包含
checksum（如 SHA256）、extractable（布尔）、error（字符串或 null）字段，禁止只返回 HTTP 状态码 - 前端用
fetch而非表单提交，捕获response.json()后立即检查error字段，弹出具体提示（如 “tar header magic mismatch at offset 0x123”） - 若校验耗时 > 2s，返回
{ status: "pending", check_id: "chk_abc123" }，再轮询/api/check/<code>chk_abc123获取最终结果
为什么不能依赖 onload 或 onprogress 判断文件完整性
XMLHttpRequest.upload.onprogress 只反映传输进度，和文件内容无关；FileReader.onload 触发只代表二进制读取完成，不代表数据有效。
常见错误现象：
- 用户拖入一个 0 字节的
backup.tar.gz，onload仍会触发，result是空字符串 - 文件被截断（如只传了前 1MB），
FileReader不报错，但后续解压必然失败 - 某些手机浏览器对大文件（>500MB）调用
readAsArrayBuffer会静默失败，需加onerror监听并 fallback 到分块读取
真正可靠的校验点只有一个：服务端收到完整字节流后，用系统命令或专用库（如 libarchive）执行实际解析。前端所有操作，都是为了更快暴露问题，而不是替代它。
