accept属性仅作界面提示，无法真正限制文件类型；必须结合前端JS二次校验（扩展名+magic bytes）与后端二进制头解析、重命名存储，才能保障安全。
accept 属性根本不能限制文件类型，它只影响文件选择框的默认显示，所有“限制上传”的想法都是错的。
accept="image/*" 为什么还能选到 .psd 或 .svg
浏览器用 accept 做的是界面提示，不是过滤器。macOS 文件选择器会默认隐藏不匹配的文件，但用户点“显示所有”就全出来了；Safari 可能放行 image/svg+xml，而 SVG 能嵌脚本；Chrome 对 image/* 的理解比规范更宽，image/vnd.adobe.photoshop（即 .psd）也会出现。这不是 bug，是设计如此。
-
accept="image/*"不等于“只允许 JPG/PNG”，它不校验内容、不拦截提交、不干预event.target.files列表 - 移动端更明显：华为 EMUI、小米 MIUI 的 WebView 常直接忽略 accept，iOS Safari 则可能因太严导致相册无法选图
- 如果你靠它防恶意文件，攻击者删掉 HTML 里的 accept 属性、用 curl 传、或拖拽一个伪造的
report.jpg（实际是 HTML），全部畅通无阻
accept 值怎么写才不会白配
写法不对，连提示效果都打折扣。重点不是“对不对”，而是“在多少设备上真起作用”。
- 必须同时提供 MIME 类型和扩展名，比如 CSV：用
accept="text/csv,.csv"，而不是只写.csv或只写text/csv - Excel 文件要写成
accept="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet,.xlsx"，单写.xlsx在 iOS Safari 上大概率失效 - 逗号后绝对不能有空格：
accept="image/png,.jpg"✅，accept="image/png , .jpg"❌（旧版 Safari 解析失败） - 避免模糊通配符：
text/*会匹配text/html，而 HTML 文件上传后可能被服务端误执行，应显式写text/plain,.txt,.log
前端 JS 必须做的二次过滤
用户选完文件后，change 事件里拿到的 event.target.files 是“原始数据”，accept 完全没筛过它。你得自己遍历、判断、提示、禁用提交。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
-
file.type不可靠——重命名过的文件（如hack.html改成data.jpg）type 可能是image/jpeg，但内容是 HTML - 优先用
file.name.toLowerCase().match(/\.(jpg|jpeg|png|pdf)$/i)做扩展名白名单比对 - 关键业务加 magic bytes 校验：用
FileReader读前 4 字节，PDF 是%PDF（十六进制25 50 44 46），PNG 是89 50 4E 47 - 多文件场景下，别只检查第一个：
Array.from(files).filter(...)，实时提示“已选 2 个不支持的文件（scan.tif, data.zip）”
后端才是唯一安全边界
前端所有操作，包括 accept 和 JS 校验，都只是优化体验。后端收到的每个文件，都必须当作“完全不可信”来处理。
- 不信任
Content-Type请求头——它由浏览器生成，可轻易伪造 - 必须读取文件二进制流前若干字节，用
file-type（Node.js）、python-magic（Python）等库解析真实 MIME - 扩展名和解析出的 MIME 必须逻辑一致：比如文件头说是
image/jpeg，但扩展名是.exe，直接拒绝 - 存储时强制重命名：剥离原始
name，用服务端生成的随机字符串 + 白名单后缀（如a7f3b2e9.jpg）
最容易被忽略的一点：很多团队把 accept 当作“已校验”的信号，结果上线后发现用户上传的 .csv 实际是 Excel 表格（MIME 是 application/vnd.openxmlformats-officedocument.spreadsheetml.sheet），或者 .pdf 文件头被篡改过——这些只有后端读文件头才能发现。
