Code Spell Checker 默认不检查变量名拼写，仅校验注释、字符串、Markdown等自然语言内容；因变量名属代码语义层，强行检查会导致useState、idx等误报，故通过cSpell.wordsOnlyCheckInCommentsAndStrings严格限定作用域。
Code Spell Checker 本身不会检查变量名拼写，这是它默认且刻意的设计——它只校验自然语言内容（注释、字符串、Markdown），而跳过 const、function、class 等上下文中的标识符。想靠它拦截 recieveData 这类变量名错误，会直接失效。
为什么 Code Spell Checker 默认不检查变量名
拼写检查器依赖词典和上下文识别，而变量名是代码逻辑的一部分，不是自然语言。强行检查会导致大量误报：比如 useState、useEffect、jsx、tsx 都可能被标红；缩写如 idx、el、btn 也会频繁触发警告，干扰开发节奏。
插件通过 cSpell.wordsOnlyCheckInCommentsAndStrings（默认 true）明确限定作用域，这是合理取舍，不是功能缺失。
真要检查变量名拼写，得换工具链
变量名属于代码语义层，必须由静态分析工具介入：
-
eslint-plugin-spellcheck是目前最直接的方案，需配合 ESLint 使用。它能扫描Identifier节点，对变量、函数、属性名做拼写校验 - 配置时注意：它默认不启用，需在
.eslintrc.js中显式添加规则"spellcheck/spell-checker": "error" - 必须搭配自定义词典（
customWordListPath）或启用en_US+en_AU等多词典，否则像color/colour这类变体会报错 - 性能有代价：大型项目开启后，ESLint 检查耗时明显增加，建议仅在保存时运行（
eslint.run: onType不推荐）
Code Spell Checker 的正确用法边界
它真正起效的地方，恰恰是容易被忽略但影响协作质量的“软文本”：
- 注释里的英文说明：
// handels the user input→handels会被标红（应为handles） - 字符串文案：
throw new Error("Unexpcted response")→Unexpcted实时提示 - Markdown 文档：
## Intallation guide→Intallation下划线提醒 - JSON 文件中非 key 的值字段（如
{"title": "Recieve confirmation"}）也可覆盖，只要在cSpell.enabledLanguageIds中加入json
配置关键项：cSpell.language 必须设为 ["en", "zh"] 才能同时覆盖中英文注释；中文支持靠拼音模糊匹配，不是 OCR 识别，所以 “接收” 写成 “接受” 不会报警——它不解决语义歧义，只管字面拼写。
常见误配导致插件“失灵”的三个坑
很多人装完没反应，问题往往出在配置细节：
- 没改
cSpell.enabledLanguageIds：默认只开plaintext和markdown，.js、.ts文件需要手动加"javascript"、"typescript" -
cSpell.ignoreRegExpList写错格式：正则必须是字符串数组，例如["\b[A-Z]{3,}\b"]，漏掉转义或引号会导致整个配置加载失败 - 项目级
.cspell.json和用户级settings.json冲突：优先级是“工作区 > 项目 > 用户”，若项目里写了"enabled": false，插件就彻底静音
最稳妥的验证方式：新建一个 test.md，输入 definately，看是否立刻波浪线——能则说明插件活，不能则先查 enabledLanguageIds 和启用状态。
