modfile.Parse 仅解析 go.mod 结构而不做 AST 分析，返回可修改结构体；支持 module/require/replace 等块及多行、indirect 注释，但不校验路径、不解析版本语义、不展开 indirect；需手动 Format() 才能生成兼容格式，WriteFile 会破坏原有注释布局，且不支持 go.work。
modfile.Parse 会忽略注释但保留格式，别指望它做 AST 分析
直接用 modfile.Parse 读取 go.mod 文件，它返回的是一个可修改的结构体，不是语法树。它能识别 module、require、replace 等块，也能处理多行 require 和带 // indirect 的行，但不会解析版本号语义、不校验模块路径合法性，也不展开 indirect 依赖关系。
常见错误现象：modfile.Parse 成功返回后，调用 f.AddRequire("x", "v1.2.3") 却没写入文件——因为没调用 f.Format() 或 WriteFile。
- 必须手动调用
f.Format()才能生成符合 go tool 兼容的格式（比如缩进、空行、注释位置） - 如果只读不改，
f.Require字段是原始声明的切片，顺序和文件一致；但添加/删除后顺序可能变化，不要依赖下标索引 -
replace和exclude块也得单独处理，f.Require里不包含它们
require 行的 version 字段可能是 pseudo-version，别当成 semver 解析
modfile.Require 结构里的 Version 字段，值可能是 v1.2.3，也可能是 v1.2.3-0.20220101010101-abcdef123456 这种 pseudo-version。Go 工具链用它标记未打 tag 的提交，但 golang.org/x/mod/modfile 不做任何转换或校验。
使用场景：你想提取所有直接依赖的稳定版本号？不能简单截断或正则匹配 - 前部分——有些模块本身就带连字符（如 cloud.google.com/go/storage 的版本 v1.29.0 是合法的，但 v1.29.0+incompatible 也是可能的）。
立即学习“go语言免费学习笔记（深入）”；
- 判断是否为 pseudo-version：用
semver.IsValid(r.Version)（需引入golang.org/x/mod/semver） - 提取基础版本前缀（如
v1.2.3）可用semver.Canonical(r.Version)，但它对 pseudo-version 返回空字符串 - 真正安全的做法是：只对
semver.IsValid()为 true 的值做解析，其余视为不可解析的字符串
WriteFile 可能破坏原有注释布局，生产环境慎用原地覆盖
modfile.WriteFile(path, f) 会重写整个文件，虽然保留了大部分注释，但会归一化空行、缩进，并把所有 require 合并到一块，打乱你原来按功能分组写的注释区块（比如 “// infra deps”、“// test-only”）。
容易踩的坑：go mod tidy 之后再用 WriteFile 覆盖，会导致后续 diff 出现大量无关变更，CI 检查或人工 review 容易漏掉真实修改。
- 若只需读取信息，完全不用写回——
Parse本身不改变磁盘 - 若必须写入，建议先备份原文件，再用
WriteFile输出到临时路径，用diff -u对比确认变更合理 - 避免在
go.mod正被其他进程（如go build、IDE）读取时覆盖，Linux 下可能触发text file busy错误
golang.org/x/mod/modfile 不支持 go.work 解析，别混用工作区场景
这个包只处理单个 go.mod 文件，对 go.work 文件完全无感知。如果你在工作区（workspace）模式下开发，go list -m all 看到的模块图和 modfile.Parse("go.mod") 解出的内容很可能不一致——因为 replace 可能来自 go.work，而 modfile 根本读不到。
性能影响：没有额外开销，但逻辑上会漏信息。你以为加了 replace 就生效了，其实它在 go.work 里，modfile 解析结果里压根没这条记录。
- 检查当前是否在 workspace：看是否存在
go.work文件，且GOWORK环境变量未设为off - 需要完整模块图？别依赖
modfile，改用go list -m -json all或go mod graph的输出解析 - 工具链层面，
golang.org/x/mod的其他子包（如modload）才支持 workspace，但它们是内部 API，不稳定，不建议直接用
真正难的不是读取字段，而是搞清你手里的 go.mod 在当前构建上下文中到底起不起作用。
