windows phone 浏览器（ie mobile/edge mobile）完全不支持 accept 属性，所有版本均忽略该属性，文件选择器始终显示“所有文件”，无法实现类型过滤，必须依赖 js 前端后缀校验与服务端三重验证。
accept="image/*" 在 Windows Phone 浏览器中基本不生效，不是“过滤无效”，而是根本没被实现。
Windows Phone 的 IE Mobile 完全不支持 accept 属性
所有 Windows Phone 版本（包括 WP8.1 和 Windows 10 Mobile）搭载的 IE Mobile 或 Edge Mobile（旧版）均未实现 accept 属性。这不是兼容性差异，是功能缺失——浏览器直接忽略该属性，文件选择器照常显示“所有文件”。
- IE Mobile 11（WP8.1）：无任何
accept行为，连 MIME 类型解析都跳过 - Edge Mobile（2015–2017 年版本）：同样未启用该属性，
accept被静默丢弃 - 实测表现：用户可任意选 .exe、.pdf、.txt，毫无限制提示
为什么不能靠 accept 做 Windows Phone 的类型控制？
因为底层没有调用操作系统级的文件类型过滤 API。现代桌面/Android/iOS 浏览器会把 accept 映射到系统原生对话框的 types 参数，而 Windows Phone 的 WebView 组件压根没桥接到这层。
Comet AI 浏览器
下载
下载 Comet AI 浏览器，体验由 Perplexity AI 驱动的革命性上网方式。内置 AI 助手可实时总结网页、跨标签页对比信息、自动执行任务。告别繁琐操作，让 AI 成为你的浏览副驾，大幅提升研究与工作效率。支持 Windows、macOS、Android 和 iOS。
- 即使写成
accept="image/png,image/jpeg,.jpg,.png"，也完全无反应 - 不存在“部分支持”或“仅支持扩展名”的中间状态——就是不读这个属性
- 你看到的“能选图片”只是巧合：用户恰好点了图库，不是浏览器过滤的结果
替代方案必须前端 + 后端双保险
在 Windows Phone 环境下，accept 无法承担任何过滤职责，只能当作占位符或未来兼容标记。真实校验必须立刻落到 JS 和后端：
- JS 层立即检查
e.target.files[0].type和.name，但注意：.type在 WP 上常为空字符串，得靠后缀粗筛（如file.name.toLowerCase().endsWith('.jpg')） - 服务端必须做三重验证：文件头（magic bytes）、实际 MIME 解析、扩展名白名单，缺一不可
- 别信
size或lastModified—— 这些字段在 WP 上返回值不稳定，容易误判
真正棘手的点不在写法，而在于：你无法通过用户行为反推浏览器能力。一个用户上传了 .png，不代表 accept 生效了；他可能只是手动进了相册文件夹——而这在 Windows Phone 上完全不可控。
