先记住这个答案
不能。accept 只影响文件选择器的默认筛选和可选项高亮，用户在许多系统中可切换为“所有文件”而选择任意类型。因此必须把类型校验放在前端读取文件后（检查 File.type 和扩展名）以及服务端上传前。若校验失败，应清晰提示用户可接受的类型，并阻止提交或上传。
- accept 只是 UI 提示，可被绕过
- 前端需读取 File.type 再校验
- 服务端校验是最后防线
accept 如何工作：选择器过滤与用户覆盖
accept 的值是逗号分隔的文件类型说明符，例如 .jpg、image/png、image/*。浏览器在打开文件选择器时用这些说明符去匹配文件的 MIME 类型或扩展名，使不匹配的文件在对话框中变灰或隐藏。这个机制主要依靠操作系统的文件对话框能力，并非 HTML 标准强制。
用户若在文件对话框中把类型下拉框从“自定义文件”切到“所有文件”，就可以选择任何文件。MDN 明确说明用户可覆盖此行为，因此 accept 不能阻止用户提交一个即使扩展名伪造的文本文件或脚本。它节省的是用户寻找正确文件的时间，而非提供安全保证。更深层，accept 中的类型列表如 *.docx 代表的是扩展名，而操作系统根据 MIME 类型判断时可能存在扩展名与内容不符的情况，所以无论如何都需要在拿到 File 对象后重新验证。
图片上传场景：前端校验兜底与提示
假设站点头像上传仅允许 JPEG 和 PNG。如果只写 accept="image/jpeg,image/png"，用户在 Windows 文件对话框中可切到“所有文件”挑一个 .webp 或 .txt 的文件，选择器不会拦截。提交后服务端若不做类型检查，可能把 WebP 当作 PNG 解析，或许浏览器能猜出格式，接口数据类型错误。
此时前端应在 change 事件中读取 FileList，对每个文件检查 file.type 是否严格等于 'image/jpeg' 或 'image/png'。由于很多系统会给文件标错 MIME（例如把 JPG 标为 image/jpg 或空值），可同时用扩展名正则作为辅助核对。校验不通过时，立即清空 input.value 并显示明确报错，告诉用户“仅支持 JPG 或 PNG 文件”，避免用户误以为已成功选择。
容易失效的条件与对应处理
只依赖 file.type 有时也会失效：SVG 文件常被标记为 image/svg+xml，在一些环境可能为空；macOS 把某些无扩展名的文件 type 留空。此时可结合扩展名做白名单判断。不要尝试通过读取文件头去嗅探 MIME，因为浏览器不保证 FileReader 读到的内容能可靠映射到类型，而且这会破坏用户隐私？不，读文件头是有的但成本高且复杂。
前端校验不可能覆盖所有文件类型识别差异，最佳实践是服务端用可靠库（如检查文件头 magic number）验证上传内容。失败时返回 4xx 状态码和结构化错误消息，前端捕获后把页面错误信息和自动清除待传文件整合。若用户反复上传错误文件，应提示他检查扩展名，而非只返回“上传失败”。这样可以梯度兜底，从 UI 到网络层都不让错误数据悄悄通过。
容易答错的地方
- 认为 accept 能阻止恶意文件
- 它只是选择器提示，不阻止用户选择其他文件。即使没有绕过选项，也可通过拖放或开发者工具伪造 request。正确认识：它仅供用户体验，真正的限制必须存在于上传逻辑。
- 只用扩展名判断文件类型
- 扩展名可伪造且不反映内容。例如把脚本改名 .jpg 可绕过扩展名检查。应优先看 File.type，并结合服务端魔数检测。浏览器提供 File.type 而扩展名来自 name，两者都不能完全信任。
面试官还会怎么问？
前端校验过还需要后端校验吗？
需要。攻击者可直接构造 multipart 请求绕过前端，且 File.type 也可能被伪造。后端应根据文件内容进行检测，任何仅基于前端的校验都能被规避。
如何设计用户友好的失败提示？
在校验失败时，用清晰的文字说明允许的扩展名或 MIME，并清空 input.value 防止误提交。不要只弹“文件无效”，而应指明当前文件是什么类型，以及接受的标准。
List 里文件逐个校验怎样处理？
循环 FileList，可用 Array.from(files).every(f => checkType(f))。一旦有不合格文件，就标记整个选区无效，并提示第几个文件不符；不要只保留合法文件，静默丢弃会让用户困惑。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。