Go Package.Complete 为 true 是否表示源码没有类型错误

不能把任意来源的 Package.Complete()==true 当作“当前源码没有类型错误”的证明。它表达包作用域至少具备全部导出对象的完整状态；判断本轮源码是否检查成功，应读取 Config.Check 的错误返回值，并保留相关诊断和输入配置。

这里需要区分一个具体保证：按官方文档，Config.Check 在没有错误时将返回包标为 complete，有错误时则不完整。但 Complete 也能由调用方通过 MarkComplete 设置，因此离开这个调用来源，布尔值本身不能证明发生过哪次源码检查。

官方文档：https://pkg.go.dev/go/types#Package.Complete；检查入口：https://pkg.go.dev/go/types#Config.Check。

先明确 Complete 承诺的范围

如果给源码分析接口设计一个 success 字段，直接把 Complete 填进去会混淆两个需求：下游是否能使用包的导出对象信息，以及指定源码输入是否通过类型检查。前者关注包元数据，后者关注一次有输入、有配置、有错误结果的分析操作。

包对象可以来自源码检查，也可以来自导出数据或手工构造。加载依赖的导出信息，并不意味着当前工作区里每一个文件的函数体都被重新检查。API 调用方应保留来源，而不是让一个状态标记承担全部质量判断。

用显式标记说明它没有检查源码

下面的完整原创示例先构造一个包并显式设置标记，再单独检查一份故意含类型错误的源码。这两部分属于不同对象，目的是说明“设置标记”和“检查源码”是不同动作。示例没有在本文执行，不作为运行证据。

package main

import (
 "fmt"
 "go/ast"
 "go/parser"
 "go/token"
 "go/types"
)

func main() {
 // 这个包只由调用方构造，尚未解析或检查任何源码。
 metadata := types.NewPackage("example.com/meta", "meta")
 fmt.Println("初始标记：", metadata.Complete())
 metadata.MarkComplete()
 fmt.Println("手动标记：", metadata.Complete())

 // 故意保留一个类型不匹配，用于说明错误必须由 Check 返回值处理。
 const source = "package sample\nvar Count int = \"wrong\"\n"
 fset := token.NewFileSet()
 file, err := parser.ParseFile(fset, "sample.go", source, 0)
 if err != nil {
  fmt.Println("解析失败：", err)
  return
 }
 var diagnostics []error
 conf := &types.Config{
  Error: func(err error) {
   // 记录诊断，回调不等于把检查错误消除。
   diagnostics = append(diagnostics, err)
  },
 }
 pkg, checkErr := conf.Check("example.com/sample", fset, []*ast.File{file}, nil)
 if checkErr != nil {
  fmt.Println("本轮源码检查失败：", checkErr)
  fmt.Println("已记录诊断数：", len(diagnostics))
  return
 }
 // 只有 Check 成功后，才把本轮输入标为类型检查通过。
 fmt.Println("本轮输入类型检查成功")
 if pkg != nil {
  fmt.Println("包元数据完整标记：", pkg.Complete())
 }
}

MarkComplete 只标记包完整，不读取 source、不分析函数体，也不会修复类型不匹配。示例对手工包调用该方法仅用于说明接口边界，不是建议给错误包补标记。对真实导入器而言，设置完整状态需要遵循其构造包信息的契约。

后半部分将字符串赋给 int 变量，属于类型不匹配。Error 回调收集诊断并允许检查器继续报告，不会把错误变成成功；Check 仍会返回遇到的第一个错误。使用回调时，必须继续处理这个返回值。

调用方应该保存独立的检查结果

更清楚的接口是独立保存包对象、检查错误、诊断列表和输入上下文。调用方需要严格成功时，以本轮 Check 无错误为基本条件；需要错误容忍的编辑器功能时，可以在错误状态下展示可用的部分信息，但要明确它不是完整成功结果。

不能用“没有读取到诊断”替代成功判断：可能没有安装回调、丢弃了错误，或压根没有运行检查。也不要在缓存命中时只返回 Complete，而省略缓存针对的文件、依赖和目标配置；源码变化后，旧包对象不能自动代表新内容。

区分成功检查与整个项目可构建

即使本轮 Check 返回 nil，也只能在给定 AST 与配置的范围内解释结果。如果启用了 IgnoreFuncBodies，函数体并不在同样的检查范围内。漏掉文件、错误筛选构建标签或使用不匹配的导入数据，也会改变这次输入所代表的工程范围。

类型检查成功不等于整个项目构建、链接或运行成功，更不表示测试通过。这里无需给 Complete 添加新的含义，只要在报告里写清楚“解析状态、类型检查状态、输入范围”即可。文章讨论的是接口职责，不引入其他执行阶段。

常见问题：NewPackage 默认 complete 吗？默认不完整。能否对出错包调用 MarkComplete 消除错误？不能，该方法不修复源码也不撤销诊断。只使用导入包类型信息时能读 Complete 吗？可以，用于理解包元数据状态，但不要将它转述为当前工作区全量源码检查成功。