Chrome调试白屏主因是端口冲突或file://协议限制，应关闭已有Chrome、指定独立调试端口（如9223）、改用http-server启动本地服务并配置"url"而非"file"，确保js可执行且无跨域错误。
Chrome 调试器没连上 DevTools，页面白屏
VS Code 启动 Chrome 后页面空白，大概率是 launch.json 里没配对调试协议或端口冲突。VS Code 的 Debugger for Chrome（或新版 ms-vscode.js-debug）需要主动连接 Chrome 实例的 DevTools 协议端口，默认是 9222，但如果你本地已有 Chrome 在运行（比如平时用的浏览器），它会抢走这个端口，新启动的调试实例就连不上 —— 连不上，VS Code 就不注入脚本、不触发断点、页面自然空着。
- 检查是否已存在 Chrome 进程：
ps aux | grep chrome（macOS/Linux）或任务管理器（Windows），关掉所有非调试用的 Chrome - 在
launch.json中显式指定调试端口，避开冲突："port": 9223 - 加上
"runtimeExecutable": "code-insiders"或完整路径（如/Applications/Google Chrome.app/Contents/MacOS/Google Chrome）确保 VS Code 启动的是干净的新实例，而不是复用已有进程 - 确认
"url"或"file"路径正确，且 HTML 文件里有可执行的 JS（否则即使连上了也啥都不显示）
HTML 文件没加载 JS，或者 JS 报错中断执行
白屏不等于没连上，也可能是 JS 加载失败或语法错误导致渲染逻辑根本没跑。VS Code 调试器只管“连”，不管“代码有没有问题”。尤其当你用 file:// 协议打开本地 HTML（"file": "./index.html"），Chrome 默认禁用 fetch、import、localStorage 等 API，JS 一报错就静默终止，控制台可能还没来得及输出错误。
- 优先改用
"url": "http://localhost:8080/index.html"，配合live-server或http-server启动本地服务 - 在
launch.json中加"webRoot": "${workspaceFolder}"，避免断点打不中源码 - 打开 Chrome 自带的 DevTools（F12），切到 Console 标签页，看是否有
Uncaught SyntaxError或Failed to load module类错误 - 如果用了 ES modules，确保
<script type="module">和文件后缀、MIME 类型匹配，file://下模块加载基本不可靠
vscode-js-debug 自动启用后行为变化
新版 VS Code（1.8+）默认启用内置的 js-debug，不再依赖旧版 Debugger for Chrome 扩展。但它对启动参数更敏感，尤其 "runtimeArgs" 写法稍有偏差就会静默失败 —— 比如你照着老教程写 --remote-debugging-port=9222，新调试器其实期望的是 "port" 字段，而非靠 runtimeArgs 传参。
- 删掉
"runtimeArgs"里关于调试端口的配置，改用顶层"port"字段 - 确保
"type": "pwa-chrome"（不是"chrome"），这是内置调试器识别的类型 - 如果项目含 TypeScript 或构建步骤，确认
sourceMapPathOverrides配置正确，否则断点能打但不命中，容易误判为“没运行” - 在 VS Code 的“运行和调试”面板顶部，点击齿轮图标生成
launch.json，选Chrome（不是Node.js），比手写更稳妥
跨域请求被拦截，页面卡在初始化
本地开发时直接双击 HTML 或用 file:// 打开，任何 fetch('/api/data') 或 XMLHttpRequest 都会触发跨域限制（因为 origin 是 null），Chrome 直接拒绝请求，JS 停在 await fetch(...) 不往下走，DOM 渲染卡住，看起来就是白屏。
- 这不是 VS Code 的问题，是浏览器安全策略 —— 别试图用
--disable-web-security启动 Chrome（危险且新版已不支持） - 必须走 HTTP 服务：用
npx http-server -c-1（禁用缓存）或npm run dev启动项目自带的开发服务器 - 如果后端 API 在另一个端口（如
http://localhost:3000），前端需配代理（如 Vite 的server.proxy）或后端加 CORS 头，否则 fetch 仍失败 - 检查 Network 面板里请求状态：如果是
blocked: cors，说明问题不在 VS Code，而在运行环境
真正卡住人的地方，往往不是配置写错了，而是 Chrome 实例被复用、端口被占、或者你以为在跑 HTTP 实际还在 file:// 下硬扛 —— 这些状态 VS Code 不会明确告诉你，它只安静地白着。
