必须在before回调中用FileReader读文件头4字节做magic校验，因file.type和exts均不可靠；需加try/catch、超时及并发控制，并在服务端重复校验。
before回调里用FileReader读文件头做magic校验
浏览器不信任文件后缀，exts和acceptmime都只管“表面”，真正判断真实格式必须读文件前几字节（magic number）。before是唯一能同步/异步拦截上传的入口，且此时obj.getchoosefiles()可拿到原生file对象。
常见错误是试图在choose或done里读取——前者还没触发上传流程但FileReader没绑定好，后者已发请求，拦不住。
- 只读前4字节就够识别大部分格式：ZIP是
50 4B 03 04，PNG是89 50 4E 47，PDF是25 50 44 46 - 用
FileReader.readAsArrayBuffer()，别用readAsDataURL()——后者转base64开销大，且对大文件极易卡死 - 必须加
try/catch和超时控制：Safari对FileReader有并发限制，Chrome在before里阻塞太久会直接跳过回调 - 示例（校验是否真为PDF）：
before: function(obj) { var files = obj.getChooseFiles(); if (!files.length) return; var file = files[0]; return new Promise(function(resolve, reject) { var reader = new FileReader(); reader.onload = function(e) { var arr = new Uint8Array(e.target.result); if (arr[0] === 0x25 && arr[1] === 0x50 && arr[2] === 0x44 && arr[3] === 0x46) { resolve(); // 放行 } else { layer.msg('文件不是有效的PDF', {icon: 2}); reject(); } }; reader.onerror = function() { layer.msg('读取文件失败，请重试', {icon: 2}); reject(); }; reader.readAsArrayBuffer(file.slice(0, 4)); }); }
file.type不可信，但比exts强一点
file.type由浏览器根据文件头或扩展名推测，不是100%可靠，但比纯字符串匹配的exts强得多。它在before和choose里都能取到，无需额外读取。
比如用户把hack.exe改成doc.pdf，file.type大概率是''或application/octet-stream，而不会是application/pdf。
- 常见可信度排序：
file.type>exts，但file.type≠ 真实 MIME；真实校验仍需 magic number 或服务端二进制解析 - IE 和旧版 Safari 的
file.type为空字符串概率高，不能作为唯一判断依据 - 多文件场景下，每个
file的type独立，需逐个判断，不能只看第一个 - 不要写
if (file.type !== 'application/pdf')就直接拦截——某些 PDF 生成器导出的文件type可能是''，得 fallback 到 magic 校验
服务端必须重复校验，前端magic只是体验优化
前端读文件头只是提升用户体验、减少无效请求，绝不能替代服务端校验。攻击者可以构造伪造 magic 的恶意文件，或绕过 JS 执行环境直接发请求。
真实生产环境必须在服务端做两件事：读文件前4–8字节比对 magic number + 用libmagic或类似库解析真实 MIME。
- Node.js 示例（用
file-type包）：const fileType = require('file-type'); const buffer = await fs.readFile(filePath); const result = await fileType.fromBuffer(buffer); // 返回{ext: 'pdf', mime: 'application/pdf'} - PHP 示例：
$finfo = finfo_open(FILEINFO_MIME_TYPE); $mimeType = finfo_file($finfo, $tmpFile); // 不依赖$_FILES['file']['type']
- Nginx 或 CDN 层无法做 magic 校验，只能靠后端应用层完成
- 注意：前端 magic 校验耗时随文件数线性增长，10个文件就要开10个
FileReader，建议加并发限制（如最多同时校验3个）
Safari和移动端的兼容性坑最要命
不是所有浏览器都支持FileReader.readAsArrayBuffer()在before里稳定运行。Safari 15–16 对FileReader在事件回调中的调用有静默失败倾向，iOS 微信内置浏览器甚至直接抛NotSupportedError。
这意味着你写的 magic 校验，在部分真实用户设备上根本不会执行，before直接跳过，上传照常发生。
- 必须在目标环境实测：用真机连 Safari Web Inspector，看
reader.onload是否触发、reader.result是否为空 - 降级方案：当
FileReader不可用时，退回到file.type+exts组合判断，并提示“格式校验受限，上传后将由服务器严格验证” - 不要用
file.size === 0判断读取失败——Safari 对超大文件（>2GB）可能返回 size 0，但FileReader仍可用 - 移动端 WebView（如安卓微信）对
slice()方法支持不一，保险起见用file.slice(0, 4)前先检查file.slice是否存在
