前端上传文件经后端fs.createReadStream处理后传至Jenkins任务

适配后端fs.createReadStream的文件传输实现 #

fs.createReadStream的核心逻辑是根据文件系统的绝对路径寻址，读取磁盘上的实体文件生成读取流，本身无法直接处理前端传输的内存态二进制数据，要适配现有流程可按以下步骤操作：

• 前端不要使用FileReader将上传文件转成Base64/文本后塞入JSON传输，而是直接获取<input type="file">选中的File对象，通过FormData以multipart/form-data格式发起POST请求，将文件原文传给后端。对应代码逻辑：

  const fileInput = document.querySelector('input[type="file"]')
  const uploadFile = fileInput.files[0]
  const formData = new FormData()
  formData.append('buildFile', uploadFile)
  // 发起请求传递formData，不要手动设置请求头，浏览器会自动补全multipart边界
  fetch('/api/upload-build-file', {
    method: 'POST',
    body: formData
  })
  

• 后端使用支持流式解析的上传中间件（如Node生态的Multer）接收文件，在解析请求体的过程中直接将文件内容流写入服务器本地的临时目录，不要等全量数据加载进内存再处理。
• 待临时文件完全写入磁盘后，拿到该临时文件的绝对路径，直接传入现有fs.createReadStream(临时文件路径)的逻辑即可，原有对接Jenkins的流处理链路不需要做任何修改。

之前使用FileReader传输失败的本质原因：FileReader生成的是内存中的序列化二进制/字符串数据，不属于文件系统可寻址的实体文件，fs模块无法通过路径定位读取这类内存数据。

纯前端实现文件流读取的替代方案 #

存在可完全跳过后端中转的实现路径，具体如下：

• 浏览器原生支持File对象的.stream()方法，可直接从用户选中的文件拿到符合Web Streams API规范的可读流，逐块读取文件内容，不需要将全量文件加载进内存，也不需要在服务器端落盘。
• 拿到文件流后，可通过支持流式传输的fetch接口直接将文件内容发送到Jenkins的构建触发接口，跳过原有Node后端的处理环节。
• 方案注意点：需要确保Jenkins服务开启了前端域名的跨域访问权限；大文件场景下可配合流的背压控制逻辑，降低前端内存占用。

内容的提问来源于stack exchange，提问作者Booster