goland中判断go项目是否适合模块化重构，先看是否有go.mod；若仅有根目录一个且import路径全为github.com/xxx/yyy，则结构仍扁平；真正适合的信号包括internal/包混杂、main.go初始化超200行、单元测试因全局函数依赖无法运行、go list路径杂乱等。
GoLand里怎么判断一个Go项目是否适合模块化重构
先看它有没有 go.mod，没有就基本是GOPATH遗留项目；有但只在根目录一个，且所有包都用 import "github.com/xxx/yyy" 这种路径引用——说明它名义上用了modules，但结构还是扁平的。真正适合推演重构的项目，通常已出现这些信号：
• internal/ 目录下塞了几十个混用的包，handler 里直接 new db.Conn
• main.go 里初始化逻辑超过200行，包含日志、DB、缓存、gRPC client等硬编码
• 单元测试跑不起来，因为 service 层强依赖 config.Load() 这类全局函数
• go list -f '{{.Dir}}' ./... 输出路径杂乱，比如 ./storage/mysql 和 ./pkg/storage 并存
用GoLand做架构推演时，哪些重构操作能提前暴露耦合问题
别急着重命名或移动文件，先做三件事：
• 在任意 handler 函数里按 Ctrl+Click 跳转到它调用的 service 方法，再跳转到该方法里调用的 repository —— 如果中间出现 import "github.com/xxx/legacy" 这种非标准路径，说明跨模块引用失控
• 右键点击 main.go → 重构 | 提取接口，尝试为业务逻辑层抽一个 UserService 接口——如果GoLand提示“无法提取：存在未导出字段或闭包捕获”，说明结构太紧，得先拆函数
• 打开 分析 | 检查代码，勾选 Go | Unused parameter 和 Go | Unexported field in exported struct —— 这些警告往往指向隐式依赖，比如一个导出结构体里藏着 db *sql.DB 字段
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
移动包（Move Package）时最常踩的坑是什么
GoLand的 重构 | 移动 看似安全，但在遗留项目里极易触发导入路径断裂：
• 不要直接拖拽整个 pkg/user 文件夹到 service/user —— 先确认目标路径下已有 go.mod，且模块名匹配（比如 module myproject/service/user）
• 移动前检查所有调用方是否用了相对导入，比如 import "./pkg/user"，这种写法在modules下会直接报错 cannot find module providing package
• 如果被移动的包里定义了 func NewClient() *http.Client 这类全局构造器，GoLand不会自动改调用处的 user.NewClient() 为 serviceuser.NewClient()，得手动批量替换
• 移动后立刻运行 go build ./...，而不是只靠IDE的绿色对勾——GoLand有时会缓存旧导入路径，构建失败才是真实状态
重构过程中如何避免测试突然全挂
遗留项目的测试往往和生产代码共用全局变量，重构时最容易崩：
• 在 go test 命令后加 -gcflags="-l" 参数，强制禁用内联，能更快暴露因函数签名变更导致的 panic
• 把所有 TestXXX 函数开头的 initDB() 替换为 testDB := setupTestDB(t)，确保每个测试用独立实例
• 如果测试里用了 os.Setenv("CONFIG_PATH", "...")，重构后记得在 defer os.Unsetenv("CONFIG_PATH") —— 否则后续测试可能读到脏环境
• GoLand的 运行 | 重新运行测试 默认复用上次参数，务必检查右下角是否显示 go test -timeout=30s ./...，而不是某个过期的子包路径
panic: runtime error: invalid memory address，得靠 go tool trace 逐帧回溯。
