刚接触 VSCode 里 TODO 注释的整理时我一度觉得这不就是个高亮插件吗能折腾出什么花来。直到在一个快两年的老项目里我看着密密麻麻散落在几十个文件中的TODO、FIXME、XXX整个人都麻了——这些到底哪些是急着要修的哪些是陈年旧账哪些是临时过渡方案没人说得清因为连注释的发起人自己都忘了。就是从那个时候开始我认真研究起了 Todo Tree 这个插件也把 TODO 类注释的规范、写法和自定义玩法彻底理了一遍。这篇内容适合所有用 VSCode 写代码的人不管你是刚入职的新人还是要带团队的组长搞懂这套注释管理方案你的代码可维护性能往上拉一大截。1. 为什么要用 Todo Tree注释管理的核心需求拆解先说一个很反直觉的事实大部分人的代码注释习惯是把 TODO 当成待办事项在写但实际上 TODO 注释的作用压根不是记事而是标记。标记什么呢标记代码里那些已知但不紧急的问题、暂时妥协的方案、需要在某个时间点回头处理的逻辑。如果不能把这些标记从代码里捞出来聚合成一张清单那它们跟空气没什么区别。1.1 没有管理工具时的痛点清单想象一下没有 Todo Tree 的日子。你想找项目里所有的 FIXME 注释要么靠编辑器全局搜索搜完之后逐个文件跳转再靠人脑记住每个注释的上下文要么用官方自带的问题面板但那个面板对自定义标记的支持很弱基本只能看语法错误和 lint 报错再要么就是靠团队约定大家在群里互相喊话那个谁你留的 TODO 搞一下。这三种方式我都经历过分别对应三个问题第一高亮缺失。默认 VSCode 对TODO这类注释是没有特殊高亮的它在代码里就是一个普通绿色注释跟其他注释混在一起扫一眼根本找不到。第二无法聚合。全局搜索只能给你一个平面结果列表没有分组、没有排序、没有过滤在多文件多标签的情况下你要手动分辨每个条目属于哪块功能。第三上下文断裂。找到注释之后你得再去看它附近的代码才能想起来当时为什么写这个有时候注释离真正的问题代码隔了好几行这个为什么就彻底丢了。1.2 Todo Tree 解决了什么核心问题Todo Tree 做的事情其实很简单就是把所有约定好的标记注释从源码中抽出来在侧边栏生成一棵树按文件路径归类点击即可跳转。听起来好像没什么但实际用下来你会发现它解决了三个层次的问题可视化层次未完成的 TODO 以特殊颜色高亮显示一眼看清哪些代码还在半成品状态。组织层次侧边栏的树状结构天然地反映了项目的功能模块哪个文件欠的债多哪个模块的 FIXME 扎堆一眼分明。流转层次写完注释等于加入清单解决完注释等于自动消失整个过程不需要任何额外操作这是它最打动我的地方——注释即任务清理即完成。第三个层次是很多人忽略的价值。任务管理工具比如各类项目管理软件里的待办和代码里的 TODO 本质上应该是联动的但大多数人的工作流是两套系统互相脱节。Todo Tree 至少让你在代码这个层面形成闭环你不需要在写完一个TODO: 这里需要补充错误处理之后再去另一个软件里记一条别忘了补错误处理。代码本身就是待办清单这个理念很朴素但真的好用。1.3 适合什么场景、什么人群从人群讲我最推荐这几类人优先用起来第一类是维护老项目的人老项目里遗留注释多靠 Todo Tree 像扫雷一样把历史遗留问题清点出来边清点边制定清理计划这是对存量债务的管理第二类是带团队的人你可以在 code review 的时候明确要求新的临时方案必须留 TODO 注释 责任人标识然后在开发周期末尾用 Todo Tree 把欠账拉出来谁的东西谁认领第三类是个人项目爱好者自己写小项目的时候经常写到一半觉得回头再改回头就是一万年Todo Tree 至少能提醒你这里确实没改完。如果你是刚入行的开发者我反而建议你先从规范写注释开始因为工具再好用注释本身一团糟也白搭。看完后面的规范部分再配合插件实践会顺很多。2. 基础配置与核心特性让 Todo Tree 真正听话装插件本身没什么好说的市场里搜 Todo Tree 直接装就行。真正需要花心思的是理解它的配置体系和默认行为背后的意图这样你才不会在遇到为什么这个标签不显示的时候一头雾水。2.1 配置文件里的关键字段解析Todo Tree 的配置项都集中在settings.json里以todo-tree前缀开头。我最先建议你动的是todo-tree.general.tags这个字段定义了插件要识别哪些标记以及每个标记的展示行为。默认配置是长这样的todo-tree.general.tags: { TODO: { icon: check-circle, iconColor: #0a8f3c }, FIXME: { icon: tools, iconColor: #c74e00 }, XXX: { icon: warning, iconColor: #d91e1e } }这里每个标签都配了 icon图标名称和 iconColor图标颜色这个设计特别聪明——它把标记的语义化从文字层面延伸到了视觉层面。TODO 是绿色圆形对勾提示有未完成事项FIXME 是橘色扳手强调需要修理XXX 是红色警告意思是这里特别需要注意再不改要出问题。视觉识别效率比纯文字高得多这是插件做得很细致的一点。2.2 全局开关与正则匹配逻辑还有一个重点字段是todo-tree.filtering.excludeGlobs和todo-tree.general.rootFolder不过我更想提醒你注意todo-tree.regex.regex这个字段。它决定了哪些注释会被匹配到默认长这样todo-tree.regex.regex: (//|#|!--|;|/\\*|\\*)\\s*($TAGS)这个正则其实很好理解前面的(//|#|!--|;|/\\*|\\*)是各种语言里的注释符号后面的($TAGS)会替换成你在tags里定义的所有标签。也就是说Todo Tree 默认只认以注释起始符号开头 空格 标签这种格式的注释。我特意说明这一点是因为很多人踩过一个坑写了//TODO: something没有空格就不被识别或者写/* TODO */里面带了星号前缀匹配起来也有点别扭。解决办法也很简单把正则改成(//|#|!--|;|/\\*|\\*|\\*)\\s*($TAGS)就能多兼容一种星号开头的场景。2.3 侧边栏视图的展示模式与交互技巧装好插件后侧边栏会出现一个 TODO 树最开始你可能觉得这不就是个文件列表吗但这里有几个交互细节值得说点击任意条目会直接跳转到注释所在行光标定位到注释行的开头。条目右侧的数字表示该文件或目录下有多少个匹配标签这个数字会在你解决注释之后实时减少很有成就感。顶部的搜索框是很多人忽略的神器。它支持按标签、按文件路径进行过滤。比如你输入!FIXME就能过滤掉所有 FIXME 条目只看剩下的输入某个文件名关键词就能只看这个文件下的所有条目。右键菜单里可以切换文件对其的包含/排除隐藏当前标签类型这在你有一个目录全是第三方代码不想被扫进来的时候特别有用。还有一个容易被忽略但实际很高效的用法把 Todo Tree 从侧边栏拖到辅助侧边栏Secondary Side Bar。主侧边栏留给资源管理器辅助侧边栏放 TODO 清单这样你可以一边看文件树一边看待办清单互不遮挡效率翻倍。这个小细节我是在一次调窗口布局的时候偶然发现的后来就成了固定习惯。2.4 关于扫描范围与控制范围的进阶配置默认情况下Todo Tree 会扫描整个工作区所有文件。大项目里这就会产生问题扫描慢、结果杂、还有一堆压根不需要管的三方依赖里的注释。所以我一般会配合两个配置用todo-tree.filtering.excludeGlobs: [ **/node_modules/**, **/dist/**, **/build/**, **/vendor/**, **/*.min.* ], todo-tree.general.settings: { followSymlinks: false }excludeGlobs就是字面意思排除你不想扫的目录或文件。followSymlinks设为 false 是为了避免符号链接指向的外部目录被重复扫描。这两个配置一设完侧边栏瞬间清爽扫描速度也明显提升。段首的.vscode工作区配置里也可以单独覆盖这些设置所以在团队协作时你可以把 exclusions 写进项目的.vscode/settings.json让所有协作者共享同一套扫描范围。关于扫描速度还有一个小 tip打开一个超大项目时Todo Tree 第一次扫描可能要 2 到 3 秒这只是建立树索引的时间后面文件编辑时它做的是增量更新不会让你感到卡顿。如果你觉得卡八成不是插件的问题而是你有个特别巨大的文件比如几百 M 的日志文件这种文件直接加进 exclude 就完事了。3. TODO 注释的正确打开方式从格式到团队规范插件配置再花哨如果注释本身写得乱七八糟Todo Tree 也只能给你展示一堆乱七八糟的条目。这一章我想认真谈谈注释规范的问题。注释是写给未来的自己和其他开发者看的这句话说了无数遍但真正执行的人不多。3.1 三种核心标签的语义界定先说语义。很多团队对 TODO、FIXME、XXX 的用法是模糊的经常把 FIXME 当成 TODO 用或者把 XXX 当 FIXME 用这会导致后面看清单的时候完全分不清轻重缓急。下面这套区分是我个人比较推荐的也是不少公司内部规范里常见的一种标签含义典型场景优先级TODO待办事项需要后续补充或完善的功能缺错误处理、缺边界条件、后续接入真实接口中FIXME已知问题当前行为有误但尚未修复这里逻辑有 bug 但先绕过、临时 workaround高XXX警告标记代码危险或需要特别警惕这里有性能隐患、这里可能崩溃但测试环境没事最高HACK临时方案写得很丑但能跑借了个 map 在 filter 里做条件分支自己都看不下去高核心原则是TODO 是未来要做FIXME 是现在有问题XXX 是这里很危险。三者的共同点是都不会立刻动手解决区别在于解决时的紧急程度和处理方式。FIXME 一般是要修复现有行为的 bugTODO 是要添加当前缺失的能力XXX 则是提醒别人动这里之前先想清楚别把隐患越捅越大。3.2 结构化注释格式让清单可以追责光有标签还远远不够。我强烈建议在团队里推广结构化注释格式也就是在标签后面补充类型、责任人和时间信息像这样// TODO[error-handling]: 补全接口超时后的重试逻辑 // FIXME[legacy-payment]: 这里的金额单位混用了分和元需要统一 // XXX[performance]: 这个双循环在数据量达到 10w 时耗时超过 2s // TODO[refactor][某开发者]: 等账单模块重构完成后把这段拆出去你可以看到方括号里写了模块或问题类型有时候还带责任人和时间。这样做有什么好处第一Todo Tree 的搜索框可以按方括号里的关键字过滤比如输入performance就能定位所有性能相关的待办第二责任人信息让清单可以追责code review 的时候当场确认归属比在群里人高效得多第三时间信息可以帮你识别陈年债——超过三个月没人动的 TODO基本可以判断优先级没那么高可以先降级。不过我建议时间信息不要写绝对日期写相对行动点更稳妥例如TODO[refactor]: 等下一个 sprint 开始后处理。写绝对日期的坏处是如果某天已经过去留着一行2024-03-05的注释会让人有种这个任务是不是过期忘了的暗示反而产生认知负担。3.3 注释中英文混写的通行准则还有一个实操问题注释到底用中文还是英文我的看法是英文注释在跨团队协作或开源项目里有必要但国内团队内部用中文完全没有问题效率更高。关键是保持一致性。你不要一个文件全中文另一个文件全英文更不要一条注释里中英混杂还没有空格。另外尽量别在注释里写太口语化的词比如弄一下搞搞建议用「处理」「修复」「优化」「重构」「补充」这类动词这样搜索的时候关键词更统一。同一类 TODO 的描述尽量使用统一的句式比如全部用补全修复优化这样 Todo Tree 的清单扫过去非常整齐。3.4 标签之外的隐藏注释类型HACK、BUG、TEMP、OPTIMIZETodo Tree 的 tags 默认只显示那三个标签但实际开发中我们经常还会用到别的标记。这些标记如果你不主动在配置里添加Todo Tree 就不会识别所以很多人根本不知道插件支持自定义标签。其实完全可以加比如todo-tree.general.tags: { TODO: { icon: check-circle, iconColor: #0a8f3c }, FIXME: { icon: tools, iconColor: #c74e00 }, XXX: { icon: warning, iconColor: #d91e1e }, HACK: { icon: bug, iconColor: #a371f7 }, BUG: { icon: bug, iconColor: #d91e1e }, TEMP: { icon: circle-outline, iconColor: #e0a800 }, OPTIMIZE: { icon: zap, iconColor: #2d7ff9 } }加完后Todo Tree 会把这几个新标签也显示在侧边栏并且自动高亮。我实际项目里加得最多的是HACK和TEMP因为这两类注释出现的频率非常高。HACK代表我知道这写得很丑陋但我现在没时间优化它的价值在于给后续接手的开发者一个心理预期别对着烂代码骂娘。TEMP则代表这只是临时方案正式方案上线后必须换掉这种标签非常适合在对接第三方服务、写 mock 数据、走通主流程还没做边界处理的时候用。4. 自制自定义图标从改颜色到换图标的完整玩法说完了常规配置终于到了标题里那个最有意思的部分——自制 TODO 图标样式。很多教程到改个颜色就停了但 Todo Tree 这套图标的可定制性远比大部分人以为的要深。我分三档玩法讲你可以根据自己的实际需求选一档。4.1 第一档用内置 Codicons 图标调整颜色就够了第一档最简单也适合绝大多数场景。Todo Tree 的 icon 配置接受两类值一类是 VS Code 内置的 Codicons 图标名称一类是自定义扩展提供的图标 ID。常见的内置图标你可以去 VS Code 的图标库网站查搜索 codicons 就能找到或者直接在配置里试。改颜色就是改iconColor字段填十六进制颜色值即可。todo-tree.general.tags: { TODO: { icon: check, iconColor: #22ab24 }, FIXME: { icon: flame, iconColor: #ff6b00 }, XXX: { icon: error, iconColor: #ff0033 } }注意iconColor不是对所有的图标都生效。它本质上是给 SVG 图标做染色tint只有那些使用单色路径stroke 或 fill 是 currentColor的图标才能被染上颜色。很多自定义彩色图标是染不了的因为它们的 SVG 路径里写死了颜色值。如果你改了iconColor但颜色没变九成就是这个原因换成单色的 codicon 图标就正常了。4.2 第二档自建一个主题扩展挂上自己的 SVG 图标如果你不甘心用现成图标想完全自定义一个属于自己的 TODO 图标比如一只小章鱼盯着一行注释那就得走 VS Code 的主题扩展机制了。听起来很重其实步骤很标准化我拆解一下。第一步初始化扩展项目用官方脚手架命令npm install -g yo generator-code yo codeInteractive 提示里选择 New Theme Extension然后让你选 themes type 的时候选New Color Theme其实不太对这里应该选 New Theme Extension 里的 Color Theme 也可以但更准确的做法是我们需要的其实是一个能注册 Product Icon Theme 或者只是注册配置文件里contributes.icons的扩展。更简洁的做法是直接手动建目录结构不依赖 yo 脚手架custom-icon-extension/ ├── package.json ├── icons/ │ ├── todo.svg │ ├── fixme.svg │ └── xxx.svg └── themes/ └── custom-icon-theme.json第二步写 package.json 声明 contributed icons关键在contributes字段。VS Code 从 1.64 左右开始支持在扩展里通过contributes.icons定义自定义图标你可以这么写{ name: custom-todo-icons, displayName: Custom Todo Icons, version: 0.0.1, engines: { vscode: ^1.75.0 }, categories: [Themes], contributes: { icons: { custom-todo: { description: Custom TODO icon, default: { fontPath: icons/todo.svg, fontCharacter: \\E001 } } } } }等一下这里如果完全按照 VS Code 扩展 API 的contributes.icons写其实它不是用来给 Todo Tree 用的这里要给 Todo Tree 用更正统的方式是把图标作为文件路径在 Todo Tree 配置里直接引用。实际上 Todo Tree 支持在 tag 配置里写绝对路径的 SVG 文件比如todo-tree.general.tags: { TODO: { icon: file:///c:/my-icons/todo.svg, iconColor: #22ab24 } }而这种使用方式的前提是图标本身是单色路径可染色的。所以自制图标最简洁的路径不是做 VS Code 扩展而是直接写一个 SVG 文件然后在 settings.json 里面用file://协议指向它。如果你想要把图标打包分发再考虑做成扩展也不迟。第三步写一个可以被染色的 SVG这个 SVG 不需要很复杂关键是路径的 fill 或 stroke 必须写成currentColor。举个例子一个简单的圆形对勾图标svg xmlnshttp://www.w3.org/2000/svg viewBox0 0 16 16 width16 height16 path dM8 1a7 7 0 1 0 0 14A7 7 0 0 0 8 1zm3.54 4.04l-4.5 4.5L5.46 7.96l-0.71.71 1.79 1.79 5.21-5.21-0.71-.71z fillcurrentColor / /svg核心就是把fill属性固定为currentColor。这样 Todo Tree 的iconColor配置才能在这个图标上生效你后续想换颜色只需改配置不用动 SVG 文件。第四步在 Todo Tree 配置里引用你的 SVGtodo-tree.general.tags: { TODO: { icon: file:///d:/dev/custom-icons/my-todo.svg, iconColor: #22ab24 } }路径要写绝对路径Windows 下盘符写法就是上面那样。这样配完刷新窗口Developer: Reload Window侧边栏和编辑器内高亮处的图标都会变成你自制的样式。4.3 第三档极客玩法做一个完整的 VS Code 扩展分发图标如果你有多个同事都要用同一套自定义图标靠每个人各自在本机配置file://路径就太低效了。这时可以把图标打包成一个 VS Code 扩展在项目内共享。实现思路是利用 VS Code 的扩展机制在package.json里声明contributes.icons然后在 Todo Tree 配置里引用你扩展提供的图标 ID而不是文件路径。一个可行的简化配置如下假设你的扩展 ID 是my-org.custom-todo-icons{ contributes: { icons: { my-todo: { description: My custom TODO icon, default: { fontPath: icons/custom-icon-set.woff, fontCharacter: \\E001 } } } } }这里用的是字体图标方式。把 SVG 转成 woff 字体再指定一个字符位置VS Code 就会把它们作为产品图标使用。然后在 Todo Tree 配置里通过icon字段引用图标 IDtodo-tree.general.tags: { TODO: { icon: my-todo, iconColor: #22ab24 } }要注意的是通过扩展贡献的图标是否能被 Todo Tree 直接引用取决于 Todo Tree 内部对 ThemeIcon 的处理方式。实测下来部分版本的 Todo Tree 支持直接引用扩展图标 ID部分版本只支持 codicon 或文件路径。所以如果你配置了发现不生效最快的排查方法是切换到file://路径方式保证能用再说。字体文件的转换可以使用任意 SVG 转字体工具网上搜 Icon Font Generator 一大把挑个支持 woff 导出的就行。4.4 图标设计中的经验与注意说了半天怎么做最后聊聊我的图标设计心得免得你花了半小时做出来一个丑得不忍直视的图标翻车。第一可视尺寸要饱满。VS Code 的 codicon 标准视觉尺寸是 16x16SVG 画布建议 16x16路径主体要占满 12~14px 的有效面积不能画个小圆圈在正中间否则渲染出来特别小看都看不清。第二图标语义要一眼懂。TODO 适合圆形、勾、时钟FIXME 适合扳手、工具、警示三角XXX 适合叉、红色感叹号。别把 TODO 画成一个文件夹——没人能一眼懂这个意思。第三路径尽量简单。SVG 路径里 path 数量越少越好节点越少越好主要是因为染色的原因复杂的渐变和 fill 规则在染了currentColor之后会变得很奇怪。能用一条 path 完成就别拆成 3 条。第四写完记得测试两种状态亮色主题和暗色主题下的显示效果。同一颜色在两种背景下观感差异很大尤其浅色 iconColor 在暗色主题下可能一片模糊。5. 常见问题与排查技巧实录即使配置都按教程做完了实际用起来总会碰到一些奇奇怪怪的问题。这里把我踩过坑和帮别人排查过的典型问题整理成一份速查表再补充几个排查思路这部分我认为才是最值钱的。5.1 高频问题速查表问题现象可能原因解决方式写了//TODO没有空格不被识别默认正则要求注释符号和标签间有空白修改todo-tree.regex.regex加入\\s{0,1}匹配零或一个空格图标颜色不生效图标不是单色路径设置颜色被忽略换成 codicon 或自己画一个 fill 为currentColor的 SVG侧边栏里看不到某目录的条目该目录被excludeGlobs排除了检查todo-tree.filtering.excludeGlobs去掉相关规则Git 子模块或符号链接目录没有条目followSymlinks为 false改为 true或者把子模块目录显式加入 scan 范围编辑器内的行高亮不显示行高亮和图标是分开配置的检查todo-tree.highlights.enabled默认 true再看文件语言是否有对应的注释类型映射插件扫出来的结果和全局搜索数量不一致Todo Tree 只认正则匹配到的行可能漏了多行注释适当放宽todo-tree.regex.regex覆盖/*、*开头的情况扫描完侧边栏一直转圈项目文件太大或扫描了二进制文件增大 exclude 范围排除 log、min、svg、lock 等文件标签在 Tree 里显示为默认图标配置的 icon 名称不存在或写错换成真实存在的 codicon 名称或检查自定义图标是否被正确加载换图标后没有刷新配置更改有时需要重载窗口执行Developer: Reload Window强制刷新5.2 排查思路从哪几层去看如果遇到一个诡异问题我建议你按三层来排查不要瞎试。第一层是正则匹配层确定你的注释文本本身能不能被 Todo Tree 的正则匹配到。最简单的验证方式直接在全局搜索里搜TODO看能不能搜到如果搜到了但 Todo Tree 里没有说明问题大概率出在正则的格式上检查注释符号、标签之间是否有空格、标签是否拼写一致。第二层是配置生效层确定你的 settings.json 语法正确、作用域正确。Todo Tree 的配置是支持工作区级覆盖的如果项目里的.vscode/settings.json和用户级配置冲突后加载的会覆盖前面的排查时要把两个文件都看一遍。第三层是展示层如果编译结果正确但 UI 上不对那大概率是图标加载或主题颜色的问题。直接按 F1 输入 Developer: Toggle Developer Tools打开控制台看看有没有针对todo-tree这个扩展的报错信息有的话搜报错关键词比瞎猜快很多。5.3 一个实际排查案例讲个真事某团队遇到过一个问题同一个项目里几个人装的 Todo Tree 显示结果不一样A 同事能看到 120 个条目B 同事只看到 80 个。一开始大家以为是谁的版本没更新后来发现不是版本问题——B 同事的.vscode/settings.json里自己加过一段配置把excludeGlobs写成了只排除node_modules但他没有意识到这个配置会覆盖用户级设置里的 dist 和 build 排除项导致 dist 里的编译产物被扫进来反而更多才对…… 等一下这里我举的例子和问题反了。实际这个案例里是 B 同事多加了**/dist/**到 exclude但漏了**/test/**而 test 目录里有大量 xxx.spec.ts 文件中带 TODO 注释。A 同事的用户级配置里把test目录也排除了所以 B 同事多看到了 test 目录下的一个条目。这个案例的关键点在于Todo Tree 的配置优先级是工作区 用户工作区的 excludeGlobs 不会继承用户配置而是整体覆盖。如果团队有统一标准建议通过项目级.vscode/settings.json全量声明一次而不是依赖每个人的本地配置。5.4 让 Todo Tree 更强大的三个高阶技巧日常用熟之后三个高阶技巧能进一步把它的价值放大。技巧一把 Todo Tree 嵌入到工作流里。利用任务系统在你 git commit 之前自动扫描一遍 TODO 清单如果发现新的 FIXME 或者 XXX 就提示确认。具体做法可以借助 VS Code Tasks 脚本但更多人的做法是给 CI 加一条静态检查任务把grep -r TODO的结果输出到一个告警文件供人工 review。代码提交前自动感知你正在带着债务上车很多问题就能消灭在早期。技巧二和 Git 集成判断债务归属。配合 Git Lens 或内置的 Git blame你可以在 Todo Tree 里点击某条 TODO切换出来看看这条注释是哪次提交加进去的谁加的代码当时是什么状态。如果你是团队组长每周清点一次本周新增的 TODO/FIXME找对应的人聊一句这个注释你打算什么时候处理长期坚持下来项目里的临时债务会少非常多。技巧三为自己维护今日待清理清单。在每天开始写代码之前先打开 Todo Tree审视一遍所有条目把今天要处理的 3 到 5 个高优先级条目在心里排个序。写完代码以后没事刷一遍侧边栏如果发现某个 FIXME 的数字比昨天少了会特别爽。这种良性反馈会让你逐渐养成留注释有成本删注释有成就感的习惯。最后再分享一个小技巧我自己用下来最上瘾的一个操作是把 TODO 注释和标签着色绑定在一起做项目体检。每个月末尾把 Todo Tree 视图截图对比月初的截图一眼看出哪个模块的债务没减少哪个模块的遗留注释在慢慢变少。配合自己定义的HACK和TEMP标签清掉一行注释发个小版本的时刻是真的有一种代码又干净了的踏实感。如果你只是一个刚开始使用 IDE 的新手不要想着一口气把所有配置都配齐先从默认配置开始用一周感受一下侧边栏里那棵树怎么长出来的再用第二周开始定义自己团队的标签规范第三周再考虑折腾自制图标。这是一条循序渐进的路也和所有工程化工具的规律一致——工具是放大器你先有清晰的注释意识才能放大出真正的效率。
刚接触 VSCode 里 TODO 注释的整理时我一度觉得这不就是个高亮插件吗能折腾出什么花来。直到在一个快两年的老项目里我看着密密麻麻散落在几十个文件中的TODO、FIXME、XXX整个人都麻了——这些到底哪些是急着要修的哪些是陈年旧账哪些是临时过渡方案没人说得清因为连注释的发起人自己都忘了。就是从那个时候开始我认真研究起了 Todo Tree 这个插件也把 TODO 类注释的规范、写法和自定义玩法彻底理了一遍。这篇内容适合所有用 VSCode 写代码的人不管你是刚入职的新人还是要带团队的组长搞懂这套注释管理方案你的代码可维护性能往上拉一大截。1. 为什么要用 Todo Tree注释管理的核心需求拆解先说一个很反直觉的事实大部分人的代码注释习惯是把 TODO 当成待办事项在写但实际上 TODO 注释的作用压根不是记事而是标记。标记什么呢标记代码里那些已知但不紧急的问题、暂时妥协的方案、需要在某个时间点回头处理的逻辑。如果不能把这些标记从代码里捞出来聚合成一张清单那它们跟空气没什么区别。1.1 没有管理工具时的痛点清单想象一下没有 Todo Tree 的日子。你想找项目里所有的 FIXME 注释要么靠编辑器全局搜索搜完之后逐个文件跳转再靠人脑记住每个注释的上下文要么用官方自带的问题面板但那个面板对自定义标记的支持很弱基本只能看语法错误和 lint 报错再要么就是靠团队约定大家在群里互相喊话那个谁你留的 TODO 搞一下。这三种方式我都经历过分别对应三个问题第一高亮缺失。默认 VSCode 对TODO这类注释是没有特殊高亮的它在代码里就是一个普通绿色注释跟其他注释混在一起扫一眼根本找不到。第二无法聚合。全局搜索只能给你一个平面结果列表没有分组、没有排序、没有过滤在多文件多标签的情况下你要手动分辨每个条目属于哪块功能。第三上下文断裂。找到注释之后你得再去看它附近的代码才能想起来当时为什么写这个有时候注释离真正的问题代码隔了好几行这个为什么就彻底丢了。1.2 Todo Tree 解决了什么核心问题Todo Tree 做的事情其实很简单就是把所有约定好的标记注释从源码中抽出来在侧边栏生成一棵树按文件路径归类点击即可跳转。听起来好像没什么但实际用下来你会发现它解决了三个层次的问题可视化层次未完成的 TODO 以特殊颜色高亮显示一眼看清哪些代码还在半成品状态。组织层次侧边栏的树状结构天然地反映了项目的功能模块哪个文件欠的债多哪个模块的 FIXME 扎堆一眼分明。流转层次写完注释等于加入清单解决完注释等于自动消失整个过程不需要任何额外操作这是它最打动我的地方——注释即任务清理即完成。第三个层次是很多人忽略的价值。任务管理工具比如各类项目管理软件里的待办和代码里的 TODO 本质上应该是联动的但大多数人的工作流是两套系统互相脱节。Todo Tree 至少让你在代码这个层面形成闭环你不需要在写完一个TODO: 这里需要补充错误处理之后再去另一个软件里记一条别忘了补错误处理。代码本身就是待办清单这个理念很朴素但真的好用。1.3 适合什么场景、什么人群从人群讲我最推荐这几类人优先用起来第一类是维护老项目的人老项目里遗留注释多靠 Todo Tree 像扫雷一样把历史遗留问题清点出来边清点边制定清理计划这是对存量债务的管理第二类是带团队的人你可以在 code review 的时候明确要求新的临时方案必须留 TODO 注释 责任人标识然后在开发周期末尾用 Todo Tree 把欠账拉出来谁的东西谁认领第三类是个人项目爱好者自己写小项目的时候经常写到一半觉得回头再改回头就是一万年Todo Tree 至少能提醒你这里确实没改完。如果你是刚入行的开发者我反而建议你先从规范写注释开始因为工具再好用注释本身一团糟也白搭。看完后面的规范部分再配合插件实践会顺很多。2. 基础配置与核心特性让 Todo Tree 真正听话装插件本身没什么好说的市场里搜 Todo Tree 直接装就行。真正需要花心思的是理解它的配置体系和默认行为背后的意图这样你才不会在遇到为什么这个标签不显示的时候一头雾水。2.1 配置文件里的关键字段解析Todo Tree 的配置项都集中在settings.json里以todo-tree前缀开头。我最先建议你动的是todo-tree.general.tags这个字段定义了插件要识别哪些标记以及每个标记的展示行为。默认配置是长这样的todo-tree.general.tags: { TODO: { icon: check-circle, iconColor: #0a8f3c }, FIXME: { icon: tools, iconColor: #c74e00 }, XXX: { icon: warning, iconColor: #d91e1e } }这里每个标签都配了 icon图标名称和 iconColor图标颜色这个设计特别聪明——它把标记的语义化从文字层面延伸到了视觉层面。TODO 是绿色圆形对勾提示有未完成事项FIXME 是橘色扳手强调需要修理XXX 是红色警告意思是这里特别需要注意再不改要出问题。视觉识别效率比纯文字高得多这是插件做得很细致的一点。2.2 全局开关与正则匹配逻辑还有一个重点字段是todo-tree.filtering.excludeGlobs和todo-tree.general.rootFolder不过我更想提醒你注意todo-tree.regex.regex这个字段。它决定了哪些注释会被匹配到默认长这样todo-tree.regex.regex: (//|#|!--|;|/\\*|\\*)\\s*($TAGS)这个正则其实很好理解前面的(//|#|!--|;|/\\*|\\*)是各种语言里的注释符号后面的($TAGS)会替换成你在tags里定义的所有标签。也就是说Todo Tree 默认只认以注释起始符号开头 空格 标签这种格式的注释。我特意说明这一点是因为很多人踩过一个坑写了//TODO: something没有空格就不被识别或者写/* TODO */里面带了星号前缀匹配起来也有点别扭。解决办法也很简单把正则改成(//|#|!--|;|/\\*|\\*|\\*)\\s*($TAGS)就能多兼容一种星号开头的场景。2.3 侧边栏视图的展示模式与交互技巧装好插件后侧边栏会出现一个 TODO 树最开始你可能觉得这不就是个文件列表吗但这里有几个交互细节值得说点击任意条目会直接跳转到注释所在行光标定位到注释行的开头。条目右侧的数字表示该文件或目录下有多少个匹配标签这个数字会在你解决注释之后实时减少很有成就感。顶部的搜索框是很多人忽略的神器。它支持按标签、按文件路径进行过滤。比如你输入!FIXME就能过滤掉所有 FIXME 条目只看剩下的输入某个文件名关键词就能只看这个文件下的所有条目。右键菜单里可以切换文件对其的包含/排除隐藏当前标签类型这在你有一个目录全是第三方代码不想被扫进来的时候特别有用。还有一个容易被忽略但实际很高效的用法把 Todo Tree 从侧边栏拖到辅助侧边栏Secondary Side Bar。主侧边栏留给资源管理器辅助侧边栏放 TODO 清单这样你可以一边看文件树一边看待办清单互不遮挡效率翻倍。这个小细节我是在一次调窗口布局的时候偶然发现的后来就成了固定习惯。2.4 关于扫描范围与控制范围的进阶配置默认情况下Todo Tree 会扫描整个工作区所有文件。大项目里这就会产生问题扫描慢、结果杂、还有一堆压根不需要管的三方依赖里的注释。所以我一般会配合两个配置用todo-tree.filtering.excludeGlobs: [ **/node_modules/**, **/dist/**, **/build/**, **/vendor/**, **/*.min.* ], todo-tree.general.settings: { followSymlinks: false }excludeGlobs就是字面意思排除你不想扫的目录或文件。followSymlinks设为 false 是为了避免符号链接指向的外部目录被重复扫描。这两个配置一设完侧边栏瞬间清爽扫描速度也明显提升。段首的.vscode工作区配置里也可以单独覆盖这些设置所以在团队协作时你可以把 exclusions 写进项目的.vscode/settings.json让所有协作者共享同一套扫描范围。关于扫描速度还有一个小 tip打开一个超大项目时Todo Tree 第一次扫描可能要 2 到 3 秒这只是建立树索引的时间后面文件编辑时它做的是增量更新不会让你感到卡顿。如果你觉得卡八成不是插件的问题而是你有个特别巨大的文件比如几百 M 的日志文件这种文件直接加进 exclude 就完事了。3. TODO 注释的正确打开方式从格式到团队规范插件配置再花哨如果注释本身写得乱七八糟Todo Tree 也只能给你展示一堆乱七八糟的条目。这一章我想认真谈谈注释规范的问题。注释是写给未来的自己和其他开发者看的这句话说了无数遍但真正执行的人不多。3.1 三种核心标签的语义界定先说语义。很多团队对 TODO、FIXME、XXX 的用法是模糊的经常把 FIXME 当成 TODO 用或者把 XXX 当 FIXME 用这会导致后面看清单的时候完全分不清轻重缓急。下面这套区分是我个人比较推荐的也是不少公司内部规范里常见的一种标签含义典型场景优先级TODO待办事项需要后续补充或完善的功能缺错误处理、缺边界条件、后续接入真实接口中FIXME已知问题当前行为有误但尚未修复这里逻辑有 bug 但先绕过、临时 workaround高XXX警告标记代码危险或需要特别警惕这里有性能隐患、这里可能崩溃但测试环境没事最高HACK临时方案写得很丑但能跑借了个 map 在 filter 里做条件分支自己都看不下去高核心原则是TODO 是未来要做FIXME 是现在有问题XXX 是这里很危险。三者的共同点是都不会立刻动手解决区别在于解决时的紧急程度和处理方式。FIXME 一般是要修复现有行为的 bugTODO 是要添加当前缺失的能力XXX 则是提醒别人动这里之前先想清楚别把隐患越捅越大。3.2 结构化注释格式让清单可以追责光有标签还远远不够。我强烈建议在团队里推广结构化注释格式也就是在标签后面补充类型、责任人和时间信息像这样// TODO[error-handling]: 补全接口超时后的重试逻辑 // FIXME[legacy-payment]: 这里的金额单位混用了分和元需要统一 // XXX[performance]: 这个双循环在数据量达到 10w 时耗时超过 2s // TODO[refactor][某开发者]: 等账单模块重构完成后把这段拆出去你可以看到方括号里写了模块或问题类型有时候还带责任人和时间。这样做有什么好处第一Todo Tree 的搜索框可以按方括号里的关键字过滤比如输入performance就能定位所有性能相关的待办第二责任人信息让清单可以追责code review 的时候当场确认归属比在群里人高效得多第三时间信息可以帮你识别陈年债——超过三个月没人动的 TODO基本可以判断优先级没那么高可以先降级。不过我建议时间信息不要写绝对日期写相对行动点更稳妥例如TODO[refactor]: 等下一个 sprint 开始后处理。写绝对日期的坏处是如果某天已经过去留着一行2024-03-05的注释会让人有种这个任务是不是过期忘了的暗示反而产生认知负担。3.3 注释中英文混写的通行准则还有一个实操问题注释到底用中文还是英文我的看法是英文注释在跨团队协作或开源项目里有必要但国内团队内部用中文完全没有问题效率更高。关键是保持一致性。你不要一个文件全中文另一个文件全英文更不要一条注释里中英混杂还没有空格。另外尽量别在注释里写太口语化的词比如弄一下搞搞建议用「处理」「修复」「优化」「重构」「补充」这类动词这样搜索的时候关键词更统一。同一类 TODO 的描述尽量使用统一的句式比如全部用补全修复优化这样 Todo Tree 的清单扫过去非常整齐。3.4 标签之外的隐藏注释类型HACK、BUG、TEMP、OPTIMIZETodo Tree 的 tags 默认只显示那三个标签但实际开发中我们经常还会用到别的标记。这些标记如果你不主动在配置里添加Todo Tree 就不会识别所以很多人根本不知道插件支持自定义标签。其实完全可以加比如todo-tree.general.tags: { TODO: { icon: check-circle, iconColor: #0a8f3c }, FIXME: { icon: tools, iconColor: #c74e00 }, XXX: { icon: warning, iconColor: #d91e1e }, HACK: { icon: bug, iconColor: #a371f7 }, BUG: { icon: bug, iconColor: #d91e1e }, TEMP: { icon: circle-outline, iconColor: #e0a800 }, OPTIMIZE: { icon: zap, iconColor: #2d7ff9 } }加完后Todo Tree 会把这几个新标签也显示在侧边栏并且自动高亮。我实际项目里加得最多的是HACK和TEMP因为这两类注释出现的频率非常高。HACK代表我知道这写得很丑陋但我现在没时间优化它的价值在于给后续接手的开发者一个心理预期别对着烂代码骂娘。TEMP则代表这只是临时方案正式方案上线后必须换掉这种标签非常适合在对接第三方服务、写 mock 数据、走通主流程还没做边界处理的时候用。4. 自制自定义图标从改颜色到换图标的完整玩法说完了常规配置终于到了标题里那个最有意思的部分——自制 TODO 图标样式。很多教程到改个颜色就停了但 Todo Tree 这套图标的可定制性远比大部分人以为的要深。我分三档玩法讲你可以根据自己的实际需求选一档。4.1 第一档用内置 Codicons 图标调整颜色就够了第一档最简单也适合绝大多数场景。Todo Tree 的 icon 配置接受两类值一类是 VS Code 内置的 Codicons 图标名称一类是自定义扩展提供的图标 ID。常见的内置图标你可以去 VS Code 的图标库网站查搜索 codicons 就能找到或者直接在配置里试。改颜色就是改iconColor字段填十六进制颜色值即可。todo-tree.general.tags: { TODO: { icon: check, iconColor: #22ab24 }, FIXME: { icon: flame, iconColor: #ff6b00 }, XXX: { icon: error, iconColor: #ff0033 } }注意iconColor不是对所有的图标都生效。它本质上是给 SVG 图标做染色tint只有那些使用单色路径stroke 或 fill 是 currentColor的图标才能被染上颜色。很多自定义彩色图标是染不了的因为它们的 SVG 路径里写死了颜色值。如果你改了iconColor但颜色没变九成就是这个原因换成单色的 codicon 图标就正常了。4.2 第二档自建一个主题扩展挂上自己的 SVG 图标如果你不甘心用现成图标想完全自定义一个属于自己的 TODO 图标比如一只小章鱼盯着一行注释那就得走 VS Code 的主题扩展机制了。听起来很重其实步骤很标准化我拆解一下。第一步初始化扩展项目用官方脚手架命令npm install -g yo generator-code yo codeInteractive 提示里选择 New Theme Extension然后让你选 themes type 的时候选New Color Theme其实不太对这里应该选 New Theme Extension 里的 Color Theme 也可以但更准确的做法是我们需要的其实是一个能注册 Product Icon Theme 或者只是注册配置文件里contributes.icons的扩展。更简洁的做法是直接手动建目录结构不依赖 yo 脚手架custom-icon-extension/ ├── package.json ├── icons/ │ ├── todo.svg │ ├── fixme.svg │ └── xxx.svg └── themes/ └── custom-icon-theme.json第二步写 package.json 声明 contributed icons关键在contributes字段。VS Code 从 1.64 左右开始支持在扩展里通过contributes.icons定义自定义图标你可以这么写{ name: custom-todo-icons, displayName: Custom Todo Icons, version: 0.0.1, engines: { vscode: ^1.75.0 }, categories: [Themes], contributes: { icons: { custom-todo: { description: Custom TODO icon, default: { fontPath: icons/todo.svg, fontCharacter: \\E001 } } } } }等一下这里如果完全按照 VS Code 扩展 API 的contributes.icons写其实它不是用来给 Todo Tree 用的这里要给 Todo Tree 用更正统的方式是把图标作为文件路径在 Todo Tree 配置里直接引用。实际上 Todo Tree 支持在 tag 配置里写绝对路径的 SVG 文件比如todo-tree.general.tags: { TODO: { icon: file:///c:/my-icons/todo.svg, iconColor: #22ab24 } }而这种使用方式的前提是图标本身是单色路径可染色的。所以自制图标最简洁的路径不是做 VS Code 扩展而是直接写一个 SVG 文件然后在 settings.json 里面用file://协议指向它。如果你想要把图标打包分发再考虑做成扩展也不迟。第三步写一个可以被染色的 SVG这个 SVG 不需要很复杂关键是路径的 fill 或 stroke 必须写成currentColor。举个例子一个简单的圆形对勾图标svg xmlnshttp://www.w3.org/2000/svg viewBox0 0 16 16 width16 height16 path dM8 1a7 7 0 1 0 0 14A7 7 0 0 0 8 1zm3.54 4.04l-4.5 4.5L5.46 7.96l-0.71.71 1.79 1.79 5.21-5.21-0.71-.71z fillcurrentColor / /svg核心就是把fill属性固定为currentColor。这样 Todo Tree 的iconColor配置才能在这个图标上生效你后续想换颜色只需改配置不用动 SVG 文件。第四步在 Todo Tree 配置里引用你的 SVGtodo-tree.general.tags: { TODO: { icon: file:///d:/dev/custom-icons/my-todo.svg, iconColor: #22ab24 } }路径要写绝对路径Windows 下盘符写法就是上面那样。这样配完刷新窗口Developer: Reload Window侧边栏和编辑器内高亮处的图标都会变成你自制的样式。4.3 第三档极客玩法做一个完整的 VS Code 扩展分发图标如果你有多个同事都要用同一套自定义图标靠每个人各自在本机配置file://路径就太低效了。这时可以把图标打包成一个 VS Code 扩展在项目内共享。实现思路是利用 VS Code 的扩展机制在package.json里声明contributes.icons然后在 Todo Tree 配置里引用你扩展提供的图标 ID而不是文件路径。一个可行的简化配置如下假设你的扩展 ID 是my-org.custom-todo-icons{ contributes: { icons: { my-todo: { description: My custom TODO icon, default: { fontPath: icons/custom-icon-set.woff, fontCharacter: \\E001 } } } } }这里用的是字体图标方式。把 SVG 转成 woff 字体再指定一个字符位置VS Code 就会把它们作为产品图标使用。然后在 Todo Tree 配置里通过icon字段引用图标 IDtodo-tree.general.tags: { TODO: { icon: my-todo, iconColor: #22ab24 } }要注意的是通过扩展贡献的图标是否能被 Todo Tree 直接引用取决于 Todo Tree 内部对 ThemeIcon 的处理方式。实测下来部分版本的 Todo Tree 支持直接引用扩展图标 ID部分版本只支持 codicon 或文件路径。所以如果你配置了发现不生效最快的排查方法是切换到file://路径方式保证能用再说。字体文件的转换可以使用任意 SVG 转字体工具网上搜 Icon Font Generator 一大把挑个支持 woff 导出的就行。4.4 图标设计中的经验与注意说了半天怎么做最后聊聊我的图标设计心得免得你花了半小时做出来一个丑得不忍直视的图标翻车。第一可视尺寸要饱满。VS Code 的 codicon 标准视觉尺寸是 16x16SVG 画布建议 16x16路径主体要占满 12~14px 的有效面积不能画个小圆圈在正中间否则渲染出来特别小看都看不清。第二图标语义要一眼懂。TODO 适合圆形、勾、时钟FIXME 适合扳手、工具、警示三角XXX 适合叉、红色感叹号。别把 TODO 画成一个文件夹——没人能一眼懂这个意思。第三路径尽量简单。SVG 路径里 path 数量越少越好节点越少越好主要是因为染色的原因复杂的渐变和 fill 规则在染了currentColor之后会变得很奇怪。能用一条 path 完成就别拆成 3 条。第四写完记得测试两种状态亮色主题和暗色主题下的显示效果。同一颜色在两种背景下观感差异很大尤其浅色 iconColor 在暗色主题下可能一片模糊。5. 常见问题与排查技巧实录即使配置都按教程做完了实际用起来总会碰到一些奇奇怪怪的问题。这里把我踩过坑和帮别人排查过的典型问题整理成一份速查表再补充几个排查思路这部分我认为才是最值钱的。5.1 高频问题速查表问题现象可能原因解决方式写了//TODO没有空格不被识别默认正则要求注释符号和标签间有空白修改todo-tree.regex.regex加入\\s{0,1}匹配零或一个空格图标颜色不生效图标不是单色路径设置颜色被忽略换成 codicon 或自己画一个 fill 为currentColor的 SVG侧边栏里看不到某目录的条目该目录被excludeGlobs排除了检查todo-tree.filtering.excludeGlobs去掉相关规则Git 子模块或符号链接目录没有条目followSymlinks为 false改为 true或者把子模块目录显式加入 scan 范围编辑器内的行高亮不显示行高亮和图标是分开配置的检查todo-tree.highlights.enabled默认 true再看文件语言是否有对应的注释类型映射插件扫出来的结果和全局搜索数量不一致Todo Tree 只认正则匹配到的行可能漏了多行注释适当放宽todo-tree.regex.regex覆盖/*、*开头的情况扫描完侧边栏一直转圈项目文件太大或扫描了二进制文件增大 exclude 范围排除 log、min、svg、lock 等文件标签在 Tree 里显示为默认图标配置的 icon 名称不存在或写错换成真实存在的 codicon 名称或检查自定义图标是否被正确加载换图标后没有刷新配置更改有时需要重载窗口执行Developer: Reload Window强制刷新5.2 排查思路从哪几层去看如果遇到一个诡异问题我建议你按三层来排查不要瞎试。第一层是正则匹配层确定你的注释文本本身能不能被 Todo Tree 的正则匹配到。最简单的验证方式直接在全局搜索里搜TODO看能不能搜到如果搜到了但 Todo Tree 里没有说明问题大概率出在正则的格式上检查注释符号、标签之间是否有空格、标签是否拼写一致。第二层是配置生效层确定你的 settings.json 语法正确、作用域正确。Todo Tree 的配置是支持工作区级覆盖的如果项目里的.vscode/settings.json和用户级配置冲突后加载的会覆盖前面的排查时要把两个文件都看一遍。第三层是展示层如果编译结果正确但 UI 上不对那大概率是图标加载或主题颜色的问题。直接按 F1 输入 Developer: Toggle Developer Tools打开控制台看看有没有针对todo-tree这个扩展的报错信息有的话搜报错关键词比瞎猜快很多。5.3 一个实际排查案例讲个真事某团队遇到过一个问题同一个项目里几个人装的 Todo Tree 显示结果不一样A 同事能看到 120 个条目B 同事只看到 80 个。一开始大家以为是谁的版本没更新后来发现不是版本问题——B 同事的.vscode/settings.json里自己加过一段配置把excludeGlobs写成了只排除node_modules但他没有意识到这个配置会覆盖用户级设置里的 dist 和 build 排除项导致 dist 里的编译产物被扫进来反而更多才对…… 等一下这里我举的例子和问题反了。实际这个案例里是 B 同事多加了**/dist/**到 exclude但漏了**/test/**而 test 目录里有大量 xxx.spec.ts 文件中带 TODO 注释。A 同事的用户级配置里把test目录也排除了所以 B 同事多看到了 test 目录下的一个条目。这个案例的关键点在于Todo Tree 的配置优先级是工作区 用户工作区的 excludeGlobs 不会继承用户配置而是整体覆盖。如果团队有统一标准建议通过项目级.vscode/settings.json全量声明一次而不是依赖每个人的本地配置。5.4 让 Todo Tree 更强大的三个高阶技巧日常用熟之后三个高阶技巧能进一步把它的价值放大。技巧一把 Todo Tree 嵌入到工作流里。利用任务系统在你 git commit 之前自动扫描一遍 TODO 清单如果发现新的 FIXME 或者 XXX 就提示确认。具体做法可以借助 VS Code Tasks 脚本但更多人的做法是给 CI 加一条静态检查任务把grep -r TODO的结果输出到一个告警文件供人工 review。代码提交前自动感知你正在带着债务上车很多问题就能消灭在早期。技巧二和 Git 集成判断债务归属。配合 Git Lens 或内置的 Git blame你可以在 Todo Tree 里点击某条 TODO切换出来看看这条注释是哪次提交加进去的谁加的代码当时是什么状态。如果你是团队组长每周清点一次本周新增的 TODO/FIXME找对应的人聊一句这个注释你打算什么时候处理长期坚持下来项目里的临时债务会少非常多。技巧三为自己维护今日待清理清单。在每天开始写代码之前先打开 Todo Tree审视一遍所有条目把今天要处理的 3 到 5 个高优先级条目在心里排个序。写完代码以后没事刷一遍侧边栏如果发现某个 FIXME 的数字比昨天少了会特别爽。这种良性反馈会让你逐渐养成留注释有成本删注释有成就感的习惯。最后再分享一个小技巧我自己用下来最上瘾的一个操作是把 TODO 注释和标签着色绑定在一起做项目体检。每个月末尾把 Todo Tree 视图截图对比月初的截图一眼看出哪个模块的债务没减少哪个模块的遗留注释在慢慢变少。配合自己定义的HACK和TEMP标签清掉一行注释发个小版本的时刻是真的有一种代码又干净了的踏实感。如果你只是一个刚开始使用 IDE 的新手不要想着一口气把所有配置都配齐先从默认配置开始用一周感受一下侧边栏里那棵树怎么长出来的再用第二周开始定义自己团队的标签规范第三周再考虑折腾自制图标。这是一条循序渐进的路也和所有工程化工具的规律一致——工具是放大器你先有清晰的注释意识才能放大出真正的效率。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
