修改accept属性仅在input初始化时生效，后续JS赋值无效；需重建元素并同步属性，且必须用change事件+文件名后缀匹配做二次校验，服务端校验不可省略。
修改 accept 属性只能在 <input type="file"> 初始化后生效
浏览器对 accept 的校验是“只读式”的：它只在用户点击文件选择框时起作用，且仅读取元素创建时或首次渲染时的属性值。后续用 JavaScript 修改 element.accept = ".pdf" 不会改变系统弹出的文件过滤器——Windows/macOS 原生对话框仍按初始值过滤。
真正可行的做法是重建 input 元素（保留 name、id 等关键属性），或更稳妥地：在用户触发选择前，动态生成新 input 并替换旧节点。
- 不要写
inputEl.accept = "image/*"期望立刻生效 - 若需切换格式（如从 PDF 切到图片），先
inputEl.remove()，再用document.createElement("input")创建带新accept的元素 - 注意同步复制
name、id、multiple、required等业务必需属性 - 如果用了
<label for="xxx">，记得更新 label 的for属性或改用包裹方式避免绑定失效
用 change 事件 + file.type / file.name 做二次校验
accept 是弱约束，仅影响文件选择界面；绕过它非常容易（比如手动输入文件名、拖拽非匹配类型）。所以必须在 JS 层做运行时检查。
核心逻辑是监听 input 的 change 事件，遍历 e.target.files，用以下方式判断：
立即学习“前端免费学习笔记（深入）”；
- 检查
file.type：适用于标准 MIME 类型（如"image/png"），但不可靠——浏览器可能返回空字符串或错误类型 - 更稳的是用
file.name.match(/\.(pdf|jpg|png)$/i)做后缀匹配 - 对关键业务（如上传合同），建议两者结合：
file.type.startsWith("application/pdf") || file.name.toLowerCase().endsWith(".pdf") - 校验失败立即清空
input.value = ""，否则下次 change 不会触发（因为文件没变）
多格式场景下，避免硬编码 accept 字符串
当页面支持多种上传模式（如“证件照”“合同扫描件”“音频反馈”），把 accept 写死在 HTML 或 JS 字符串里会导致维护困难、易出错。
推荐用数据驱动方式管理：
- 定义配置对象：
const acceptRules = { idPhoto: "image/*", contract: ".pdf,.doc,.docx", audio: "audio/*" } - 切换模式时，调用函数：
updateFileInput(inputEl, acceptRules.contract) - 函数内部执行元素重建 + 属性同步，而不是直接赋值
accept - 顺便把
data-max-size、data-allowed-count也纳入同一配置体系，保持一致性
移动端 capture 与 accept 的兼容性冲突
在 iOS Safari 和部分安卓 WebView 中，同时设置 accept="image/*" 和 capture="camera" 可能导致相机无法唤起，或直接 fallback 到文件选择器。
这不是 bug，而是规范未明确定义的行为。实际开发中要明确优先级：
- 若强调拍照体验，去掉
accept，用 JS 在change后校验file.type和尺寸 - 若强调格式安全，放弃
capture，接受用户从相册/文件管理器选图 - 测试真机：iOS 17+ 对
accept+capture组合支持更好，但 Android 各厂商 WebView 差异大，不能假设一致
accept 就限制住了用户，其实只是藏起了选项；真正拦住非法文件的，永远是 change 事件里的字符串匹配 + 服务端双重校验。 
