不能。accept仅是前端提示性约束，无法真正阻止用户选择不合规文件，用户可通过“所有文件”切换、拖放或粘贴绕过，后端必须基于文件头（magic bytes）进行二进制校验，否则存在任意文件上传风险。
accept属性能真正阻止用户选择不合规文件吗
不能。accept 只是提示浏览器在文件选择器中过滤可选文件类型，属于前端提示性约束，用户完全可以通过“所有文件”切换绕过，或直接拖入/粘贴非法文件。后端必须重新校验，否则存在上传任意文件风险。
常见错误现象：开发者只靠 accept="image/*" 就认为上传的一定是图片，结果收到 .exe 或 .html 文件，甚至触发 XSS 或服务端路径遍历。
-
accept的值不影响实际文件内容，仅影响原生<input type="file">弹窗的默认筛选项 - Chrome 和 Edge 支持较完整（如
accept=".pdf,.docx"），Safari 对扩展名支持弱，更倾向 MIME 类型匹配 - 移动端（尤其 iOS）对
accept响应不稳定，有时完全忽略
accept写法：MIME 类型 vs 扩展名，哪个更可靠
MIME 类型（如 image/png）语义准确但覆盖不全；扩展名（如 .jpg）直观但易伪造。实际应组合使用，优先列 MIME，再补关键扩展名。
示例：<input type="file" accept="image/*,.png,.jpg,.jpeg,.gif">
立即学习“前端免费学习笔记（深入）”；
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
-
image/*匹配大部分浏览器识别的图片 MIME，但不包含 WebP（需显式加image/webp） -
.pdf在多数浏览器中有效，但 Safari 可能不识别，建议同时加application/pdf - 避免写
accept="*"—— 这等价于未设置，且部分旧浏览器会报解析警告 - 多类型用英文逗号分隔，**不要空格**：
accept="text/plain,text/csv"✅，accept="text/plain, text/csv"❌（空格会导致 Safari 忽略第二项）
用户选了违规文件，怎么在 JS 里及时拦截
不能依赖 change 事件中只看 files[0].type，因为浏览器可能无法正确识别 MIME（如重命名的 .jpg 文件返回空字符串或 text/plain）。必须结合 name 后缀 + 文件头（magic bytes）做轻量校验。
简单实用做法：
- 先检查
file.name是否匹配允许的扩展名（用file.name.toLowerCase().endsWith(".jpg")） - 再读取前 4 字节判断文件头：
new Uint8Array(await file.slice(0, 4).arrayBuffer())，比对 JPEG（[0xFF, 0xD8, 0xFF]）、PNG（[0x89, 0x50, 0x4E, 0x47]）等 - 注意
file.type在用户手动改后缀时不可信，file.name也可能被伪造，但文件头极难伪造 - 不要在
change回调里直接submit()，先异步校验，失败则input.value = ""清空并提示
后端校验必须做哪些事，光看 Content-Type 不行
后端拿到文件后，Content-Type 请求头和 filename 都可被客户端任意篡改，唯一可信的是文件二进制内容本身。
- 必须读取文件前若干字节（至少 4–8 字节），比对 magic number，例如 PDF 必须以
%PDF（0x25 0x50 0x44 0x46）开头 - 限制上传目录权限，禁止执行权限，存放路径与 Web 访问路径分离（如不放在
/public下） - 对图片类文件，用 ImageMagick 或 Sharp 等库解码一次，防止恶意构造的“图片”触发解析器漏洞
- 若业务允许，重命名文件（如 UUID + 安全扩展名），彻底剥离原始
filename的影响
最常被忽略的一点：前端 accept 和 JS 校验只是体验优化，只要后端没做二进制层校验，上传门就一直开着。
