Go 1.11+ 默认启用 Go Modules，项目可脱离 GOPATH 任意路径存放；FC 场景下每个函数为独立部署单元，模块化天然适配扁平结构，避免 GOPATH 导致的混包冲突、路径忽略及本地线上行为不一致问题。
直接用 go 二进制安装 + go mod 管理依赖，不配 GOPATH，不建传统工作区，就能跑通函数计算（FC）的本地开发和部署流程。
为什么不用 GOPATH 模式
函数计算场景下，每个函数是独立部署单元，项目结构扁平、无跨包复用需求。硬套 GOPATH 会导致：
-
go get默认往$GOPATH/src写第三方包，但 FC 打包只认当前目录及子目录，外部路径会被忽略 - 多个函数共用一个
GOPATH容易混包，版本冲突难排查 - FC 的构建环境（如阿里云 FC 的 build image）默认不设
GOPATH，本地行为和线上不一致
Go 1.11+ 的模块模式（go mod）天然适配这种“单函数即项目”的模型。
go mod init 要指定模块名，不是随便起
模块名会参与编译时的包导入路径解析，FC 运行时加载 main 函数依赖它。错误示例：go mod init myfunc → 如果代码里写 import "github.com/xxx/utils"，而实际没这个远程路径，就会编译失败。
立即学习“go语言免费学习笔记（深入）”；
推荐做法：
- 模块名用占位符，比如
go mod init example.com/fn，只要保证本地所有import都能按相对路径解析通即可 - 避免用真实域名或 GitHub 路径，除非你真打算开源并发布到对应仓库
- 模块名一旦生成，不要轻易改；否则已
go mod vendor或缓存的依赖可能失效
FC 要求的 main 函数签名和入口文件位置
阿里云 FC、腾讯云 SCF 等主流平台都要求 Go 函数必须提供标准 main 入口，且必须在 main.go 文件中，不能拆成 main.go + handler.go 后再 import —— 因为打包工具只扫描 main.go 找 func main()。
典型结构：
./ ├── go.mod ├── go.sum ├── main.go // 必须存在，且含 func main() └── handler.go // 可以有，但必须被 main.go 显式 import
常见错误：
- 把 handler 逻辑全写在
main.go里，导致文件臃肿、无法单元测试 - 用
go run .能跑，但go build -o bootstrap main.go失败，原因是没把handler.go加进编译列表 - FC 控制台提示
failed to find handler：其实是main.go里没调用真正的 handler，或者fmt.Println后没os.Exit(0)导致进程卡住
本地调试与线上行为一致的关键点
函数计算运行时（如 aliyunfc/runtime-go1.x）是精简 Linux 环境，没有 $HOME、不加载 shell profile、LD_LIBRARY_PATH 为空。本地模拟时容易忽略：
- 用
CGO_ENABLED=0 go build编译，避免动态链接 libc 导致线上找不到 so - 不要依赖
/tmp以外的临时路径，FC 只挂载了/tmp为可写 - 配置项（如数据库地址）别硬编码在
main.go，用os.Getenv("DB_HOST")，然后在 FC 控制台或template.yml里注入 -
go test可以跑，但注意testing.TB的Log不会输出到 FC 日志系统，要用fmt.Fprintln(os.Stderr, ...)或标准日志库
最常被跳过的细节：FC 的 Go 运行时启动后会先执行 main.init()，再等 HTTP 请求或事件触发 handler。如果 init 里做了阻塞操作（比如同步连 Redis），函数就永远起不来。
