vscode 配 gatsby 需手动配置 launch.json 指向 node_modules/gatsby/dist/bin/gatsby、启用 sourcemaps、确保 gatsby-node.js 用 module.exports；prettier 与 eslint 要通过 eslint-config-prettier 协调规则；windows 用户须将项目置于 wsl 原生路径避免性能问题。
VSCode 本身不内置 Gatsby 支持，但通过合理配置扩展、调试文件和格式化工具，能获得接近 IDE 级别的开发体验。关键不是“装一堆插件”，而是让 gatsby develop 可断点、gatsby build 可追踪、代码风格不打架。
怎么配 launch.json 让 gatsby develop 可调试
VSCode 默认不识别 Gatsby CLI 的 Node.js 进程入口，必须手动指向其内部二进制路径。直接运行 gatsby develop 会跳过源码映射，断点无效。
- 确保项目已安装
gatsby（即node_modules/gatsby存在），不要只靠全局 CLI -
launch.json中的program必须写成"${workspaceRoot}/node_modules/gatsby/dist/bin/gatsby"，不能用npm run develop或gatsby命令名 -
sourceMaps设为true（不是false），否则断点打在转译后代码上，无法回溯到gatsby-node.js或gatsby-config.js - 若断点仍不生效，检查
gatsby-node.js是否用了export default语法——Gatsby v5+ 要求该文件是 CommonJS 模块，应写module.exports = {...}
为什么 Prettier 和 ESLint 一起用总报冲突
两者默认规则重叠（比如单引号、分号、箭头函数括号），不协调会导致保存时反复格式化、编辑器右下角弹警告，甚至自动删掉你刚写的 __typename 字段。
- 必须安装
eslint-config-prettier并在.eslintrc.js的extends数组末尾加入'prettier' -
.prettierrc.js中避免设置semi: true，因为 Gatsby 官方推荐和多数插件源码用无分号风格；若强行开启，ESLint 的semi规则会持续报错 - 禁用 ESLint 的
quotes规则，改由 Prettier 统一控制；否则singleQuote: true和quotes: ['error', 'backtick']直接打架 - VSCode 设置里关掉
editor.formatOnSave，改用editor.codeActionsOnSave+source.fixAll.eslint，这样只执行 ESLint 修复，不触发 Prettier 多余重排
Windows 用户必须避开的 WSL 文件路径坑
在 Windows 上用 WSL 开发 Gatsby，如果把项目放在 /mnt/c/... 下，gatsby develop 启动极慢，热重载延迟超 10 秒，甚至构建失败报 ENOSPC（实际不是磁盘满，是 WSL 对 Windows 文件系统监控失效）。
- 项目必须建在 WSL 原生路径下，例如
~/projects/my-gatsby-site，而不是/mnt/c/Users/xxx/projects/... - VSCode 打开项目时，确认左下角显示的是
WSL: Ubuntu（或你装的发行版），不是Local - 不要在 VSCode 里用
code .打开挂载路径下的文件夹；正确做法是：先在 WSL 终端进入项目目录，再执行code . -
gatsby build生成的public目录若需被 Windows 浏览器访问，用explorer.exe .在 WSL 内打开当前目录，它会自动映射到\wsl$Ubuntuhomexxx...，而非硬拷贝到 C 盘
真正卡住人的从来不是“没配好”，而是调试时断点不命中、保存后代码乱跳、或者 Windows 下热重载像在等泡面——这些都源于路径、模块系统、格式化链路三个环节中某个细节没对齐。配完别急着写页面，先在 gatsby-node.js 里加个 console.log，跑一次 gatsby develop，看它是否真从你改的那行输出。这比任何文档都管用。
