断点未命中或行列号错位，本质是源码与实际运行代码不一致，需确认 source map 正确生成加载、浏览器启用且未缓存、调试器显示的是映射后源码而非编译后文件，并检查构建插件干扰及编辑器配置同步。

断点未命中或代码行列号错位，通常不是浏览器或调试器“坏了”，而是源码映射（source map）、构建产物、缓存或编辑器显示与实际执行代码不一致导致的。核心要搞清：你看到的代码 ≠ 浏览器实际运行的代码。

检查 source map 是否正确生成并加载

现代前端项目（Vue/React/Vite/Webpack）默认生成 .map 文件，但容易出问题：

• 构建时未开启 source map（如 Webpack 的 devtool: 'source-map' 或 Vite 的 build.sourcemap: true）
• 打包后 .map 文件未随 JS 一起部署（Nginx 未配置 .map 后缀 MIME 类型或路径 404）
• 浏览器开发者工具里禁用了 source map：F12 → ⚙️ Settings → Preferences → Sources → ✅ Enable JavaScript source maps
• Chrome 有时会缓存旧的 source map，可尝试 Ctrl+Shift+R（硬重载）+ 清空缓存（勾选 “Disable cache”）

确认调试的是“源码”还是“编译后代码”

在 Sources 面板中看左侧文件树：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 如果看到的是 webpack://、vue://、src/App.vue 这类路径 → 是 source map 映射后的源码，断点应打在这里
• 如果只看到 localhost:3000/assets/index.abc123.js 这类压缩/打包后的文件 → 断点打在它上面，行号必然错位（因为 Babel、TS 编译、Uglify 等已重写代码）
• 右键该 JS 文件 → “Map to file system resource…” 可手动关联本地源码目录（适合本地开发联调）

留意构建工具的 transform 干预行为

某些插件会在编译阶段插入/删除代码，导致行号偏移：

• Vite 的 define 或 alias 替换可能引发逻辑跳转异常
• Babel 插件（如 @babel/plugin-transform-runtime）会注入辅助函数，推高后续代码行号
• TypeScript 的 import type 或 declare 在编译后被完全移除，也会造成断点下移
• 可在打包后打开 dist 中的 .js 和 .map 文件，用在线工具（如 source-map-visualization）验证映射准确性

编辑器与浏览器显示不一致？试试“重新加载调试器”

VS Code + Debugger for Chrome / Edge 插件常见问题：

• 修改了代码但没重启 dev server，编辑器显示新代码，浏览器仍跑旧 bundle
• VS Code 的 launch.json 中 sourceMaps: true 和 outFiles 路径没配对（尤其多入口或库模式）
• 点击 VS Code 调试侧边栏的 ↻（Restart Session） 或直接关闭再打开 DevTools，强制刷新映射关系
• 临时在代码里加 debugger;，看是否触发 —— 若触发但断点不红，基本是映射失效

不复杂但容易忽略，关键是让“你写的”、“构建出的”、“浏览器加载的”、“调试器显示的”四者对齐。每次怀疑断点失效，先打开 Network 面板过滤 .map 文件，确认状态码是 200 再往下查。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南