能剥离，但必须先确认是否被其他模块隐式依赖——通过 go list -deps、init() 函数、空导入、配置文件、go mod why 等多维度验证；剥离前需抽离 contract、replace 临时兼容、编写最小验证脚本；删后须检查测试、embed 资源、build tag 及反射依赖，并设 deprecated.md 和 ci 拦截。
能剥离，但必须先确认它是否已被其他模块隐式依赖——直接删 go.mod 或目录，90% 会触发构建失败或运行时 panic。
怎么判断一个模块是不是真边缘
边缘不等于“没人改”，而是“没被其他模块 import、没注册全局副作用、没被反射或配置加载”。别只看 Git 提交记录。
- 运行
go list -deps ./... | grep 'your-module-name'，如果无输出，说明没有显式依赖 - 检查是否有
init()函数：在模块根目录搜func init()，尤其注意日志钩子、HTTP handler 注册、DB 驱动_空导入（如import _ "github.com/lib/pq"） - 查配置驱动场景：grep 项目里所有
.yaml/.toml文件，看有没有模块名或包路径作为字符串出现（比如adapter: "user_gorm"） - 运行
go mod why -m your-module-name；若返回main module does not need module，才初步可信
剥离前必须做的三件事
跳过任何一步，后续都会卡在 CI 或某个凌晨三点的部署失败上。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 把模块内所有对外暴露的类型（
struct、interface、func）抽成独立的contract包，路径类似example.com/project/contract/user，并用replace指向本地目录 - 在主
go.mod中加replace your-module => ./path/to/module，确保其他模块还能编译通过——不是为了长期保留，而是争取迁移窗口期 - 写一个最小验证脚本：
main.go里只 import 该模块 + 调用一个空函数，然后go build -o /dev/null .，确认它仍能链接；再删掉 import，确认构建不报错
删模块时最常踩的坑
删完目录或 go.mod 后，你以为结束了，其实只是问题刚浮出水面。
-
go mod tidy不会帮你发现测试文件里的残留 import：跑go test -v ./... -run=^Test.*$，看是否 panic 或 missing package - 模块里若有
//go:embed资源（如 SQL 文件、模板），删包后这些路径会变成 dangling reference，go build不报错，但运行时io/fs.ReadFile直接 panic - CI 构建环境可能启用了不同
//go:buildtag，导致某些_导入只在特定平台生效——本地go mod tidy没删，CI 却报错找不到包 - 别信
go list -f '{{.Deps}}' ./old-module的输出：它只显示静态 import，不反映reflect.Value.MethodByName或json.Unmarshal对 struct 字段的隐式依赖
真正难的不是删代码，是确认「删了之后，没人会在某个分支上悄悄加回一行 import」。建议在模块目录里留一个 DEPRECATED.md，并在 CI 的 pre-commit hook 里加一条检查：禁止新提交往该路径下写 import 行。否则，三个月后它又会从 git blame 里幽灵般复活。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
