vscode本身不运行parcel，仅提供终端和文件监听能力；parcel必须通过命令行手动执行（如parcel index.html或npx parcel index.html），其热更新依赖自身文件监听机制，与vscode设置无关。
VSCode 本身不运行 Parcel，也不参与打包逻辑；它只提供终端和文件监听能力。Parcel 的实时打包必须由命令行启动，VSCode 只是承载它的外壳。
parcel index.html 命令必须在集成终端中手动执行
Parcel 没有内置 VSCode 插件支持任务自动识别或语法提示，parcel index.html 这条命令不能靠“运行任务”触发，也不能靠插件解析配置后自动拉起服务。
- 打开 VSCode 集成终端（
Ctrl+`），确认当前路径是项目根目录（含index.html和package.json） - 直接输入
parcel index.html并回车——这是唯一可靠启动方式 - 若报
command not found: parcel，说明未全局安装或未用 npx：改用npx parcel index.html - Parcel 启动后会在终端输出本地地址（如
http://localhost:1234），并自动打开浏览器（取决于系统是否允许）
为什么 tasks.json 封装 parcel 命令常常失败
VSCode 的 tasks.json 本质是 shell 命令封装器，但 Parcel 启动后会持续占用进程、接管 stdin/stdout，导致任务卡死或无法正确识别为“完成”状态。
-
"isBackground": true不适用：Parcel 不是标准监听工具（如tsc -w），没有可识别的启动完成信号 -
problemMatcher几乎无效：Parcel 输出非结构化，VSCode 无法提取错误位置到“问题”面板 - 强行封装进 task 容易导致终端假死、热更新失效、端口被占等连锁问题
- 真正需要的是「终端复用」而非「任务封装」：开一个专用终端页签跑
parcel，其他终端干别的事
实时打包依赖文件系统监听，不是 VSCode 功能
Parcel 的「保存即重编译」能力来自它自己调用 chokidar 监听文件变化，与 VSCode 的文件保存事件无关。VSCode 即使关闭、崩溃或禁用所有插件，只要 parcel 进程还在运行，热更新就继续工作。
- 不要试图在
settings.json里配files.autoSave来“配合”Parcel——它不读这个设置 - Windows 用户注意：默认 Windows Defender 实时保护可能干扰 chokidar 监听，表现为修改文件后无反应；可临时将项目目录加入排除列表
- 如果修改 CSS/JS 后页面没更新，先检查浏览器控制台是否有 HMR 错误，再看终端是否打印了
built in XXXms——没打印说明 Parcel 根本没收到变更通知
Parcel 的零配置优势恰恰在于它绕开了构建工具链和编辑器之间的耦合。你不需要让 VSCode “理解” Parcel，只需要让它稳稳地托住那个一直跑着的终端进程。最容易被忽略的一点是：关掉终端等于关掉整个开发服务器，而不是暂停——下次还得重新敲命令。
