accept属性仅优化前端文件选择体验，对后端安全零影响；必须配合前端JS二次校验与服务端二进制流真实校验（magic bytes、MIME解析、扩展名一致性）才能保障安全。
accept 属性根本不能提升后端安全性
它对后端接口零影响——用户删掉 accept 属性、用 curl 直传、拖拽伪造文件，后端照样收到。所有指望靠它防攻击的逻辑，上线即失效。
它的唯一作用是：让浏览器文件选择框默认只显示匹配的文件（比如 accept="image/*" 时，macOS Finder 默认隐藏 .exe）。但用户点“显示全部”就全出来了，iOS Safari 甚至可能因太严而禁用相册入口。
-
accept不校验内容，不拦截提交，不修改event.target.files列表 - 移动端 WebView（如华为 EMUI、小米 MIUI）常直接忽略该属性
- 服务端收到的
Content-Type请求头可被任意伪造，$_FILES['file']['type']或req.file.mimetype全部不可信
accept 值写错，连提示效果都丢
写法不对，连“减少误选”这个基本体验都做不到。关键不是语法对不对，而是真正在多少设备上起作用。
- 必须同时提供 MIME 类型和扩展名：
accept="application/pdf,.pdf"，单写.pdf在 iOS Safari 上大概率失效 - Excel 必须写成
accept="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet,.xlsx"，只写.xlsx在部分 Edge 版本里不生效 - 逗号后绝对不能有空格：
accept="image/png,.jpg"✅，accept="image/png , .jpg"❌（旧版 Safari 解析失败） - 避免模糊通配符：
text/*会匹配text/html，而 HTML 文件上传后可能被服务端误执行
前端 JS 必须做的二次过滤
用户选完文件后，change 事件拿到的 event.target.files 是原始数据，accept 完全没筛过它。你得自己遍历、比对、提示、禁用提交。
-
file.type不可靠——重命名过的文件（如hack.html改成data.jpg）type可能是image/jpeg，但内容是 HTML - 优先用
file.name.toLowerCase().match(/\.(jpg|jpeg|png|pdf)$/i)做扩展名白名单比对 - 关键业务加 magic bytes 校验：用
FileReader读前 4 字节，PNG是89 50 4E 47，PDF是25 50 44 46 -
multiple场景下别只检查第一个：Array.from(files).filter()，实时提示“已选 2 个不支持的文件(scan.tif,data.zip)”
后端才是唯一安全边界
前端所有操作只是体验优化。真正有效的校验必须在服务端完成，且必须基于二进制流本身。
- 不信任客户端传来的
Content-Type，用服务端库解析真实 MIME：Node.js用file-type，Python用python-magic，Java用Apache Tika - 校验文件头（magic bytes）：比如
.xlsx必须以PK\x03\x04开头，.pdf必须以%PDF开头 - 验证扩展名是否与真实 MIME 一致（防伪装：.jpg 文件内容其实是 HTML）
- 保存时剥离原始扩展名，用随机名 + 白名单后缀（如
abc123.pdf），上传目录禁止执行权限
最容易被忽略的一点：form 标签漏设 enctype="multipart/form-data"，会导致后端根本收不到文件字段——req.file 为 undefined、$_FILES 为空，错误信息不明确，排查时容易卡在前端 JS 逻辑里。
