在 go 项目中测试含 cgo（即 import "c"）的代码时，因 go test 默认禁用 cgo，需将 c 互操作逻辑移至非测试文件，并通过纯 go 封装函数进行单元测试。

Go 的 go test 工具默认禁用 CGO 支持（即不设置 CGO_ENABLED=1），因此直接在 _test.go 文件中使用 import "C" 会导致编译失败：“import "C" is unsupported in test files”。这不是限制，而是设计使然——Go 要求测试文件保持可移植、可复现，而 CGO 引入平台依赖和外部构建链。

✅ 正确实践是职责分离：

• 将所有含 import "C" 的代码（包括 C 函数声明、类型定义、// #include 等）严格放在 非测试文件（如 cbridge.go 或 interop.go）中；
• 在该文件中，用私有 Go 函数封装 C 调用，隐藏底层细节；
• 测试文件（如 cbridge_test.go）仅导入并调用这些封装函数，无需接触 C. 命名空间。

示例结构：

// cbridge.go
package mypkg

/*
#include 
#include 
*/
import "C"
import "unsafe"

// Exported wrapper — safe, Go-idiomatic, testable
func ComputeLength(s string) int {
    cs := C.CString(s)
    defer C.free(unsafe.Pointer(cs))
    return int(C.strlen(cs))
}

// cbridge_test.go
package mypkg

import "testing"

func TestComputeLength(t *testing.T) {
    tests := []struct {
        input    string
        expected int
    }{
        {"hello", 5},
        {"", 0},
        {"Go+CGO", 6},
    }
    for _, tt := range tests {
        if got := ComputeLength(tt.input); got != tt.expected {
            t.Errorf("ComputeLength(%q) = %d, want %d", tt.input, got, tt.expected)
        }
    }
}

⚠️ 注意事项：

• 不要在测试文件中写 import "C" — 即使加了 //go:cgo_import_dynamic 也无效；
• 若需测试 C 逻辑本身（如内存安全、边界行为），应使用 C 单元测试框架（如 CMocka），而非 Go 测试；
• 确保 CGO_ENABLED=1 仅在构建/运行阶段启用（go build 和 go run 默认启用，go test 默认禁用，但可通过 CGO_ENABLED=1 go test 强制启用——不推荐，因破坏可重现性与跨平台一致性）；
• 封装函数应处理 C 资源生命周期（如 C.free、C.CString 配对），避免内存泄漏或 use-after-free。

总结：CGO 不是测试的障碍，而是提醒我们践行“关注点分离”——让 C 承担性能敏感或系统交互职责，让 Go 承担逻辑组织与可测试性职责。通过轻量封装，你既能享受 C 的能力，又能获得 Go 测试生态的全部优势。