VSCode无法准确统计代码贡献度；GitLens的blame仅显示最后修改者，不区分新增/修改/删除且受rebase影响，Authorship视图只按行着色不统计行数，VSCodeCounter仅统计物理行数无关作者，真实贡献须用git log --numstat等命令行分析。
VSCode 编辑器内无法准确查看“代码提交记录贡献度”——所谓“谁写了多少行”，不是编辑器能算清的事，所有插件显示的都是近似、易失真、甚至误导性的数字。
GitLens 的 blame 注释只告诉你“谁最后改了这行”
启用 gitlens.gbl.annotations.enabled 后，行尾会显示作者名、时间、哈希，但它不区分：
- 这行是全新写的，还是只删了个空格就提交了
- 这行是否来自 rebase 后覆盖的原始作者（rebase 会让 blame 显示操作者而非真实作者）
- 某次提交中删了 200 行又重写 150 行，
git blame会把新写的每行都标给这次提交者，但逻辑可能全继承自别人
Authorship 视图不统计行数，只按行着色
执行 GitLens: Toggle File Authorship View 后看到的颜色块，本质是把文件按行分段，再根据该行当前 git blame 结果上色。它：
- 不关联 commit 时间范围、不支持按作者过滤
- 无法导出数据，不能用于汇报或考核
- 对 JSX/TSX 中的表达式块（如
{user?.name}）同样着色，但这类内容几乎不体现“开发工作量”
VSCodeCounter 统计的是文件总行数，和 Git 作者完全无关
它读的是磁盘上当前文件的物理行数，不是 Git 提交历史。常见误用包括：
- 没开
"VSCodeCounter.useGitignore": true，导致node_modules被计入，总数虚高 5–10 倍 - 把
.tsx文件里 400 行 JSX 模板当成“有效代码行”，实际可维护逻辑可能只有 80 行 - 完全不识别
git log --author，所以哪怕你只改过 3 次utils/下的文件，它也会把整个目录 2800 行全算作“你的”
真要查贡献，必须离开 VSCode 执行 Git 命令
编辑器只是界面，Git 的 author、committer、numstat、merge/rebase 行为都在命令行层面。例如：
git log --author="Alice" --pretty=tformat: --numstat --since="6 months ago" -- src/ | awk '{add+=$1; del+=$2} END{print "added:", add, "deleted:", del}'这个命令能告诉你 Alice 在半年内对 src/ 目录的真实增删行数——它基于 commit 对象本身，不受 rebase 干扰，也不依赖编辑器渲染逻辑。VSCode 插件做不到这点，因为它们没有权限或机制去遍历所有 commit 并解析 --numstat 输出。
最常被忽略的一点：所谓“贡献度”，从来不是单维度的行数或提交次数；它藏在 PR 描述质量、review 反馈密度、changelog 清晰度、甚至 revert 频率里——这些，VSCode 连边都摸不到。
