go 允许将测试文件放在独立子目录（如 `test/`）中，但需调整包声明和导入方式，并确保被测函数导出；否则会因作用域限制导致“undefined”错误。
在 Go 中，默认推荐将测试文件（如 module1_test.go）与被测源码（如 module1.go）置于同一目录、同名包下，这样测试可直接访问包内所有标识符（包括未导出函数）。但当项目规模扩大时，混放测试与生产代码确实影响可维护性。此时，你可以将测试移至子目录（例如 test/），但必须遵守 Go 的包隔离规则。
✅ 正确做法：测试作为独立包 + 显式导入
将测试文件放入 test/ 子目录后，它不再属于原包，而应声明为独立包（如 package test），并通过 import 引入被测包：
? 目录结构：
package1/
├── module1.go # 生产代码
└── test/
└── module1_test.go # 测试代码✅ module1.go（需导出函数供外部调用）：
package package1
// 注意：首字母大写，导出函数
func SomeFunc() {
// 实现逻辑
}✅ test/module1_test.go（独立包，显式导入）：
package test
import (
"testing"
"your-module-path/package1" // 替换为实际模块路径，如 github.com/you/repo/package1
)
func TestSomeFunc(t *testing.T) {
package1.SomeFunc() // 通过包名调用
}? 关键点： 测试文件不能再声明 package package1，否则会与主包冲突； 必须使用 导出名（如 SomeFunc 而非 someFunc），因为跨包无法访问未导出标识符； import 路径必须是模块的完整导入路径（即 go.mod 中定义的 module path + 子路径），而非相对路径。
⚠️ 注意事项与权衡
- 无法测试未导出函数/变量：子目录测试无法访问 package1 内部未导出成员（如 func helper()），这是 Go 包封装机制的强制约束；
- IDE 和工具链兼容性：部分 IDE（如 VS Code + gopls）或 go test ./... 仍能自动发现子目录测试，但需确保 test/ 不被 go build 误包含（建议在 test/ 下添加空 +build ignore 文件或避免 go build ./... 递归构建测试目录）；
- 社区惯例：绝大多数 Go 项目仍采用同目录 _test.go 方式——因其简洁、零配置、支持内部测试（如 TestHelper 可直接调用 helper()），也更利于 go test -cover 等工具统计。
✅ 推荐替代方案：按功能分组，而非物理分离
若目标是提升可读性，更符合 Go 习惯的做法是：
- 保持测试与源码同目录；
- 使用清晰命名区分：user.go / user_test.go / user_integration_test.go；
- 对大型模块，按领域拆分子包：package1/user/, package1/order/, 各自含 *_test.go。
总之，技术上可行 ≠ 实践推荐。除非有强约束（如 CI 要求测试完全隔离），否则优先遵循 Go 社区约定：测试即包的一部分，共存于源码目录。
