live server比手动刷新更可靠，因其启动真实http服务（非file://协议），规避跨域、cors及模块加载限制，解决import、fetch、service worker等场景的mime类型错误等问题。
Live Server 为什么比手动刷新更可靠
手动刷新页面容易漏掉未保存的修改，或因缓存导致样式/脚本未生效。Live Server 插件启动的是真实 HTTP 服务（不是 file:// 协议），规避了跨域、CORS 和模块加载限制，尤其对 import 语句、fetch 请求、Service Worker 等场景必不可少。
常见错误现象：打开 HTML 文件双击运行，控制台报错 Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/plain". —— 这就是 file:// 协议导致的，Live Server 能直接解决。
- 安装后右键 HTML 文件选择
Open with Live Server，自动在http://127.0.0.1:5500/xxx.html打开 - 默认端口 5500 可在设置中修改：
liveServer.settings.port - 不支持 HTTPS，开发环境需关闭
debug.chrome.ignoreHttpsErrors配合调试
Debugger for Chrome 怎么让断点真正命中源码
断点打在 JS 文件里却跳转到 bundle.js 或空白行？根本原因是没正确配置 source map 映射。VSCode 不会自动猜路径，必须显式告诉它“压缩文件里的第 123 行，对应我写的 src/index.ts 第 45 行”。
关键参数是 sourceMapPathOverrides，尤其在使用 Webpack/Vite 构建时：
- 若构建产物在
dist/，源码在src/，则"webpack:///src/*": "${webRoot}/src/*" - Vue 项目常见问题：
.vue单文件组件中的<script></script>块需确保devtool: 'source-map'开启 - 检查浏览器开发者工具的
Sources面板里是否能看到原始.ts或.jsx文件 —— 看不到就说明映射失败
ESLint + Prettier 组合为什么总提示格式冲突
两者规则重叠（比如分号、引号、空行），不协调就会出现“保存后 ESLint 报错，再格式化又触发 ESLint 报错”的死循环。核心矛盾在于谁该负责“风格”、谁该负责“质量”。
正确分工：
-
ESLint只管逻辑错误和潜在 bug（no-unused-vars、react-hooks/exhaustive-deps） -
Prettier全权接管所有格式细节（缩进、换行、括号位置） - 必须安装
eslint-config-prettier并在.eslintrc.js的extends中靠后写，覆盖 ESLint 自带的格式规则
典型错误配置：extends: ['prettier', 'eslint:recommended'] —— prettier 写太前，被后面规则覆盖。
审查元素时如何一键跳回 VSCode 对应代码行
这个功能依赖两个条件同时满足：浏览器 DevTools 的 “Enable CSS source maps” 和 VSCode 的调试会话已启动。不是装了插件就自动生效。
必须操作步骤：
- 确保
launch.json中webRoot指向项目根目录（不是dist或public） - 在 Chrome DevTools 的
Settings > Preferences > Sources中勾选Auto-reload generated CSS和Enable CSS source maps - 在 Elements 面板右键元素 →
Reveal in Editor，VSCode 才会精准跳转到 SCSS/JSX 文件的对应行
容易被忽略的是：如果用的是 Vite 或 Snowpack，默认开启 source map，但若在 vite.config.ts 里写了 build.sourcemap = false，这个跳转就彻底失效。
