文件上传控件的业务标签不能依赖name属性区分，必须通过data-context显式绑定业务类型，并在前端打标、后端校验一致性，确保上传意图明确、安全可控。

给文件上传控件加业务标签不能靠 name 做区分

多个上传入口共存时（比如“身份证正面”“身份证反面”“营业执照”），很多人直接给每个 <input type="file"> 设不同 name，以为后端能靠这个区分业务含义——但实际中，name 只是表单字段名，不携带语义上下文。如果用户一次选了多个文件、或用 JS 手动构造 FormData，name 就失去业务标识能力。

真正可靠的方式是：在触发上传前，显式绑定业务标签到每个文件实例上。

• 用 data-* 属性标记 label 或 input 的业务类型，例如 <input type="file" data-context="id-card-front">
• 监听 change 事件时，从事件源取 dataset.context，再遍历 e.target.files，为每个 File 对象打标（可用 Object.defineProperty 或封装为带标签的 { file, context } 对象）
• 构造 FormData 时，不直接 append File，而是 append new Blob([file], {type: file.type}) 并指定带业务前缀的 key，例如 formData.append("file_id-card-front", file)

accept 和 capture 不是业务标签，只是筛选条件

accept="image/*" 或 capture="environment" 控制的是用户能选什么、调用哪个设备，和“这是哪类业务文件”完全无关。它们不会出现在上传数据里，也不影响后端解析逻辑。

常见错误是把 accept 当成业务分类依据，比如设 accept=".pdf" 就认为“这一定是合同”，结果用户手动改后缀绕过，或拖入伪造 PDF 头的恶意文件——业务标签必须由前端主动注入、后端强制校验，不能依赖浏览器 UI 层的限制。

立即学习“前端免费学习笔记（深入）”；

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

后端收到文件后必须验证业务标签一致性

即使前端打了标，HTTP 请求里仍可能被篡改。所以后端不能只看 Content-Disposition 中的 name 字段，而要：

• 检查请求体中是否包含预期的业务字段名（如 file_id-card-front），缺失即拒收
• 对同一批上传的多个文件，比对它们的业务上下文是否冲突（例如同一请求里同时出现 id-card-front 和 id-card-back 是合理，但出现两个 id-card-front 就该告警）
• 存储时将业务标签写入数据库元数据字段，而非仅靠文件名或路径推断（避免 “upload_123.pdf” 这种无意义命名）

动态生成上传控件时，id 和 data-context 必须同步更新

React/Vue 项目里常通过循环渲染多个上传区，容易漏掉 data-context 绑定，或重复使用同一个 id 导致 label 点击失效。更隐蔽的问题是：JS 触发 click() 时，若控件是异步挂载的，dataset.context 可能还是 undefined。

安全做法是：

• 用组件级唯一 key 生成 id 和 data-context，例如 id={`upload-${index}`} + data-context={`contract-signature-${index}`}
• 在 change 回调里用 this.dataset.context（非 e.target.dataset）确保取到当前控件上下文
• 避免在 useEffect 或 mounted 里立即调用 click()，先 setTimeout(() => input.click(), 0) 确保 DOM 渲染完成

业务标签不是锦上添花的装饰，它是前后端对齐文件意图的最小契约。漏掉它，上传功能就退化成“扔一堆二进制过去，猜后端怎么处理”。