VSCode插件开发示例_手把手教你做一个代码统计插件

VS Code代码行数统计插件漏统计的主因是仅监听onDidChangeTextDocument而忽略文件打开、切换等场景；须同时监听onDidOpenTextDocument、onDidChangeActiveTextEditor（需判空）和onDidChangeTextDocument，并逐行扫描lineAt()计算非空非注释行。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

为什么 vscode.workspace.onDidChangeTextDocument 会漏统计？

开发过代码统计插件的朋友，大概率都踩过这个坑：插件明明运行着，可一打开新文件，行数显示却是个大大的“0”。用户难免会疑惑：是我的代码不配被统计吗？

其实问题根源很明确：onDidChangeTextDocument 这个监听器，顾名思义，它只响应文档内容变更。当用户首次打开一个 .js 文件，或者从资源管理器直接点开时，文档只是被加载到编辑器里，内容并未修改，这个事件自然不会触发。插件没收到通知，自然也就不会去统计，结果就漏了。

所以，正确的监听策略必须是“三管齐下”：

• 用 vscode.workspace.onDidOpenTextDocument 捕获新文件打开的动作。
• 用 vscode.window.onDidChangeActiveTextEditor 捕获用户在多个标签页之间切换焦点的行为（比如从 A.ts 切到 B.py）。
• 最后，再用 onDidChangeTextDocument 来兜底，确保代码被编辑时，统计数据能实时更新。

这里有个细节需要特别留意：onDidChangeActiveTextEditor 的回调参数，在某些情况下（例如用户把焦点从编辑器移到了终端面板）会是 null。如果不做判空处理，直接去访问其属性，插件就会崩溃。这是新手很容易疏忽的一个点。

怎么安全获取当前文件的有效代码行数？

解决了“何时统计”的问题，接下来就是“如何统计”了。直接使用 document.lineCount 获取总行数？这显然不对，因为它会把空行、注释行（包括多行注释中间的空行）全都算进去。我们真正需要的，通常是“有效的、非注释的代码行数”。

这就需要我们手动进行逐行扫描和判断，关键点有三个：

• 逐行处理：调用 document.lineAt(i).text.trim() 获取每一行的内容并去除首尾空格。如果结果是空字符串，那就是空行，跳过。
• 识别单行注释：使用正则表达式 /^\s*\/\/.*$/ 来判断。注意，行首可能存在的空格或制表符也要匹配进去。
• 处理多行注释：这是稍微复杂的地方。需要维护一个状态变量，当遇到 /* 时，进入“注释模式”，在此之后直到遇到 */ 之前的所有行（包括其中的空行），都应被视为注释行而忽略。

另外，性能上也要注意。切忌使用 document.getText().split(‘\n’) 这种方式一次性把整个文件内容拆分成数组。对于超过10MB的大文件，这种操作极易导致内存激增甚至卡死。VS Code官方推荐的流式访问方式，正是逐行调用 lineAt()，这对内存更加友好。

状态栏显示数字后，为什么点击没反应？

好不容易把数字正确显示在状态栏了，用户想点击查看详情，却发现毫无反应。这多半是交互逻辑没配置完整。

VS Code的状态栏项（StatusBarItem）默认只是一个被动的显示控件，要让它可点击，必须显式地为其指定一个命令。你需要：

• 在创建状态栏项后，设置 item.command = ‘extension.showStats’（这里‘extension.showStats’是你自定义的命令ID）。
• 在插件的 package.json 文件的 contributes.commands 部分，注册这个同名命令。
• 在插件的激活函数 activate() 中，使用 vscode.commands.registerCommand() 来绑定这个命令ID和具体的处理函数。

常见的疏漏包括：命令ID的大小写不一致（VS Code对此是敏感的）、忘记了注册命令，或者最基础的——没有调用 item.show() 方法。记住，即使你设置了 text 属性，不调用 show()，状态栏项就根本不会渲染出来。

一个简单的调试技巧：在命令的处理函数里，先加上一行 vscode.window.showInformationMessage(‘clicked!’)。如果点击状态栏能弹出这个信息提示，就证明命令绑定成功了。

打包发布前，为什么本地跑得好，别人装了就报 Cannot find module ‘./extension’？

这是使用TypeScript开发插件，在打包发布环节最经典的错误之一。本地测试一切正常，但用 vsce package 打包成 .vsix 文件给别人安装后，却报错找不到模块。

问题的核心在于路径解析。你的 package.json 里 main 字段很可能写的是 ./src/extension.ts。然而，VS Code插件运行时加载的是Ja vaScript文件，而不是TypeScript源文件。vsce 这个打包工具默认不会帮你执行TypeScript编译。

因此，必须确保两件事：

• 首先，检查 tsconfig.json，确保输出目录 outDir 设置为 ./out，并且源代码根目录 rootDir 正确指向 ./src。
• 然后，将 package.json 中的 main 字段修改为编译后的入口文件路径：./out/extension.js。

为了避免每次打包前都忘记编译，一个非常实用的做法是在 package.json 的 scripts 里加一条命令：“package”: “tsc && vsce package”。这样，运行 npm run package 就能自动完成编译和打包。

当然，随着插件变得复杂，可能会引入Webpack打包、处理 node_modules 依赖等更高级的方案，这些都会改变最终的输出结构。但对于一个纯TypeScript的插件起步阶段而言，牢牢守住“编译输出到 out 目录，并将 main 指向 out/extension.js”这条底线，就能避开这个最常见的发布陷阱。