前端直接读取服务器txt文件大小，核心答案是：浏览器出于安全限制，无法直接获取文件大小，必须通过服务器响应头或API接口间接获得。
为什么前端读取服务器txt文件大小不能一步到位
很多刚入门的朋友第一反应是：用文件输入框拿一下file.size不就行了？这个思路只适用于用户本地上传的文件，服务器上的txt文件，在浏览器里根本没有对应的File对象,浏览器安全模型不允许JavaScript随意访问服务器文件系统的元数据。
业内专家指出，HTTP协议本身已经把文件大小信息放在了响应头里，前端需要做的就是想办法把这个头信息读出来，这个过程不复杂,但有几个细节值得说透。
前端读取服务器txt文件大小的主流方案
用HTTP HEAD请求探测大小
HEAD请求和GET请求很像，区别在于服务器收到HEAD请求后只返回响应头，不返回响应体，这意味着你拿到的txt文件大小的同时,省下了下载整个文件的带宽和时间。
实际操作时，可以用fetch的HEAD方法：
async function getTxtSize(url) {
const response = await fetch(url, { method: 'HEAD' });
const size = response.headers.get('Content-Length');
return size ? parseInt(size, 10) : null;
}
// 调用示例
const size = await getTxtSize('/logs/access.txt');
console.log(`文件大小是 ${size} 字节`);
这段代码的核心就是通过Content-Length响应头拿到文件大小。如果服务器没有返回Content-Length头，这种方式拿到的就是null，遇到这种情况,得看后面的方案。
Range请求只下载第一个字节也能拿到大小
有些服务器默认不返回Content-Length头，或者返回的是Transfer-Encoding: chunked,这时候HEAD请求就失灵了。
换个思路：用Range头请求文件开头的1个字节，服务器如果支持分片，会在响应头里返回完整的Content-Range信息,格式是这样的：
Content-Range: bytes 0-0/204800最后的204800就是文件总大小,这段逻辑用代码实现就是：
async function getTxtSizeWithRange(url) {
const response = await fetch(url, {
headers: { 'Range': 'bytes=0-0' }
});
// 状态码206表示服务器支持Range请求
if (response.status === 206) {
const contentRange = response.headers.get('Content-Range');
const totalSize = contentRange.split('/')[1];
return parseInt(totalSize, 10);
}
return null;
}
状态码206是分片请求成功的标志
，如果服务器不支持Range，返回的是200整文件,那就只能走第三个方案了。
整文件下载后获取大小
这是最原始的办法：把整个txt文件下载下来，再用Blob的size属性获取大小。
async function getTxtSizeByDownload(url) {
const response = await fetch(url);
const blob = await response.blob();
return blob.size;
}
这个方案最直接，但缺点同样明显：如果文件很大，可能会占用大量内存。只适合txt文件本身不大的情况，对于几十兆甚至上百兆的日志文件,强烈不建议用这个方法。
不同服务器后端怎么配合返回txt文件大小
nginx服务器下的场景
如果你有服务器配置权限，nginx默认会在静态文件响应头中带Content-Length，前端用方案一就能直接工作，不需要额外配置，唯一要注意的是nginx开启了gzip压缩后，Content-Length返回的是压缩后的大小，不是txt源文件的实际大小，这时候要看Content-Encoding头来判断数值是否被压缩过。
Node.js后端返回txt文件大小
在Node.js里，用fs.stat获取文件大小后通过HTTP头返回：
const fs = require('fs');
const http = require('http');
http.createServer((req, res) => {
if (req.url === '/api/txt-size') {
const stats = fs.statSync('./files/example.txt');
res.writeHead(200, {
'Content-Type': 'application/json'
});
res.end(JSON.stringify({ size: stats.size }));
}
}).listen(3000);
这种情况下前端只需要请求这个API接口，不用关心HTTP头细节。API方式的好处是后端可以自由控制返回值格式，顺便返回修改时间、编码格式等额外信息。
Python Flask后端返回txt文件大小
Flask里用send_file前先取一下大小：
from flask import Flask, jsonify
import os
app = Flask(__name__)
@app.route('/api/txt-size')
def get_txt_size():
file_path = './files/example.txt'
size = os.path.getsize(file_path)
return jsonify({'size': size})
前端用普通的GET请求就能拿到JSON格式的size字段，这种场景多用于前端做文件管理面板、日志查看器等工具化界面。
前端读取txt文件大小的实际应用场景
日志查看器的分页加载
运维监控平台的前端经常要展示服务器上的txt日志文件，如果一次性把整个文件拉下来，浏览器会卡死。
常见的做法是先用HEAD请求拿到文件总大小，再结合Range请求按需加载片段。
比如一个5MB的日志文件，前端先拿到5222400字节这个总量，然后分页请求每5000字节的内容，滚动时按需追加，既流畅又节省带宽，做前端时,文件大小这个数值还用于计算总页数和滚动条的进度比例。
大文件下载进度条
有的网站提供txt文件下载服务，且文件体积不小，上传下载进度条前，需要先知道文件总量，用HEAD请求拿到Content-Length后，配合XMLHttpRequest的progress事件,就能算出准确的下载百分比。
const xhr = new XMLHttpRequest();
xhr.open('GET', '/files/archive.txt');
xhr.responseType = 'blob';
// 注意：这里是增量接收时不断累计
xhr.onprogress = function(e) {
if (e.lengthComputable) {
const percent = (e.loaded / e.total 100).toFixed(2);
console.log(`下载进度：${percent}%`);
}
};
这个场景中，e.total本身就是从响应头里解析出来的,原理跟方案一完全一致。
CDN与静态资源场景下的txt大小读取
有些txt文件会放在CDN上，比如使用简米云OSS或酷番云COS托管的文件，CDN节点默认会带上Content-Length，但如果你在CDN层面开启了gzip压缩或内容转换，前端拿到的大小值就和源文件不一致了。判断方法很直接：看响应头里Content-Encoding字段，如果是gzip或br，那你拿的是压缩后的传输大小，对于txt这种纯文本文件来说,压缩前后体积差距可能有好几倍。
实际项目中的代码封装
前面几种方案可以封装成一个通用函数,根据服务器的实际表现自动降级：
async function getRemoteTxtSize(url) {
// 优先尝试HEAD请求
const headResp = await fetch(url, { method: 'HEAD' });
const headSize = headResp.headers.get('Content-Length');
if (headSize) {
return parseInt(headSize, 10);
}
// 尝试Range请求
const rangeResp = await fetch(url, { headers: { 'Range': 'bytes=0-0' } });
if (rangeResp.status === 206) {
const contentRange = rangeResp.headers.get('Content-Range');
return parseInt(contentRange.split('/')[1], 10);
}
// 最后兜底：下载整个文件
const fullResp = await fetch(url);
const blob = await fullResp.blob();
return blob.size;
}
这个函数把三层方案串起来了，放在前端工具集里随时调用，需要注意的一点是，fetch跨域场景下服务器必须开启CORS并暴露相关响应头，否则headers.get('Content-Length')
拿不到值。
前端读txt文件大小容易踩的坑
跨域导致响应头读不到
项目部署在不同域名下调用API，浏览器默认拿不到响应头字段，需要在服务器上配置CORS的expose-headers：
Access-Control-Expose-Headers: Content-Length, Content-Range否则就算响应头里有数据，前端读出来也是null，这个坑出现的频率极高,排查起来也很隐蔽。
Content-Length丢失
如果服务器开启了HTTP/2，某些情况下响应头里不会明确给出Content-Length，而是采用分帧传输，使用HTTP/2时，前端读取大小要依赖Content-Range或额外接口，不能把Content-Length当作唯一指望。
gzip压缩后的尺寸迷惑
nginx默认对txt文本开启gzip，前端的Content-Length拿到的可能是压缩后的字节数，后端fs.stat拿到的是源文件字节数，两个数值对不上，会让排查问题的人抓狂，判断的时候先看Content-Encoding是什么,再做换算。
常见问题
前端怎么准确获取服务器txt文件大小？
最准确的方法是通过HTTP请求的响应头Content-Length字段获取，用fetch发一个HEAD请求，读取headers.get('Content-Length')并转为数字即可，如果服务器没返回这个字段，就用Range: bytes=0-0方式读取Content-Range里的总大小值。
fetch拿到的文件大小和服务器上的实际文件大小不一致是什么原因？
多数情况下是压缩层导致，服务器开启了gzip或brotli压缩后，传输层的Content-Length是压缩后的体积，还有个可能：CDN节点分片传输时，响应头里没有Content-Length，而后端程序通过fs.stat或类似系统调用读到的文件大小才是源文件真实体积。
服务器不返回Content-Length时还能获取txt文件大小吗？
能，先尝试Range请求读取Content-Range响应头，这个头里的后面的数字就是文件总字节数，服务器也不支持Range请求的话，就只能下载整个文件后用Blob.size获取了。
回到出发点上：前端获取服务器txt文件大小的本质，是和服务器在HTTP协议层面协作完成的一场信息交互，掌握HEAD请求和Range请求这两种轻量级方式，足够应对绝大多数项目需求，遇到没有响应头的情况时，合理地用接口兜底，不要让前端硬扛，这套思路不仅适用于txt文件，任何远程静态资源的大小获取都能通用,希望读完你可以直接用在项目里。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/744947.html
