go get @commit 会生成伪版本而非直接锁定 commit，格式为 v0.0.0-yearmonthday-hourminutesecond-commithash，用于满足 semver 排序要求；同一 commit 在不同机器生成的伪版本时间戳可能不同，但内容由 hash 确保一致。
go get @commit 会生成伪版本，不是直接锁定 commit
直接运行 go get github.com/you/repo@abc123 看似拉取了指定 commit，但实际写入 go.mod 的是一条伪版本（如 v0.0.0-20240315112233-abc123def456），而非原始 commit hash。这是 Go 的设计行为——它必须用可排序、符合 SemVer 格式的字符串记录依赖，所以把 commit 时间戳和 hash 组合成伪版本。
这意味着：同一 commit 在不同时区或不同机器上生成的伪版本可能略有差异（时间戳精度到秒），但只要 hash 一致，内容就确定。不过要注意，如果该 commit 后来被 force push 覆盖，Go 不会自动检测，go.sum 仍会校验旧 hash，导致 checksum mismatch。
- 伪版本格式固定为
v0.0.0-YEARMONTHDAY-HOURMINUTESECOND-COMMITHASH（前缀v0.0.0-不可省略） - 不能手动编辑
go.mod中的伪版本字符串去“简化”它，Go 会拒绝解析非标准格式 - 若想复现构建，必须确保
go.sum未被污染，且本地模块缓存未混入其他 commit 的同名伪版本
replace 替换本地目录时，目标必须含有效 go.mod
用 replace github.com/you/utils => ../utils 做本地调试很常见，但容易卡在“找不到包”或“go build 报错 module declares its path as … but was required …”——根本原因通常是 ../utils 目录下没有 go.mod，或其 module 指令与 replace 左侧不匹配。
比如你 replace 的是 github.com/you/utils，那 ../utils/go.mod 第一行必须是 module github.com/you/utils，不能是 module utils 或 module my-utils。否则 Go 会拒绝加载，认为路径不一致。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
-
replace路径必须是相对路径（相对于当前go.mod所在目录）或绝对路径，不能用~/开头 - 被替换目录若无
go.mod，Go 会退化为 legacy mode 解析，可能漏掉子模块或误读 import 路径 -
replace只影响当前模块，下游依赖不会继承该替换；若需传播，得让下游也加同样 replace
私有仓库拉取指定 commit 需先解决认证和 URL 映射
对 git@gitlab.internal/company/lib 这类私有地址，go get gitlab.internal/company/lib@deadbeef 很可能报 unknown revision 或 invalid version。这不是 commit 不存在，而是 Go 默认只尝试 HTTPS 协议，且不走 SSH 认证流程。
必须两步配合：一是用 git config --global url."ssh://git@gitlab.internal/".insteadOf "https://gitlab.internal/" 告诉 Git 把 HTTPS 请求转成 SSH；二是用 go mod edit -replace=gitlab.internal/company/lib=git@gitlab.internal:company/lib.git 显式映射模块路径到 SSH 地址。缺一不可。
- 若用 HTTPS + token 认证，需配置
git config --global credential.helper store并提前git clone一次触发凭据保存 -
GOPRIVATE=gitlab.internal必须设置，否则 Go 代理（GOPROXY）会尝试走公网镜像，跳过你的私有源 - commit hash 必须存在于目标仓库的可见分支中（如
main或dev），不能只在本地分支
go.sum 频繁变动往往源于未打 tag 的分支依赖
当你频繁使用 @master 或 @main 拉依赖，go.sum 几乎每次 go mod tidy 都会变——因为 master 的 latest commit 在变，Go 自动生成的伪版本也跟着变。这会导致 CI 构建失败、PR diff 巨大、团队成员间 go.sum 冲突。
真正稳定的依赖粒度只有两种：带语义化 tag 的版本（如 @v1.4.2），或明确 commit hash（@abc123）。前者靠人工打 tag 控制，后者靠哈希值保证内容唯一。混用分支名是最容易埋雷的做法。
- CI 流水线中应禁止
go get ...@master类命令，改用 pinned commit 或 tag - 若必须用分支开发，建议在分支上打临时 tag（如
v0.0.0-dev-20260804），再go get @v0.0.0-dev-20260804 -
go clean -modcache有时能解决因缓存污染导致的伪版本错乱，但治标不治本；根源还是依赖来源不够确定
go.sum 对未打 tag 提交的敏感性，这三处最容易在交接或 CI 环境中突然暴露问题。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
