coverage gutters 是首选，因其直接在编辑器行号旁以绿/红色标记行级覆盖率，响应快、不跳转、支持 lcov/xml/cobertura 多种格式；而 coverage viewer 仅在状态栏显示总覆盖率数字，无行级提示，无法指导补写测试用例。
Coverage Gutters 为什么是首选，而不是 Coverage Viewer
Coverage Gutters 直接在编辑器行号旁染色（绿色/红色），响应快、不跳转、支持 lcov/xml/cobertura 多种格式；Coverage Viewer 只在状态栏显示总覆盖率数字，点进去才打开 HTML 报告——它不标记具体哪一行没覆盖。如果你要补测试用例，得靠行级提示，不是看一个百分比。
它不生成数据，只读取：你必须先让 Jest/Pytest/dotnet test 输出 lcov.info 或 coverage.xml，它才会有东西可画。装了插件但状态栏一直显示 No coverage data found，90% 是因为报告根本没生成，或者路径不对。
Jest/Vitest 项目中 lcov.info 没生成或路径错的典型表现
运行 jest --coverage 后，coverage/lcov.info 不存在？不是插件问题，是命令漏了 reporter：
-
jest --coverage默认只输出文本和 HTML，必须加--coverageReporters=lcov - Vitest 需在
vitest.config.ts中写coverage: { reporter: ['lcov'] }，光写enabled: true不生效 -
lcov.info必须在coverage/lcov.info（默认路径），如果改到out/coverage/lcov.info，就得在 VSCode 设置里配"coverage-gutters.lcovname"为"out/coverage/lcov.info" - 检查
lcov.info里每段的SF:行路径，比如SF:/home/user/proj/src/index.ts，而你在 VSCode 打开的是./src/index.ts—— 路径前缀不一致，整文件就不会染色
Python 项目用 pytest-cov 时 coverage.xml 总不显示的硬伤
Coverage Gutters 默认找 coverage.xml，但 pytest --cov=. 默认只生成二进制 .coverage 文件，它完全忽略这个文件。
必须显式指定 XML 输出：
- 命令行跑：
pytest --cov=src --cov-report=xml:coverage.xml（注意是xml:coverage.xml，不是xml） - VSCode 的
python.testing.pytestArgs必须是数组：["--cov=src", "--cov-report=xml:coverage.xml"]，写成字符串会报unrecognized arguments - 打开
coverage.xml，搜索你当前编辑的文件名，看<source></source>值是不是和 VSCode 左侧资源管理器里显示的路径完全一致（包括大小写、/还是\、有没有./开头） - 用 WSL 或 Docker 时，
<source></source>常是/mnt/c/project/src/xxx.py，而 VSCode 打开的是C:\project\src\xxx.py，得手动用sed或编辑器替换路径前缀
Q# 项目覆盖率可视化卡在哪几个环节
Q# 本身不直接产出覆盖率，靠 .NET 测试链间接实现：C# 宿主代码能覆盖，Q# 操作逻辑只能靠断言行为验证。所以你看到的 coverage.json 主要是测试类和驱动代码，不是量子门序列。
关键动作只有三步：
- 项目文件中确认有
<packagereference include="coverlet.collector" version="3.2.0"></packagereference> - 执行
dotnet test --collect:"XPlat Code Coverage"，生成coverage.json（不是lcov.info） - 用
dotnet-reportgenerator-globaltool转成 HTML：reportgenerator -reports:coverage.json -targetdir:coveragereport -reporttypes:Html，再用 Coverage Gutters 手动加载——它不原生支持coverage.json，得转格式
真正容易被忽略的是：Q# 的覆盖率数值反映的是 C# 测试胶水层，不是 Q# 本身。想确认一个 ApplyToEach 是否被所有分支触发，还得靠多个输入组合 + Assert 断言，不能只盯那个 60% 的数字。
