一、为什么要选择无组件上传？先搞懂传统方案的坑
咱们先聊聊传统方案到底有哪些问题，你可能没意识到，很多时候我们依赖组件库其实是“过度设计”了。就拿文件上传来说，市面上主流的UI组件库（比如某Element、某Ant Design）确实提供了现成的上传组件，功能看起来很全：进度条、拖拽上传、预览缩略图……但这些“全功能”背后，是大量你可能根本用不上的代码。
我去年帮一个朋友的电商项目优化性能，他们的商品管理后台用了某组件库的上传组件，我打开浏览器开发者工具一看，光是上传相关的代码就占了整个前端包体积的18%——里面包含了各种兼容性处理（比如支持IE8的古老代码）、冗余的动画效果，还有好几个咱们项目根本用不上的功能模块（比如文件夹上传、断点续传）。后来换成无组件方案，直接砍掉了85%的冗余代码，打包体积小了近2MB，页面加载速度快了1.2秒，后台用户都说操作流畅多了。
除了体积问题，样式定制也是个大麻烦。组件库的上传按钮样式往往和设计稿差得远，你想改个边框圆角、调整一下 hover 颜色，可能要写一堆优先级很高的 CSS 去覆盖组件默认样式，甚至还要用 !important，维护起来特别费劲。我之前接手过一个项目，前任开发者为了让上传组件和设计稿一致，硬生生写了400多行覆盖样式，后来我换成原生 input 实现，20行CSS就搞定了，还不用担心组件版本更新导致样式失效。
再说说性能。有些组件为了实现“优雅”的交互，会在前端做很多不必要的处理，比如把图片转换成 base64 再上传（其实直接传二进制文件效率更高），或者频繁操作DOM更新状态，导致页面卡顿。有次我做一个图片批量上传功能，用组件库的时候一次选10张图，页面就开始掉帧；换成原生方案后，同样的操作，CPU占用率直接降了60%，体验天差地别。
当然啦，不是说组件库不好，如果你项目赶时间，或者需要那些复杂功能（比如断点续传、大文件分片），用成熟组件确实能省事儿。但如果只是简单的二进制文件上传（比如图片、PDF、音频），追求轻量和灵活，那无组件方案绝对是更优解——代码自己写，逻辑自己控，出了问题也好调试，对吧？
二、无组件上传二进制文件的完整步骤：从文件选择到请求发送
接下来进入实操环节，我会把整个流程拆成4步，每一步都配上代码示例和我踩过的坑，你跟着做，半小时就能跑通一个基础版本。
第一步：用原生input实现文件选择，藏起丑按钮自定义样式
文件上传的第一步肯定是让用户选择文件，原生HTML里其实早就有现成的标签——。不过这玩意儿默认样式确实有点丑，不同浏览器长得还不一样，所以咱们的第一个小技巧就是：把原生input藏起来，用自己的按钮触发它。
你看这段代码，我把设为display: none，然后用一个自定义按钮触发它的点击事件：
<!-隐藏原生input，用户看不到但功能还在 >
<input type="file" id="fileInput" style="display: none;" accept="image/" multiple>
<!-
这是用户实际看到的按钮，样式随便你改 >
const uploadBtn = document.getElementById('uploadBtn');
const fileInput = document.getElementById('fileInput');
// 点击自定义按钮时，触发原生input的点击
uploadBtn.addEventListener('click', () => {
fileInput.click();
});
// 用户选择文件后，input会触发change事件
fileInput.addEventListener('change', (e) => {
const selectedFiles = e.target.files; // 这里拿到用户选择的文件列表
if (selectedFiles.length === 0) {
console.log('用户取消了选择');
return;
}
// 打印一下选中的文件信息，看看里面有什么
console.log('选中的文件：', selectedFiles);
// 下一步：校验文件
validateFiles(selectedFiles);
});
这里有几个细节要注意：accept="image/" 表示只允许选择图片文件，你可以改成 application/pdf 限制PDF，或者 video/ 限制视频，具体格式可以参考 MDN的MIME类型列表{rel=”nofollow”}。如果想允许选择多个文件，加上 multiple 属性就行。
我之前踩过一个坑：刚开始用div模拟按钮，结果在iOS Safari里点击没反应，查了半天才发现，iOS对非原生交互元素的点击事件支持不太好，换成原生button就没问题了。所以自定义按钮最好用标签，兼容性更靠谱。
第二步：文件校验不能少，提前拦截无效文件
用户选完文件后，别急着上传，先在校验一下——不然用户传个100MB的超大文件，或者格式不对的文件，既浪费带宽，又影响体验。校验主要看两方面：文件类型和文件大小。
咱们接着上面的代码，写一个validateFiles函数：
function validateFiles(files) {
// 允许的文件类型（MIME类型）
const allowedTypes = ['image/jpeg', 'image/png', 'image/webp'];
// 最大文件大小（5MB，1MB=10241024字节）
const maxSize = 5 1024 1024;
// 遍历所有选中的文件（如果允许多选的话）
for (let i = 0; i < files.length; i++) {
const file = files[i];
//
校验文件类型
if (!allowedTypes.includes(file.type)) {
alert(文件"${file.name}"格式不对，请上传JPG、PNG或WEBP图片);
// 清空input，避免用户再次选择时重复提交
fileInput.value = '';
return; // 校验失败，直接返回
}
//
校验文件大小
if (file.size > maxSize) {
// 把字节转成MB，方便用户理解
const fileSizeMB = (file.size / (1024 1024)).toFixed(2);
alert(文件"${file.name}"太大了（${fileSizeMB}MB），请上传5MB以内的图片);
fileInput.value = '';
return;
}
}
// 所有文件校验通过，开始上传
uploadFiles(files);
}
这里有个小技巧：fileInput.value = '' 很重要。因为如果用户先选了一个不合法的文件，被拦截后，又选了同一个文件，这时候 change 事件不会触发（因为文件没变化），用户会以为功能坏了。清空value后，每次选择都会触发事件，体验更顺畅。
我之前在一个图片社区项目里就吃过这个亏：没清空value，结果有用户反馈“选了文件没反应”，排查半天才发现是这个原因。后来加上这句代码，类似问题再也没出现过。
第三步：用FormData打包文件，学会浏览器的“快递盒”
文件校验通过后，就该准备发送给后端了。二进制文件不能像普通表单数据那样直接发，需要用 FormData 来打包——你可以把它想象成一个“快递盒”，浏览器会帮你把文件和其他参数按HTTP协议要求打包好，后端接收到就能直接解析。
FormData
的用法其实很简单，主要用 append 方法添加数据：
function uploadFiles(files) {
const formData = new FormData();
//
添加文件数据：append(后端接收的字段名, 文件对象, [可选文件名])
// 如果是多文件，字段名可以加[]，比如'files[]'，具体看后端要求
for (let i = 0; i < files.length; i++) {
const file = files[i];
formData.append('files[]', file, file.name); // 第三个参数是文件名，可选
}
//
可以顺便添加其他参数，比如用户ID、上传时间
formData.append('userId', 'currentUser123'); // 假设当前用户ID是这个
formData.append('uploadTime', new Date().toISOString());
//
打印一下FormData里的内容（注意：直接console.log(formData)看不到内容，需要用forEach）
console.log('FormData内容：');
formData.forEach((value, key) => {
console.log(${key}:, value); // 文件会显示为[object File]，正常现象
});
// 下一步：发送请求
sendUploadRequest(formData);
}
这里要注意，不同后端框架对多文件字段的要求可能不一样：有的需要字段名加[]（比如PHP），有的不需要（比如Node.js的Express）。如果后端说“收不到文件”，先检查字段名是不是匹配，我之前就因为少加了个[]，和后端同学排查了半小时，尴尬得不行。
第四步：发送上传请求，XMLHttpRequest和Fetch选哪个？
最后一步就是把FormData发送给后端了。这里有两种常用方案：XMLHttpRequest（XHR）和 Fetch API。它们各有优缺点，我帮你整理了一张对比表，你可以根据项目情况选：
| 对比维度 | XMLHttpRequest | Fetch API |
|---|---|---|
| 兼容性 | IE10+支持，兼容性好 | 现代浏览器支持，IE不支持 |
| 进度监控 | 原生支持upload.progress事件，方便做进度条 | 需要用ReadableStream，实现复杂 |
| 代码风格 | 回调函数，容易嵌套 | Promise风格，支持async/await，更简洁 |
如果你的项目需要兼容旧浏览器（比如企业内网系统可能还有IE用户），优先选 XMLHttpRequest；如果都是现代浏览器，Fetch 写起来更清爽。我两种都给你写个示例，你可以直接抄作业。
方案A：用XMLHttpRequest实现，带进度监控
XMLHttpRequest
虽然是老API，但进度监控特别方便，适合需要显示上传进度的场景：
function sendUploadRequest(formData) {
const xhr = new XMLHttpRequest();
// 配置请求：method（POST/GET）、url（后端接口）、是否异步（true）
xhr.open('POST', '/api/upload', true);
//
添加请求头（如果需要）
// 注意：Content-Type不用手动设，浏览器会自动设为multipart/form-data
xhr.setRequestHeader('Authorization', 'Bearer your-token-here'); // 比如加个认证token
//
进度监控（核心！）
xhr.upload.addEventListener('progress', (e) => {
if (e.lengthComputable) { // 如果能计算进度（文件大小已知）
const percent = (e.loaded / e.total) 100; // loaded已上传字节，total总字节
console.log(上传进度：${percent.toFixed(1)}%);
// 这里可以更新进度条UI，比如：
// document.getElementById('progressBar').style.width = ${percent}%;
}
});
//
请求成功回调
xhr.addEventListener('load', () => {
if (xhr.status >= 200 && xhr.status < 300) { // 状态码2xx表示成功
const response = JSON.parse(xhr.responseText); // 解析后端返回的JSON
console.log('上传成功：', response);
alert('文件上传成功！');
// 重置input，方便再次上传
fileInput.value = '';
} else {
console.error('上传失败：', xhr.statusText);
alert(上传失败：${xhr.statusText});
}
});
//
请求失败回调（比如网络错误）
xhr.addEventListener('error', () => {
console.error('网络错误，上传失败');
alert('网络错误，请检查网络连接后重试');
});
//
发送请求：把FormData传进去
xhr.send(formData);
}
这里要注意，xhr.upload 才是上传相关的事件对象，xhr 本身的 progress 事件是下载进度，别搞混了。我刚开始学的时候就用错了对象，结果进度条不动，还以为代码写错了。
方案B：用Fetch API实现，代码更简洁
如果你不需要进度监控，或者项目里已经在用 async/await，Fetch 写起来会更优雅：
// 因为Fetch返回Promise，所以用async函数包裹
async function sendUploadRequest(formData) {
try {
const response = await fetch('/api/upload', {
method: 'POST',
body: formData, // 要发送的数据（FormData对象）
headers: {
// 'Content-Type': 'multipart/form-data' // 注意：不要手动设置！浏览器会自动处理
'Authorization': 'Bearer your-token-here' // 其他头可以加
},
credentials: 'include' // 如果需要带cookie，加上这个
});
if (!response.ok) { // response.ok等价于status 200-299
throw new Error(HTTP错误，状态码：${response.status});
}
const result = await response.json(); // 解析JSON响应
console.log('上传成功：', result);
alert('文件上传成功！');
fileInput.value = '';
} catch (error) {
console.error('上传失败：', error.message);
alert(上传失败：${error.message});
}
}
Fetch
的坑点是：不要手动设置 Content-Type: multipart/form-data！因为浏览器会自动生成这个头，并且加上必要的分隔符（boundary），手动设置反而会导致后端解析失败。我之前就手贱加了这句，结果后端说收不到文件，排查了好久才发现是这个原因。
到这里，一个完整的无组件上传功能就实现了！代码加起来也就100多行，没有任何第三方依赖，性能好，样式还能完全自定义。你可以根据自己的需求扩展功能，比如加个文件预览（用 URL.createObjectURL(file) 生成临时预览地址），或者失败重试逻辑。
如果你按这个方法试了，欢迎回来告诉我效果怎么样，或者遇到了什么问题——毕竟实际项目里的情况可能千差万别，咱们一起讨论解决，让这个方案更完善！
大文件直接往上怼真的很容易出问题，你想啊，100MB的文件，要是网络稍微波动一下，传一半断了，又得从头再来，用户不得急死？而且服务器那边也可能因为超时把请求掐了——我之前帮一个教育平台做课程视频上传，刚开始没分片，200MB的视频传10次能失败3次，后台投诉一堆。后来改成分片上传，体验立马不一样了。
具体怎么做呢？其实就是把大文件“拆零件”。你可以定个固定大小，比如5MB一块（这个大小可以根据你们服务器的配置调，别太大也别太小，太大容易超时，太小请求太多服务器压力大），用File对象的slice方法把文件切成一堆小Blob（就像把大蛋糕切成一小块一小块）。然后每一块用FormData包起来，带上分片序号（比如第1片、第2片）、总共有多少片、还有这个文件的唯一标识——这个标识很重要，我一般用MD5哈希（你可以用spark-md5这种库生成），这样后端就知道哪些分片是同一个文件的，也能避免用户重复传同一个文件浪费流量。
传的时候用XMLHttpRequest的progress事件特别方便，每一片上传进度都能实时拿到，你可以在页面上显示“第3片/共40片，当前进度25%”，用户看着心里有数，就不会一直刷新页面了。不过这里有个坑得注意：分片序号一定要从0或1开始按顺序传，后端合并的时候才不会乱。我之前有次没控制好顺序，第5片比第3片先到后端，结果合并出来的视频后半段全是花屏，排查半天才发现是分片顺序反了——后来加了个队列，确保分片按序号一个个传，就再没出过这问题。现在那个教育平台的视频上传成功率从70%提到了98%，用户催更的投诉都少了一半。
无组件上传适合所有场景吗？哪些情况更推荐用组件库？
无组件上传并非万能方案，更适合需求简单、追求轻量灵活的场景，比如基础的图片/文档上传、自定义样式要求高、需要控制包体积的项目。如果你的项目需要复杂功能——比如断点续传（断网后继续上传）、文件夹批量上传、跨浏览器兼容性（尤其是IE8及以下）、或者现成的预览/裁剪/压缩工具，那组件库（如Ant Design Upload、Element Plus Upload）会更高效，省去重复开发成本。简单说：轻量需求自己写，复杂功能用现成的。
用原生input实现文件选择后，能添加拖拽上传功能吗？
完全可以！原生API就能实现拖拽，核心是监听元素的dragover和drop事件。具体步骤：先给容器（比如一个div）添加dragover事件，阻止默认行为（不然浏览器会直接打开文件）；再监听drop事件，通过e.dataTransfer.files获取拖拽的文件，后续逻辑和点击选择文件一致。我之前给一个后台系统加过这个功能，代码量也就30行左右，比想象中简单——你可以试试在文章里的fileInput外包裹一个div，加上这两个事件监听，就能同时支持点击和拖拽了。
无组件上传大文件（比如超过100MB）时，需要额外做什么处理？
大文件直接上传可能会超时或失败， 结合“分片上传”逻辑：把文件按固定大小（比如5MB一块）拆成多个Blob，用FormData分批发送，后端接收后再合并。这时候XMLHttpRequest的progress事件就很有用，能实时显示每个分片的上传进度。另外要注意和后端约定分片序号、总片数、文件唯一标识（比如MD5），避免重复上传。我之前处理过200MB的视频上传，用分片+进度监控后，用户体验和成功率都提升了不少。
原生方案在旧浏览器（比如IE11）上会有兼容性问题吗？
会有一些小细节需要注意。FormData在IE10+支持，但FormData.forEach方法IE不支持，遍历数据时 用for…of或传统for循环；Fetch API完全不支持IE，所以旧浏览器必须用XMLHttpRequest； File对象的某些属性（如lastModified）在IE里可能缺失。如果你的项目需要兼容IE11， 优先用XMLHttpRequest，避免使用Fetch，同时测试文件校验逻辑（比如size属性在IE里是否正常返回）。
后端接收无组件上传的文件时，需要特别配置什么参数吗？
核心是确保后端正确解析multipart/form-data格式。不用手动设置Content-Type，浏览器会自动添加multipart/form-data; boundary=xxx（boundary是分隔符，后端靠它拆分文件和参数）。后端需要注意：字段名要和前端FormData.append的key一致（比如前端用files[]，后端就用files[]接收多文件）；如果是Java Spring Boot，记得用@RequestParam(“files[]”) MultipartFile[] files；Node.js Express则需要借助multer中间件。 和后端约定文件大小限制（比如单个文件不超过50MB），避免超大文件占用服务器资源。
