Better Comments 默认仅对特定前缀（如TODO、FIXME、!、?、*等）生效，且要求严格匹配大小写、格式及语言支持；// TODO未变色需检查语言ID是否支持、配置项是否拼写正确、主题是否覆盖颜色。
简单来说，Better Comments 并不会自动点亮你所有的注释。它有一套自己的“激活规则”：默认只认准 TODO、FIXME、NOTE、HACK、!、?、* 这类特定关键词。这里有个关键细节：大小写和格式必须严格匹配。你写个小写的 todo，或者中间带空格的 TO DO，插件都会“视而不见”。
为什么 // TODO 没变色？检查这三件事
安装完插件，兴致勃勃地敲下 // TODO:，结果注释还是灰蒙蒙一片——这场景是不是很熟悉？别急着怀疑插件，问题往往出在环境配置上。可以从下面三个方向入手排查：
- 确认语言支持：首先，得看看当前文件的语言类型是否在插件的“服务列表”里。打开命令面板（
Cmd+Shift+P），运行Developer: Inspect Editor Tokens and Scopes，然后留意右上角显示的languageId。如果是ja vascript、python这类主流编程语言，通常没问题；但如果显示的是plaintext或markdown，那默认情况下高亮是不会生效的。 - 核对配置文件：接着，检查一下 VSCode 的
settings.json。有没有不小心删掉或修改了better-comments.tags这个配置项？还有一个常见的拼写错误：把短横线漏掉，写成betterComments.tags，这也会导致配置失效。 - 排除主题干扰：最后，某些第三方或自定义的编辑器主题可能会覆盖插件的颜色设置。如果你怀疑是这个问题，不妨临时切换到 VSCode 自带的
Default Dark+主题试试看，这能快速验证是否存在样式冲突。
自定义 tag 时最容易踩的坑
想给代码审查加个醒目的 // REVIEW 标签，却怎么折腾都不着色？别急，你很可能踩中了下面这几个“雷区”：
- 标签格式必须规范：
tag的值必须全大写、纯字母，不能包含空格、冒号或连字符。举个例子："REVIEW"是对的，但"review"（小写）、"REVIEW:"（带冒号）、"REVIEW-2026"（带连字符）都是无效的。 - 颜色值要写对：颜色必须使用合法的十六进制格式，并且记得带上
#号。写成"#FF8C00"没问题，但"ff8c00"（缺#）或"rgb(255,140,0)"（不支持 rgb 格式）就会导致配置失败。 - 背景色配置要完整：如果你同时配置了
backgroundColor，记得把它设为"transparent"或一个具体的颜色值。如果设置成null或者干脆留空，整个配置项都可能失效。 - 修改后记得刷新：改完
settings.json后，通常不需要重启整个 VSCode，但务必重新打开当前文件，或者执行一次Developer: Reload Window命令，让更改生效。
在 Markdown 或 Shell 文件里启用高亮
默认情况下，Better Comments 的“势力范围”并不包括 markdown 和 shellscript 这类文件。所以，你在 README.md 里写的 ，或者在 .sh 脚本里加的 # FIXME，很可能还是原样，没有颜色。怎么解决？
- 扩展支持语言列表：打开
settings.json，找到或添加better-comments.highlightLanguageIds这个字段，把你需要支持的语言 ID 明确列进去：
"better-comments.highlightLanguageIds": ["ja vascript", "python", "typescript", "markdown", "shellscript"]
- 注意语法差异：这里有个关键点：不同语言的注释语法不同。Markdown 用的是 HTML 注释语法
，而不是编程语言里常见的// TODO；Shell 脚本则使用#号开头，比如# FIXME。 - 按需局部启用：如果只想对特定类型的文件（比如所有
.md文件）开启高亮，可以使用 VSCode 的语言专属设置：
"[markdown]": { "better-comments.enable": true }
禁用干扰项：避免误高亮旧注释或日志
工具用好了是利器，用不好反而添乱。比如，项目里那些遗留的历史调试注释（// DEBUG: xxx），或者字符串里恰好包含了类似注释的文本（console.log("// TODO")），都可能被插件错误地染色，反而降低了代码的可读性。怎么管理这些干扰？
- 排除特定语言：可以利用
better-comments.ignoreLanguageGrammars配置项，将一些高风险或不需要高亮的语言排除在外。例如，禁用对纯文本文件的高亮处理：
"better-comments.ignoreLanguageGrammars": ["plaintext"]
- 理解已知限制：如果你发现字符串字面量里的内容（比如
const s = "// TODO";）也被高亮了，这说明插件有时无法完美区分真正的注释和字符串中的文本。这是当前版本的一个已知限制，最稳妥的办法，就是尽量避免在字符串里写入那些会被误认的“伪注释”前缀。 - 快速开关全局高亮：在进行代码审查，或者需要一份“干净”的视图时，可以临时关闭高亮功能。只需将
better-comments.enable设为false即可，非常方便。
说到底，配置出五彩斑斓的注释并不难，真正的挑战在于让团队形成一致的书写习惯：使用同一套前缀规则、及时清理已经完成的 TODO、避免在字符串中埋下“地雷”。颜色只是一种视觉放大器，它放大的应该是清晰、规范的协作习惯，而不是混乱本身。工具本身并非魔法，善用者方能得其利。
