VSCode原生Markdown预览无需Node.js，因其实现基于内置WebView，支持frontmatter、toc、HTML标签、mermaid及math公式（需启用），响应快且无端口冲突；仅导出PDF、静态站点编译或自定义语法预处理等构建需求才需Node。
VSCode 自带的 Markdown 预览功能不依赖 Node.js，它走的是内置 WebView 渲染路径；如果你试图用 node 运行某个脚本去“启动预览”，那本质上是绕路，还容易因环境不一致导致样式错乱、链接失效或数学公式不渲染。
为什么不需要 Node.js 就能预览 Markdown
VSCode 的 Ctrl+Shift+V（Windows/Linux）或 Cmd+Shift+V（macOS）触发的是编辑器原生预览，解析和渲染全在客户端完成，不启动任何 Node 进程。它支持：frontmatter、toc、基础 HTML 标签、mermaid（需启用）、math（需开启 markdown.math.enabled）等特性。
常见误解是：看到某些插件（如 Markdown Preview Enhanced）用了 Node 启服务，就以为“预览必须 Node”。其实那是为扩展能力（比如导出 PDF、实时监听文件变化并刷新浏览器），不是预览本身必需。
- 原生预览响应快、无端口冲突、不依赖全局
node或npm版本 - 若你已安装 Node，但 VSCode 仍提示“无法预览”，大概率是文件关联或扩展干扰问题，不是 Node 缺失
-
Markdown Preview Enhanced等插件若配置了liveServer模式，会起http://localhost:xxxx，此时才真正用到 Node —— 但它不是必须项
当真需要 Node 支持时：什么场景下必须上 Node
只有以下明确需求才值得引入 Node 依赖：
- 导出为 PDF 且要求页眉页脚、目录层级、LaTeX 数学公式完整渲染（
markdown-pdf插件底层调phantomjs或puppeteer） - 将
.md实时编译为静态站点（如配合marked+chokidar写简易 watch 脚本） - 自定义渲染逻辑，比如把
%%include ./xxx.md%%这类语法做预处理（需写node脚本 +fs.readFileSync）
这类操作本质是构建流程，不是“预览”。别为了看个实时 HTML 就跑一个 node server.js——延迟高、端口占着、关不干净。
排查预览异常：先关插件，再查设置
如果按快捷键没反应，或预览区空白/样式丢失，优先检查这些：
- 确认当前文件后缀是
.md，且右下角语言模式显示为Markdown（点一下可切换） - 禁用所有 Markdown 相关插件（尤其是
Markdown All in One和Preview Enhanced），重启 VSCode 后再试原生预览 - 检查设置里是否误关了：
markdown.preview.doubleClickToSwitchToEditor不影响显示，但markdown.preview.enabled必须为true - 若用工作区设置，确认
.vscode/settings.json没有覆盖掉全局的markdown.preview相关项 - 某些企业版 VSCode 或 Remote-SSH 环境下，WebView 可能被策略禁用，此时连原生预览都不可用，和 Node 完全无关
想用 Node 做轻量服务？最小可行命令就一行
真要起个本地服务看效果（比如测试导出前的 HTML 输出），不必装框架。确保项目根目录有 package.json 后，执行：
npm install -g http-server
然后在 Markdown 所在目录运行：
http-server -c-1 -o -s
这会起一个静态服务，自动打开浏览器，但注意：
-
-c-1禁用缓存，避免改完 Markdown 刷新看不到更新 -
-o自动打开浏览器，-s启用 CORS（方便后续加 JS 交互） - 它不会解析
frontmatter、不支持$$...$$数学块——这只是个文件服务器，不是 Markdown 渲染器 - 若需渲染，得自己加
marked+express写路由，复杂度陡增，远不如用原生预览
真正卡住的往往不是技术选型，而是没分清“编辑时即时反馈”和“构建后交付产物”这两件事的边界。原生预览够用就别动 Node；要用 Node，就明确它解决的是哪一环，而不是把它当成万能胶水。
