accept属性仅影响浏览器文件选择框的默认显示，不校验上传行为，前端必须二次过滤文件扩展名和文件头，后端校验（Content-Type、magic bytes、大小、重命名）是唯一安全边界。
accept 属性只影响文件选择框，不校验上传行为
它只是告诉浏览器“默认只显示哪些文件”，比如 accept="image/*" 会让 macOS 文件选择器隐藏 .txt、.exe 等非图片文件；但用户仍能点“显示所有”、拖拽任意文件、或用开发者工具删掉 accept 后继续选。Chrome 和 Safari 行为略有差异：Safari 对 accept="audio/*" 可能直接禁用 iCloud 上传入口，而某些安卓 WebView 会完全忽略该属性。
accept 值怎么写才靠谱？别只信 MIME 类型
MIME 类型在不同系统上报的值不稳定：.jpg 在 Windows 可能是 image/pjpeg，iOS 可能报空，Node.js file.type 也可能为空。靠单一 MIME 匹配极易漏判。
- 优先组合写法：
accept="image/png, image/jpeg, .png, .jpg, .jpeg" - 逗号后不能有空格：
accept="text/plain,.csv"✅，accept="text/plain , .csv"❌（旧版 Safari 解析失败） - 通配符更省心：
accept="image/*, application/pdf"比罗列十几个 MIME 更实际 - 避免只写
application/x-rar-compressed：很多环境根本识别不了，最终file.type是application/octet-stream或空字符串
前端必须手动遍历 files 列表做二次过滤
即使设了 multiple + accept，用户仍可一次勾选 .pdf、.zip、.psd —— 浏览器不会拦截，event.target.files 里全都会出现。
-
file.type不可靠，优先用file.name.match(/\.(jpg|jpeg|png|pdf)$/i) - change 事件里要遍历每项，实时提示：“已选 3 个不支持的文件（report.psd, data.zip, scan.tif）”
- 禁用提交按钮前，得确认全部文件都通过扩展名 +（可选）文件头（magic bytes）校验，不能只看第一个
后端校验不是可选项，而是唯一安全边界
accept 属性对后端零影响。用户绕过前端限制后，$_FILES 或 req.file 依然能拿到任意类型文件。真正有效的校验必须包含：
立即学习“前端免费学习笔记（深入）”；
- 检查
Content-Type头（但可伪造，仅作参考） - 读取文件前几个字节（magic bytes），比对真实格式（如 PDF 开头是
%PDF，PNG 是89 50 4E 47） - 限制文件大小（
accept完全不涉及） - 重命名存储时剥离原始扩展名，用服务端生成的随机名 + 白名单后缀
移动端尤其要注意：华为 EMUI、小米 MIUI 的 WebView 经常跳过 accept，iOS Safari 则可能因限制过严导致用户根本无法从相册选图——这些场景下，前端过滤失效是常态，后端兜底必须稳。
