玩过Go覆盖率的同学当有所了解，Go的覆盖率方案最初的设计目标仅是针对单测场景，导致其局限性很大。而为了适配更多的场景，行业内各种博客、插件、黑科技介绍也层出不穷。当然，过去我们也开源过Go系统测试覆盖率收集利器 - goc，算其中比较完善，比较系统的了。且从用户使用角度来看，goc也确实解决了行业内很多同学的痛点。
Than McIntosh基于作者的Proposal，我们先来看看这个提案细节。
新姿势: go build -cover
go test -covergo build -cover在新姿势下，使用流程大体是:
整体逻辑也比较清晰：
go tool covdatacovdata新版覆盖率格式
先来看旧版的覆盖率结果:
大家当比较熟悉，其是文本格式，简单易懂。
每一行的基本语义为 "文件:起始行.起始列,结束行.结束列 该基本块中的语句数量 该基本块被执行到的次数"
cov-example/p/p.go新提案在这个方向上做了不少文章，实现细节上稍显复杂，但方向较为清晰。
通过分析旧版的每一行能看出，本质上每一行会记录两类信息，一是定位每个基本块的具体物理位置，二是记录这个基本块的语句数量和被执行的次数。虽然执行的次数会变化，但是其他的信息是不变的，所以全局上其实只要记录一份这样的信息就好，而这就能大大的优化空间，
所以，新版覆盖率它实际会实际输出两份文件，一份就是meta-data信息，用于定位这个被测程序所有包、方法等元信息，另一份才是counters，类似下面:
covdatatmp真 • 全量覆盖率
一个标准的go程序，基本上由三种类型的代码包组成:
- 自身代码
- 第三方包，通过mod或者vendor机制引用
- go标准库
在过去，几乎所有的工具都只关注业务自身代码的插桩，鲜少关注第三方包，更别说go官方标准库了。这在大部分场景下是没问题的，但有时有些场景也有例外，比如SDK相关的项目。因为这时候SDK会作为Dependency引入，要想对其插桩就需要额外的开发量。还比如一些CLI程序，执行完命令之后，立马就结束了，也是非常不利于覆盖率收集的。
这些问题都是很现实的，且我们在goc项目中也收到过真实的用户反馈:
不过，现在好了，新版覆盖率方案也有实际考虑到这些需求，它实际会做到 支持全量插桩+程序退出时主动输出覆盖率结果 的原生方式，非常值得期待。
更多覆盖率使用场景支持: 合并(merge)、删减(subtract)、交集(intersect)
在实际处理覆盖率结果时，有很多实用的场景，在新提案中也有提及，比如支持:
go tool covdata merge -i=-o= go tool covdata subtract -i=dir1,dir2 -o=go tool covdata intersect -i=dir1,dir2 -o=
在过去，这些场景都需要依赖第三方工具才行，而在新方案中已经无限接近开箱即用了。
不过更复杂的场景，类似远程获得覆盖率结果等(类似goc支持的场景)，看起来新方案并没有原生支持。这个问题，笔者也在issue 讨论中提出，看看作者是否后续有解答。
展望与不足
go test -covertest "origin" queriesIntra-line coverageFunction-level coverageTaking into account panic paths