Go 怎么为 Windows 和 Linux 编写不同实现

同一个 Go 包需要在 Windows 和 Linux 下调用不同系统能力时，推荐把差异拆到平台文件里：上层只依赖公共函数，文件名后缀或 //go:build 负责选择实现。这样比在业务代码里到处写 runtime.GOOS 更容易维护，也能让构建阶段直接暴露缺少平台实现的问题。

最小可维护方案是“公共 API + 平台实现文件”：os_windows.go 服务 Windows，os_linux.go 服务 Linux；只有条件更复杂时才增加显式 //go:build。

先把跨平台差异收进公共 API

假设应用要判断一个目录是否允许写入。Windows 和 Linux 的底层实现可能不同，但业务层真正需要的只是一个稳定的 CanWrite 函数。先在包中保留一份不带平台后缀的公共入口：

package platform

// CanWrite 由不同平台文件提供具体实现。
func CanWrite(path string) (bool, error) {
	return canWrite(path)
}

这里的公共入口只负责统一名字和返回值。canWrite 不在这个文件中实现，否则平台文件再声明同名函数就会产生重复定义。公共文件、Windows 文件和 Linux 文件会共同组成同一个 platform 包。

用文件名后缀分别实现 Windows 和 Linux

在同一目录加入下面两个文件。Go 工具链会把后缀中的 GOOS 或 GOARCH 当作隐式构建约束，因此不需要在最简单的场景重复写标签。

// 文件：os_windows.go
package platform

import "os"

// canWrite 使用 Windows 可访问性检查作为示例实现。
func canWrite(path string) (bool, error) {
	info, err := os.Stat(path)
	if err != nil {
		return false, err // 路径不存在或当前进程无法读取时交给上层处理。
	}
	return !info.IsDir() || info.Mode().Perm() != 0, nil
}

// 文件：os_linux.go
package platform

import "os"

// canWrite 读取 Unix 权限位，示例只关注 owner/group/other 的可写位。
func canWrite(path string) (bool, error) {
	info, err := os.Stat(path)
	if err != nil {
		return false, err // 不把 stat 失败误判成“没有写权限”。
	}
	return info.Mode().Perm()&0222 != 0, nil
}

这段示例刻意只演示“同一函数名由不同文件提供实现”的组织方式。真实权限判断还要考虑当前用户、ACL、只读挂载和目录继承等因素，不能把 Mode().Perm() 当成完整授权结论。

复杂条件用 go:build 表达，不要把判断写进运行时

当一个实现还受架构或 cgo 影响时，可以在文件顶部写显式约束。例如只让 Linux 且启用 cgo 的实现参与构建：

//go:build linux && cgo

package platform

// 该文件只在目标系统为 Linux 且 cgo 可用时参与构建。
func canWrite(path string) (bool, error) {
	// 这里放 Linux+cgo 的实际实现；示例省略系统调用细节。
	return path != "", nil
}

表达式支持 ||、&&、! 和括号。一个文件只能有一行 //go:build，它必须位于顶部注释区域内，并在 package 前留空行。较老的 // +build 语法仍可能出现在旧代码中，使用 gofmt 可以为它补出等价的 //go:build。

用 go list 和交叉构建检查实际文件选择

条件编译最容易踩的坑是“当前电脑能编译”不等于“目标平台能编译”。在包目录执行 go list，可以查看指定目标下进入编译的 Go 文件：

# 查看 Linux 目标实际选中的普通 Go 文件。
GOOS=linux GOARCH=amd64 go list -f '{{.GoFiles}}'

# 查看 Windows 目标实际选中的普通 Go 文件。
GOOS=windows GOARCH=amd64 go list -f '{{.GoFiles}}'

# 只构建目标文件，不在当前机器运行生成的程序。
GOOS=windows GOARCH=amd64 go build ./...

预期结果是两个列表都包含公共文件，但平台实现文件不同。若列表为空或出现重复定义，优先检查后缀拼写、文件是否放在同一包目录，以及显式标签是否把所有候选文件排除了。需要查看被排除的文件时，可把模板改成 {{.IgnoredGoFiles}}。

这几类错误最值得先排查

• 把运行时判断当成条件编译。 runtime.GOOS 只是在程序运行后分支，不能避免不支持平台的导入或系统调用被编译。
• 标签写在 package 后面。 Go 工具链扫描到第一个非空、非注释内容就会停止识别，标签放错位置等于没有标签。
• 只有 Windows 和 Linux 文件，却要支持其他系统。 如果包会被 darwin、freebsd 或 wasm 使用，应增加通用实现或明确拒绝这些目标，避免“无 Go 源文件”错误。
• 把权限语义写死在示例里。 平台文件只隔离实现差异，公共 API 仍要定义错误、目录、ACL 和权限不足时的行为。

选型上，单一平台差异优先使用文件名后缀；条件包含架构、cgo 或自定义开关时再使用 //go:build。最后把至少一个 Windows 和一个 Linux 的 go list 或交叉构建命令放进 CI，跨平台问题就会在合并前出现。

相关问题

文件名后缀和 //go:build 可以同时使用吗？

可以，但两者会同时生效，必须满足文件名隐含条件和显式表达式。条件重复时通常没有收益，复杂组合才值得这样写。

怎么只给 Linux 的 amd64 编译一个文件？

可命名为 feature_linux_amd64.go，也可以写 //go:build linux && amd64。文件名后缀更直观时优先用前者。

自定义 tag 会自动从 go.mod 读取吗？

不会。自定义 tag 需要在构建命令中通过 -tags 传入，并应为不带该 tag 的默认场景准备实现或明确不支持范围。

构建约束的完整语法和内置标签列表可参考 Go 官方 Build constraints 文档。把平台差异固定在文件边界里，业务包就能继续保持一套 API、一套测试入口和清晰的构建检查。