咨询：开源Go项目应测试哪些GOARCH/GOOS/Go版本组合？

Great question—this is a super common balancing act for Go maintainers, especially after you’ve already been burned by missed architecture issues like your 386 test failure! Let’s break this down into actionable, practical groups to cover what matters without slowing down your CI pipeline to a crawl.

Core GOOS/GOARCH Combinations (Must-Have) #

These are the platforms where most users will run your code, and where architecture-specific bugs (like 32-bit integer overflow, pointer size differences, or OS syscall quirks) are most likely to bite:

• Mainstream 64-bit production/development platforms:
  • linux/amd64: The de facto standard for servers and cloud environments—non-negotiable.
  • darwin/amd64 & darwin/arm64: Covers both Intel and Apple Silicon Macs, which are popular among Go developers.
  • windows/amd64: Critical for Windows desktop and server users.
• High-risk 32-bit platform:
  • linux/386: You already learned this the hard way! 32-bit systems have different memory models and integer limits that often expose bugs hidden in 64-bit tests.
• Fast-growing 64-bit ARM:
  • linux/arm64: Used in AWS Graviton, Azure Ampere, and modern embedded devices—adoption is skyrocketing, and it has subtle differences from amd64 that can catch you off guard.

Go Version Selection #

Focus on versions that your actual users are running, plus a bit of forward-looking coverage:

• Current stable release (e.g., Go 1.22): The version most new users will adopt—must test all core platforms here.
• Previous 2 minor releases (e.g., Go 1.21, Go 1.20): Many enterprises and users lag 1-2 versions behind for stability reasons. For these, you can limit testing to just the core 64-bit platforms (linux/amd64, darwin/amd64, windows/amd64) to save time.
• Latest beta/RC (Optional): If you want to catch compatibility issues early or plan to use new Go features, add this—but only test core platforms, and consider making it a separate, non-blocking job.
• Skip end-of-life versions: Go only supports the last 3 stable releases, so there’s no need to test versions older than that unless your project has a dedicated user base stuck on them.

Tips to Keep Builds Fast #

Testing more platforms doesn’t have to mean waiting forever—use these tricks to optimize your Travis pipeline:

• Parallelize jobs: Split your test matrix into separate parallel Travis jobs (one per GOOS/GOARCH combo) so they run at the same time instead of sequentially.
• Skip obsolete combinations: Ditch platforms like darwin/386 (Apple dropped 32-bit Mac support years ago) or windows/arm (rarely used for Go projects) unless you have explicit user requests for them.
• Differentiate test depth: For edge platforms (e.g., linux/mips if you need it), run only the core unit tests with go test -short instead of full integration tests. Save the slow, comprehensive tests for core platforms.
• Cache aggressively: Use Travis’s caching to store Go modules, build artifacts, and test caches—this cuts down on repeated dependency downloads and compilation time.
• Matrix pruning: For older Go versions, skip niche architectures. For example, only run linux/amd64, darwin/amd64, and windows/amd64 on Go 1.20, but run all core platforms on Go 1.22.

Scenario-Specific Additions #

Tailor your test matrix to what your project does:

• CLI tools: Add freebsd/amd64 and openbsd/amd64—BSD users love command-line utilities.
• Embedded/IoT projects: Add linux/arm (32-bit ARM for devices like older Raspberry Pi models) and potentially linux/mips if you target specific embedded hardware.
• Cross-platform desktop apps: Add windows/arm64 (for new Windows ARM laptops) and ensure full test coverage on darwin/arm64 (Apple Silicon is now standard for Macs).
• cgo-dependent projects: Be extra careful—cgo breaks cross-platform compatibility easily. For example, if you use cgo with linux/386, make sure your CI environment has 32-bit system libraries installed. You might also want to limit cgo tests to platforms you know have reliable library support.

Final Note #

The key is to start small with the core combinations, then expand based on user feedback or bug reports. Your 386 failure is a perfect example—adding that one platform caught a bug that would have slipped to users. By focusing on high-impact platforms and optimizing your CI pipeline, you can keep coverage meaningful without sacrificing speed.

内容的提问来源于stack exchange，提问作者Sonia Hamilton