文章指出go.sum并非锁文件，对依赖版本解析无任何语义影响，仅作为Go校验和数据库的本地缓存，记录模块版本及其哈希值。其核心作用是确保模块内容安全一致，而非依赖管理。实际依赖版本应查看go.mod文件。

标题：go.sum并非锁文件

核心内容： 1. go.sum文件本质上是Go校验和数据库的本地缓存，仅用于存储模块版本与其加密哈希值的映射关系。它不参与版本解析，对构建过程没有语义影响，不应被用作依赖关系分析。

2. Go模块系统的正确依赖信息应通过go.mod文件获取。该文件自Go 1.17起会明确列出构建主模块及其测试所需的所有直接和间接依赖的确切版本。

技术细节： - go.sum的设计初衷是增强安全性，通过校验和数据库确保模块内容的全局一致性 - 开发者可通过golang.org/x/mod/modfile解析、go mod edit -json命令或直接阅读规范来获取依赖信息 - Go模块采用最小版本选择原则，不同主版本被视为独立模块，有效避免了依赖冲突

对比其他语言： - 传统包管理系统通常包含清单文件（如package.json）和锁文件（如package-lock.json） - Go通过单一go.mod文件实现双重功能，简化了依赖管理流程 - 独特的版本选择机制避免了"依赖钻石"问题，且不会自动引入未经测试的最新依赖

作者评价： - 认为Go模块系统的简洁性被严重低估 - 指出其他生态系统需要复杂版本解析，而Go的依赖解析过程几乎不可感知 - 强调-mod标志的两种模式（mod/readonly）为依赖管理提供了灵活性

注：原文中关于会议见闻、赞助商信息等与主题无关的内容已作删减处理。

总结评论内容：

1. 关于go.sum的作用：

• 支持观点：go.sum能防止上游模块被修改或破坏时导致构建失败 "if a module is later modified or compromised upstream, the checksum in go.sum will cause the build to fail" (anishgupta)
• 反对观点：默认的GitHub Action仍在使用go.sum而非更优方案 "the default actions/setup-go github action still uses go.sum" (peterldowns)

2. 关于依赖解析问题：

• 指出间接依赖会影响构建版本 "it does affect your dependency resolution...AWS/K8S/Google Cloud libraries cause MASSIVE problems" (Groxx)
• 说明go.mod只提供最低版本而非精确版本 "it lists the precise version...No, it does not" (djha-skin)

3. 关于锁文件的理解：

• 认为go.sum实质上是锁文件 "A lock file...contains a cryptographic hash...go.mod does not" (wereHamster)
• 详细解释不同语言的版本管理差异 "Python packages...do not follow semantic versioning...lock files are necessary" (markkitti)

4. 其他观点：

• 对现有问题表示惊讶 "I am today years old to find this..." (virajk_31)

主要争议点集中在go.sum的实际作用、Go语言的依赖管理机制，以及与其他语言包管理方式的对比。多数评论认为当前的依赖管理存在改进空间，特别是对间接依赖的处理和版本控制方面。