VSCode本身不支持断点续传，因标准node启动无状态保持能力；需用nodemon+attach模式实现热调试，并配sourceMaps、移除skipFiles限制及确保服务端幂等性与持久化。
VSCode 本身不提供“断点续传”功能，它只是调试器前端；真正的断点续传能力取决于 Node.js 运行时是否支持热重载、进程保持和状态恢复——而标准 node 启动方式（node index.js）不具备这些能力。你真正需要的，是「在调试过程中修改代码后不中断服务、自动重启并复用已有连接状态」，这本质上属于开发体验优化，不是调试器原生特性。
为什么直接用 launch.json 无法实现“断点续传”
VSCode 的 launch.json 配置中 "request": "launch" 模式每次触发 F5 都会杀死旧进程、启动新实例，所有内存状态（如已建立的 TCP 连接、临时缓存、上传中的分片上下文）全部丢失。所谓“续传”，必须依赖外部工具维持进程生命周期。
-
nodemon只负责文件变更后重启，但重启即清空状态，不等于续传 -
ts-node-dev或node-dev同理，它们不保存运行时上下文 - Node.js 官方没有内置“暂停执行 + 热替换 + 恢复执行”的调试语义，
debugger语句或断点仅用于单次暂停观察
可行方案：用 nodemon + --inspect 搭建可热调试的上传测试环境
如果你的目标是测试大文件分片上传、断网重连、服务端分片合并逻辑，推荐用以下组合替代纯 launch.json：
- 启动命令改用：
nodemon --inspect=9229 --watch src/ --exec node src/upload-server.js - VSCode 中配置一个
attach型调试配置，而非launch -
launch.json关键字段如下：{ "type": "node", "request": "attach", "name": "Attach to nodemon", "port": 9229, "address": "localhost", "restart": true, "sourceMaps": true, "outFiles": ["${workspaceFolder}/dist/**/*.js"] } - 这样 VSCode 不控制进程启停，只监听调试协议端口；
nodemon负责检测变更、重启，并始终绑定同一调试端口
给 node_modules 里的上传库（如 busboy、formidable）加断点要注意什么
想在第三方解析库内部打断点排查分片接收异常？默认情况下 VSCode 会跳过 node_modules 中的 JS 文件（因 "skipFiles" 包含 "${workspaceFolder}/node_modules/**/*.js"）。必须手动移除或细化过滤：
- 删掉
launch.json中"skipFiles"里对node_modules的通配规则 - 或者改成更精确的排除：
"skipFiles": ["<node_internals>/**", "${workspaceFolder}/node_modules/@types/**"]</node_internals> - 确保该模块未被 webpack / esbuild 打包混淆，否则断点位置会错位
- 如果模块是 ESM 格式且你用的是 CommonJS 入口，可能需额外配
"resolveSourceMapLocations"
真正影响“续传逻辑验证”的三个隐藏细节
很多团队卡在“断点能打、服务能跑，但上传一断就失败”，问题往往不在调试配置，而在底层设计假设：
- HTTP 服务器（如 Express）默认不启用
keepAlive，长连接在断点暂停期间超时关闭 → 需显式设置server.keepAliveTimeout = 60_000 - 上传中间件（如
multer）把分片暂存到内存或临时目录，重启后路径丢失 → 必须将分片写入持久化存储（如tmp目录 + 唯一 uploadId 命名） - 客户端未实现分片校验与幂等提交，导致重试时重复写入 → 服务端需基于
uploadId + chunkIndex做去重判断，不能只靠断点观察单次请求
调试只是照镜子，镜子里看到的是代码行为；而“续传”是否可靠，取决于你有没有在代码里真正落地幂等性、状态持久化和连接保活这三个支点。
