VSCode本身不处理文件上传，而是通过配置launch.json调试Express+multer后端服务，配合前端HTML/JS实现分片上传；关键在于断点调试上传逻辑、校验分片参数一致性、严格保证合并顺序与完整性。
VSCode 本身不直接处理文件上传，它只是编辑和调试环境；真正实现大文件分片上传的是你写的 Node.js 后端 + 前端页面（哪怕只是本地 HTML + JS）。VSCode 的作用是帮你写、运行、调试这套代码。关键不是“在 VSCode 里上传”，而是“用 VSCode 开发并本地验证分片上传逻辑”。
怎么在 VSCode 里启动一个可调试的分片上传服务
你需要一个最小可运行的 Express + multer 服务，并能被 VSCode 的 debugger 附加。重点不是装插件，而是配置 launch.json 让 Node 进程支持断点调试。
- 确保项目根目录有
package.json，已安装express、multer、cors - 创建
server.js，暴露/upload-chunk和/merge两个接口，接收chunk、chunkIndex、totalChunks、fileHash等字段 - 在项目根目录新建
.vscode/launch.json，内容为：
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Launch server",
"program": "${workspaceFolder}/server.js",
"console": "integratedTerminal",
"env": { "NODE_ENV": "development" }
}
]
}按 F5 启动后，VSCode 会运行 Node 并监听 3000 端口（或你在 server.js 里指定的端口），你就可以在 server.js 的 req.file 处下断点，观察每个分片是否真实写入临时目录。
前端 HTML + JS 要怎么写才能在 VSCode 里直接测试
别依赖构建工具——直接建一个 index.html 放在项目根目录，用原生 fetch 或 axios 发请求。VSCode 自带 Live Server 插件（推荐安装）可一键起本地 HTTP 服务，解决跨域问题（否则浏览器会因同源策略拒绝发送 FormData）。
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
-
index.html中用<input type="file">获取File对象 - 调用
file.slice(start, end)切片，注意参数单位是字节，不是 MB —— 写成5 * 1024 * 1024，别写5MB或字符串 - 每个分片构造
FormData时，必须包含：chunk（Blob）、chunkIndex（数字）、totalChunks（数字）、fileHash（建议用crypto-js前端算 MD5，避免后端重复校验） - 并发控制别写死
Promise.all—— 大文件可能生成上百个分片，全量并发会触发浏览器连接数限制（通常 6~10 个），改用队列控制，例如每次最多发 4 个
为什么本地测试时总卡在 “No chunk received” 错误
这是 multer 没收到 chunk 字段最常见的报错，根本原因几乎全是前端传参或后端配置不匹配，不是代码逻辑问题。
- 前端
FormData.append('chunk', blob)的键名，必须和后端multer().single('chunk')的参数完全一致（区分大小写） - 后端
multer.diskStorage的filename回调里，不能直接返回req.file.originalname—— 所有分片会覆盖同名文件。应拼上chunkIndex，例如return `${req.body.fileHash}-${req.body.chunkIndex}.part` - 如果用了
express.json()或express.urlencoded()中间件，它们会干扰multipart/form-data解析，必须放在multer之后，或干脆删掉（分片上传不需要它们） - 检查浏览器开发者工具 Network 标签页：点击某个
/upload-chunk请求 → Headers → 看Content-Type是否含boundary=；Preview 里能否展开看到chunk字段 —— 如果看不到，说明前端没 append 成功
合并分片时文件损坏或顺序错乱怎么办
分片合并不是简单把所有 .part 文件 cat 一起，顺序和完整性必须由服务端严格保证。
- 不要依赖文件系统目录遍历顺序（
fs.readdirSync返回顺序不保证数字排序），必须从数据库或内存中读取已上传的chunkIndex列表，并.sort((a, b) => a - b) - 合并前校验每个分片大小：最后一个分片可能小于设定值（如文件总长 10.3MB，分片 2MB，则第 6 片只有 0.3MB），但其他分片必须严格等于
chunkSize - 合并后建议计算最终文件的 MD5，与前端传来的
fileHash比对 —— 不一致就删掉整个文件夹，返回 500 错误，避免静默损坏 - 注意
fs.createWriteStream的flags: 'a'（追加）模式，别用'w'（覆盖），否则前面的分片会被清空
真正的难点不在切片或上传，而在状态一致性：前端 localStorage 记的进度、后端数据库存的已收分片、磁盘上实际存在的文件，三者必须随时对齐。任何一环脱节，断点续传就失效。别跳过状态校验步骤，哪怕本地测试也得模拟中断再续传一次。
