FIPS 140-3 这个话题，平时写业务代码很少主动碰，但一旦碰到，通常就不是“代码能不能跑”的问题，而是“这套服务能不能进合规环境”。我最近看 Go 官方 FIPS 文档时最大的感受是：Go 把开关做得越来越顺手了，但上线时最容易翻车的，反而是团队把它当成普通环境变量。
这篇我按真实项目的视角来写：先判断你到底需不需要 FIPS，再讲 GOFIPS140 和 GODEBUG=fips140 各管什么，最后给一份我会放进 CI 和发布流程里的检查清单。别急着复制命令，先把边界看清楚。
先说人话：什么时候你才需要 FIPS
如果你的 Go 服务只是普通互联网业务，FIPS 140-3 大概率不是性能优化方案，也不是安全银弹。它更像一套合规约束：金融、政企、医疗、跨境合规、供应链审计这类环境，会要求你证明加密模块、算法选择、构建来源和运行模式都在受控范围里。
所以第一步不是打开 GOFIPS140，而是问清楚三个问题：客户或监管要求的是哪一个模块版本？服务运行在哪些操作系统和镜像里？TLS、随机数、签名、密钥交换这些路径是不是都走 Go 标准库？如果答案还没梳理好，直接上线 FIPS 模式，后面查问题会很难受。
GOFIPS140 管构建，GODEBUG 管运行
Go 官方博客里说得很直白：Go 1.24 开始，Go 自带原生 FIPS 140-3 支持。这里有两个经常被混在一起的点：GOFIPS140 更偏构建选择，用来让程序构建到指定的 Go Cryptographic Module 快照；GODEBUG=fips140=on 更偏运行模式，用来让二进制启动时进入 FIPS 140-3 模式。
我在团队里一般会这样解释：GOFIPS140 像是“这辆车装哪套合规模块”，GODEBUG=fips140 像是“上路时按不按合规驾驶模式”。你只在本地 export 一下环境变量，不代表生产镜像、CI 构建机、灰度容器和回滚版本都一致。
# 构建时绑定一个明确的 FIPS 模块版本 GOFIPS140=v1.0.0 go build -trimpath -o bin/api ./cmd/api # 运行时启用 FIPS 140-3 模式 GODEBUG=fips140=on ./bin/api # 更严格的验证场景，可以在测试环境检查非批准用法 GODEBUG=fips140=only go test ./...
我会把它做成发布流程，而不是临时命令
合规项目最怕“某次发布刚好没带那个变量”。所以我更推荐把 FIPS 构建做成独立 target，比如 make build-fips、独立 Dockerfile stage、独立 CI job。这样普通构建和合规构建不会互相污染，审计时也能明确拿到产物、参数和日志。
还有一个细节别省：构建完成后用 go version -m 或对应版本文档提供的方法检查二进制元信息，确认产物里确实带上了你期望的 FIPS 模块设置。很多线上事故不是不知道怎么配，而是没人验证“最终发布出去的那个文件”到底是什么。
TLS 和算法限制，要提前在测试环境炸一次
进入 FIPS 模式后，Go 的加密库会按 FIPS 140-3 要求工作，TLS 版本和算法也会受到限制。听起来是好事，但如果你的老系统还在依赖旧 cipher suite、历史证书链、非标准随机数来源，问题会在联调或生产才冒出来。
我的建议是：先做一轮“故意严格”的测试，把 GODEBUG=fips140=only 放进测试任务里，尽早暴露非批准算法路径。然后把服务的出站请求、入站 TLS、JWT/签名、密钥派生、随机数使用都列出来，挨个确认是不是标准库路径，或者第三方库是否有自己的加密实现。
Go 1.26 之后，运行态检查更方便
截至 2026 年 6 月，crypto/fips140 包在最新文档里已经提供了运行态信息接口，例如 Enabled()、Version()，以及更严格模式相关的接口。这里要注意版本差异：如果你的工程还锁在 Go 1.24 或 Go 1.25，不要照抄最新 API，先看你当前工具链对应的文档。
package main
import (
"fmt"
"crypto/fips140"
)
func main() {
fmt.Println("fips enabled:", fips140.Enabled())
fmt.Println("fips version:", fips140.Version())
}
一份我会放进项目里的 FIPS 检查清单
第一，需求层面写清楚：要求哪个 FIPS 版本、哪个 Go 工具链版本、哪个运行环境。第二，构建层面固定 GOFIPS140，不要让开发机的 shell 状态决定产物。第三，测试层面跑严格模式，尤其覆盖 TLS、签名、随机数、密钥交换和第三方 SDK。
第四，发布层面保存构建日志、镜像 digest、二进制元信息和运行参数。第五，回滚层面也要有 FIPS 产物，不能出问题时回到一个“非合规但能跑”的旧镜像。第六，文档层面把“哪些路径走 Go 标准库，哪些第三方库需要额外证明”写出来，方便安全团队和客户审计。
最后说句实话
FIPS 140-3 对 Go 开发者是好消息，因为以前很多团队只能绕到 Go+BoringCrypto 或自己维护复杂构建链。现在 Go 官方把能力放进标准工具链，落地门槛低了很多。但门槛低，不等于可以随手开。
我的经验是：把 FIPS 当“发布体系”来做，而不是当“环境变量”来做。你会少很多解释不清的产物、少很多临时补日志的尴尬，也少很多上线前夜才发现 TLS 握手失败的痛苦。
参考资料：Go 官方博客：The FIPS 140-3 Go Cryptographic Module、crypto/fips140 官方文档。
