accept属性仅优化文件选择器体验，无法替代JavaScript校验；必须结合file.type、file.name及file.size进行前端二次验证，并在安全要求高时用FileReader读取文件头魔数校验。
仅靠 accept 属性不能真正校验图片类型，它只影响系统文件选择器的默认过滤行为，用户仍可手动切换为“所有文件”并选中任意格式。必须配合 JavaScript 做二次校验，否则前端验证形同虚设。
accept 属性只能过滤文件选择器，不是安全校验
accept="image/*" 的作用是告诉浏览器：“在弹出的本地文件选择窗口里，默认只显示图片类文件”。但它不阻止用户点击下拉菜单改成“所有文件（*.*）”，然后选一个 .exe 或 .pdf 上传。IE9 及更早版本甚至完全忽略该属性。
常见错误现象：
- 用户上传了
fake.png，实际是压缩包，file.type返回空字符串或application/octet-stream - 某些安卓 WebView 中
accept完全失效，file.type恒为空 - 后缀名被手动篡改（如把
report.docx改成report.jpg），file.type仍可能返回image/jpeg
所以 accept 只能作为体验优化手段，绝不能替代 JS 校验。
立即学习“前端免费学习笔记（深入）”；
用 file.type 和 file.name 双重判断更可靠
file.type 是浏览器根据文件头和扩展名推测的 MIME 类型，file.name 提供原始后缀。两者结合能覆盖多数误判场景。
实操建议：
- 优先检查
file.type.startsWith('image/')，这是最轻量的判断 - 若
file.type为空（常见于移动端），退而检查file.name.toLowerCase().match(/\.(jpg|jpeg|png|gif|bmp|webp)$/) - 避免只依赖后缀名匹配，比如
file.name.endsWith('.jpg')—— 用户可能传photo.JPG或scan.jpeg.txt - 不要用
file.name.substring(file.name.lastIndexOf('.'))，它无法处理无后缀或带点号的文件名（如my.photo.png）
示例逻辑：
function isValidImage(file) {
if (file.type && file.type.startsWith('image/')) return true;
const ext = file.name.toLowerCase().match(/\.[a-z0-9]+$/);
return ext && /\.(jpg|jpeg|png|gif|bmp|webp)$/.test(ext[0]);
}file.size 校验必须放在 change 事件里，且要清空 input.value
用户选中超大文件后，如果不主动清空 input.value，下次再选同一文件时 change 事件不会触发 —— 因为 DOM 值没变。这是最常被忽略的细节。
关键步骤：
- 在
change回调中立即读取event.target.files[0]，不要缓存到外部变量 - 校验失败后必须执行
event.target.value = ''，否则无法重复触发事件 - 大小阈值建议用字节比较（如
file.size > 5 * 1024 * 1024），避免浮点精度问题（(file.size / 1024).toFixed(0)会四舍五入失真） - 注意单位：服务端通常按字节接收，前端也统一用字节，别混用 KB/MB
真实项目中还要防“假图片”：用 FileReader 读取 header 字节
当安全要求较高（如用户头像、资质上传），仅靠后缀和 MIME 不够。真正的图片文件开头有固定字节标识（如 PNG 是 89 50 4E 47，JPEG 是 FF D8 FF）。这时需用 FileReader 读取前几个字节做魔数校验。
这步开销小但有效：
- 只读取
file.slice(0, 4)，不加载整个文件 - 用
reader.readAsArrayBuffer()+new Uint8Array(buffer)提取字节 - 比完整解析图片快一个数量级，且无法被后缀欺骗
- 注意 Safari 对
slice()的兼容性，iOS 13+ 已稳定支持
复杂点在于：这个逻辑必须异步，不能阻塞 change 事件流；而且一旦引入 FileReader，就得处理其 onload/onerror 两套回调分支 —— 很多人在这里漏掉错误兜底，导致上传流程静默中断。
