验证插件是否干扰JavaScript运行时行为，需先禁用所有插件并用VSCode附加调试确认断点正常命中，再按功能分组逐个启用插件，检查控制台是否出现Cannot find module或ERR_REQUIRE_ESM等异常日志，并特别关注ESLint与Prettier在ESM项目中的版本兼容性及paths解析逻辑覆盖问题。

如何验证插件是否干扰 JavaScript 运行时行为

VSCode 插件本身不执行 JS 代码，但可能通过语言服务、格式化器或调试适配器间接影响代码解析、执行或断点命中。关键判断点在于：插件是否修改了 node_modules 中的依赖、是否劫持了 require 或 import 行为、是否在 launch.json 中注入了非预期的 runtimeArgs。

实操建议：

• 禁用所有插件后运行 node --inspect-brk index.js，再用 VSCode 附加调试（type: "pwa-node"），确认断点能正常命中——这是基线
• 逐个启用插件（推荐按功能分组：格式化类、LSP 类、调试类），每次启用后运行相同脚本并检查控制台输出是否多出异常日志（如 Cannot find module 'xxx' 或 ERR_REQUIRE_ESM）
• 特别留意 ESLint 和 Prettier 的版本组合：若项目使用 ESM（"type": "module"），eslint@8.x 需搭配 eslint-config-prettier@9.x，否则 eslint --fix 可能静默失败
• 检查插件是否覆盖了 jsconfig.json 或 tsconfig.json 中的 compilerOptions.paths 解析逻辑——某些路径别名插件会绕过 TypeScript 的模块解析规则

launch.json 中哪些配置最容易引发兼容性问题

launch.json 是 JS 环境兼容性的“高压区”，错误配置常导致 Node.js 进程启动失败、SourceMap 加载失败或调试器挂起。

常见错误现象：

• 断点灰色不可用 → "sourceMaps": true 缺失，或构建产物未生成 .map 文件
• 调试器连接超时 → "port" 被其他进程占用，或 "timeout" 设置过短（默认 10000ms，大型项目建议设为 30000）
• 报错 Cannot find module 'node:fs' → "runtimeVersion" 未指定，VSCode 默认用旧版 Node.js 解析内置模块

实操建议：

• Node.js 版本必须显式声明："runtimeVersion": "20.15.0"（与本地 node -v 一致），避免 VSCode 自动降级
• 若使用 esbuild 或 vite build 输出，确保 "outFiles" 指向正确路径，例如 ["${workspaceFolder}/dist/**/*.js"]
• 禁用 V8 优化可快速定位问题："runtimeArgs": ["--no-opt", "--trace-warnings"]，但仅用于排查，勿长期启用

ESLint/Prettier 冲突时如何隔离测试环境

当 eslint 和 prettier 同时启用且规则冲突，JS 代码可能被反复格式化、保存后报错、或 vscode-eslint 插件直接停止响应。

dmap-jsapi-skill

DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。

下载

使用场景：

• 团队已统一使用 Prettier，但遗留项目仍需 ESLint 检查逻辑错误（如 no-unused-vars）
• CI 流水线要求 ESLint 报错阻断构建，而本地开发希望保存时只格式化不报错

实操建议：

• 在 .eslintrc.js 中明确关闭所有格式化类规则："rules": {"indent": "off", "quotes": "off", "semi": "off"}
• VSCode 设置中禁用 Prettier 对 JS 的接管："prettier.disableLanguages": ["javascript", "typescript"]，仅保留其对 JSON/MD 文件的支持
• 用 eslint --fix 替代 prettier --write 执行格式化，前提是已安装 eslint-config-prettier 并在 extends 中引用
• 测试时临时移除 package.json 中的 prettier 字段，观察 npm run lint 是否仍报格式错误——若仍报，则说明 ESLint 规则未真正禁用

为什么 node_modules/.bin 下的二进制文件会受插件影响

VSCode 插件（尤其是调试类和测试类）常直接调用 node_modules/.bin 中的可执行文件（如 jest、webpack-cli、ts-node）。这些二进制文件本质是 shell 脚本或 JS 入口，其行为高度依赖 process.env 和当前工作目录。

容易踩的坑：

• 插件启动时未正确继承 NODE_OPTIONS（如 --loader ts-node/esm），导致 ts-node 无法加载 ESM 模块
• 某些插件（如 Wallaby.js）会重写 process.argv，导致 jest --runInBand 参数被忽略
• vscode-jest 插件若未配置 jest.path，会 fallback 到全局 jest，而非项目本地 node_modules/.bin/jest

实操建议：

• 在 launch.json 中显式指定 "runtimeExecutable" 和 "runtimeArgs"，避免插件自动探测
• 用 npx jest --version 和 ./node_modules/.bin/jest --version 对比输出，确认两者版本一致
• 检查插件文档是否声明支持特定 CLI 参数；例如 vscode-jest v4+ 要求 Jest 29+，否则 --testPathPattern 会被静默丢弃

实际测试中，最易被忽略的是插件对 process.env.NODE_ENV 的篡改——有些插件会在调试启动前强制设为 "development"，导致生产环境特有的条件分支（如 if (process.env.NODE_ENV === 'production')）永远不执行，却不会报错。