go mod edit -replace 不生效是因为本地路径缺少 go.mod 或 module 声明不匹配原依赖（含大小写和版本后缀），且未执行 go mod tidy；需确保在主模块根目录操作，并配合 require 和 -a 强制重编译验证。
为什么 go mod edit -replace 不生效？
直接写 go mod edit -replace github.com/example/lib=../local-fix 后 go build 仍拉远程包，通常是因为模块路径不匹配或本地目录未包含 go.mod。Go 要求被替换的本地路径必须是一个合法模块（即含 go.mod 文件），且其 module 声明必须与原依赖完全一致（包括大小写、版本后缀）。如果本地库是 fork 后改名的，比如原模块是 github.com/oldorg/lib/v2，而你本地写成 github.com/you/lib，-replace 就会静默失效。
- 确认本地路径下存在
go.mod，且第一行module声明和原始依赖路径一字不差（含/v2等版本后缀） - 执行
go mod edit -replace后务必运行go mod tidy，否则 replace 可能未写入go.sum或未触发依赖重解析 - 避免在子目录中执行命令——
go mod edit必须在主模块根目录下运行
如何用 replace + require 保证补丁被构建进二进制？
replace 只影响构建时解析路径，不改变 import 路径；但若补丁涉及 API 变更（如新增方法、修改签名），仅靠 replace 不够，还必须让 Go 工具链“感知”到这个依赖已被修改并需要重新计算依赖图。这时候需配合显式 require 声明（尤其当原依赖是间接依赖时）。
- 先用
go list -m all | grep example/lib查看当前解析出的实际模块路径和版本 - 如果该包出现在
indirect行，说明它没被主模块直接 import，此时replace可能被忽略——应加一行require github.com/example/lib v0.0.0-00010101000000-000000000000（版本可填任意伪版本，只要非空） - 再执行
go mod tidy，它会把require行标准化，并将replace绑定到该伪版本上
本地补丁调试时为何 go run main.go 没用上修改？
常见现象：改了本地库代码，go run main.go 却还是旧行为。根本原因在于 Go 的构建缓存（$GOCACHE）会复用已编译的 .a 归档，而 replace 不自动触发缓存失效。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 每次改完本地库，必须加
-a参数强制重编译：go run -a main.go - 或者清空对应模块缓存：
go clean -modcache（注意这会清掉所有模块缓存，较重） - 验证是否生效：在本地库中临时加一句
fmt.Println("patch loaded")，确保它被打印出来 - 检查
go list -m -f '{{.Dir}}' github.com/example/lib输出路径，确认指向的是你的本地目录而非$GOPATH/pkg/mod
补丁提交前如何验证兼容性？
本地跑通不等于上线安全。补丁若改动导出符号（函数、字段、接口），可能破坏下游依赖；若修改 go.mod 中的 require，还可能引发 diamond dependency 冲突。
- 在补丁库目录下运行
go test ./...，确保自身测试全部通过 - 回到主项目，用
go list -deps -f '{{if .Indirect}}{{.Path}} {{.Version}}{{end}}' ./... | grep example/lib查是否有其他模块也依赖它——若有，补丁需向后兼容 - 临时删掉
replace行，改用require github.com/example/lib vX.Y.Z+go get拉最新 tag，对比行为差异
补丁真正落地前，最易被忽略的是 go.sum 校验和更新——go mod tidy 必须成功完成且无 error，否则 CI 构建会失败。别跳过这一步。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
