项目简介
Go 是谷歌开发的静态类型编译语言，以简洁、高并发（goroutine 和 channel）和快速编译著称。标准库涵盖网络、加密和 Web 服务器，适合现代云和系统软件。
README 预览
# The Go Programming Language\n\nGo is an open source programming language that makes it easy to build simple,\nreliable, and efficient software.\n\n\n*Gopher image by [Renee French][rf], licensed under [Creative Commons 4.0 Attribution license][cc4-by].*\n\nOur canonical Git repository is located at https://go.googlesource.com/go.\nThere is a mirror of the repository at https://github.com/golang/go.\n\nUnless otherwise noted, the Go source files are distributed under the\nBSD-style license found in the LICENSE file.\n\n### Download and Install\n\n#### Binary Distributions\n\nOfficial binary distributions are available at https://go.dev/dl/.\n\nAfter downloading a binary release, visit https://go.dev/doc/install\nfor installation instructions.\n\n#### Install From Source\n\nIf a binary distribution is not available for your combination of\noperating system and architecture, visit\nhttps://go.dev/doc/install/source\nfor source installation instructions.\n\n### Contributing\n\nGo is the work of thousands of contributors. We appreciate your help!\n\nTo contribute, please read the contribution guidelines at https://go.dev/doc/contribute.\n\nNote that the Go project uses the issue tracker for bug reports and\nproposals only. See https://go.dev/wiki/Questions for a list of\nplaces to ask questions about the Go language.\n\n[rf]: https://reneefrench.blogspot.com/\n[cc4-by]: https://creativecommons.org/licenses/by/4.0/\n
常见问题 (5)
故障排除如何修复在使用 code actions 时 canRemoveParameter 中出现的 gopls panic？
这是 gopls v0.14.0 中的一个已知 bug:'remove unused parameter'(移除未使用参数)重构(refactorRewrite)在某个函数参数属于一个没有函数体的外部函数时,会因 nil 指针解引用而 panic,因为 canRemoveParameter 对 nil 的函数体调用了 go/ast.Inspect。该修复已在 CL 537878 中合入,并已 backport 到 0.14 发布分支。要解决此问题,请将 gopls 升级到 v0.14.1 或更高版本:go install golang.org/x/tools/gopls@latest,然后重启编辑器/语言服务器。
故障排除为什么在 windows/386 上使用 VirtualQuery 时，windows.MemoryBasicInformation 会返回错误的 RegionSize、State、Protect 和 Type 值？
golang.org/x/sys/windows 中的 MemoryBasicInformation 在 windows/386 上结构体布局有误：一个错误的 PartitionId 字段（在 CL 352249 中引入）使 AllocationProtect 之后的每个字段都偏移了 4 个字节，导致 VirtualQuery/VirtualQueryEx 返回错位的值，并且 Type 永远不会被写入。修复方法是将 golang.org/x/sys 升级到包含 CL 849405 的版本，该版本在 windows/386 上移除了 PartitionId 字段，使结构体与原生的 32 位 MEMORY_BASIC_INFORMATION ABI 保持一致：
go get golang.org/x/sys@latest
go mod tidy如果你的代码在 386 上引用了 MemoryBasicInformation.PartitionId，请在升级后移除该用法（否则将无法编译）。请注意，此移除是有意为之的源代码破坏性变更，因为保留错误的布局会使后续所有字段继续处于错误的偏移位置。
故障排除This is documented, intentional behavior — not a bug. (One note: Go 1.28 doesn't exist yet; the latest releases are in the 1.2x range. But this behavior has been stable across Go versions for a long time, so the answer applies regardless.)
`net.IPMask.MarshalText` is explicitly documented to return an empty slice and a nil error when the mask is empty. The implementation looks like this:
```go
// MarshalText implements the encoding.TextMarshaler interface.
// The output is that of String, with the exception that it returns
// an empty slice when the mask is empty.
func (m IPMask) MarshalText() ([]byte, error) {
if len(m) == 0 {
return []byte(""), nil
}
return []byte(m.String()), nil
}
```
So if you're getting empty output with no error, the mask you're calling it on has length 0 — it's nil or a zero-length slice. Common ways that happens:
- **Zero value:** calling it on a declared-but-uninitialized mask, e.g. `var m net.IPMask`.
- **Invalid arguments to `CIDRMask`:** `net.CIDRMask(ones, bits)` returns `nil` if the arguments are out of range, e.g. `net.CIDRMask(33, 32)`.
- **An unset struct field** after decoding JSON/XML, or a failed parse that was ignored.
Note the distinction: a mask with an invalid *non-zero* length (not 4 or 16 bytes) doesn't produce empty output — `String()` returns `"<nil>"` for those. Empty output specifically means `len(m) == 0`.
To debug, check `len(mask)` at the point where you marshal, and trace where the mask was produced. If you want to distinguish "empty mask" from "marshaling failure" in your own code, check the length yourself before or after calling `MarshalText`, since the method deliberately gives you no error signal for the empty case.
这是 Go 1.28-devel 中的一个 bug，当通过 GODEBUG=netmarshal=1 启用新的文本序列化格式时触发。对于长度不为 0、4 或 16 字节的 IPMask，MarshalText 会静默返回空字节和 nil 错误，导致数据被破坏（例如，json.Marshal 会生成 ""，反序列化后得到空掩码）。问题原因在 src/net/ip.go 中：addr, _ := netip.AddrFromSlice(m) 丢弃了 ok 返回值，因此零值 Addr 会产生空输出。解决方法：(1) 使用 GODEBUG=netmarshal=0 禁用新格式，回退到旧的 base64 编码，该编码能正确地对任意长度的掩码进行往返转换；(2) 仅序列化有效长度（0、4 或 16 字节）的掩码，例如在序列化前使用 netip.AddrFromSlice 验证并检查 ok 返回值。该修复（对无效掩码长度返回非 nil 错误）已被标记为 Go 1.28 的发布阻塞问题。
故障排除如何修复 linux/arm64 上的 TestMulHighSVE SIGSEGV 崩溃（SVE 结果向量覆盖相邻栈槽）？
这是 cmd/compile 中的 SVE 寄存器参数 morestack 溢出偏移（spill-offset）Bug，已在 Go master 上由 CL 828585 修复（于 2026-10-02 合入）。该崩溃并非由 arm64 memmove FP/SIMD 改动（CL 840906）引起。它出现在 trybot 上，是因为 LUCI 按上传时的 patchset 提交原样构建，而该 CL 的每个 patchset 都基于 2026-09-28 的 master（a696473376），早于该修复。修复/变通方法：将你的 CL rebase 到当前 master（2026-10-02 之后的任意提交）并重新上传，使 trybot 运行包含该编译器修复。症状确认：被溢出（spill）的 SVE（Z 寄存器）参数在 morestack 调用期间落在错误的栈偏移处，破坏了附近的槽位（例如位于 sp+0x88 的闭包指针被 MulHigh 结果通道覆盖），从而导致诸如 'unexpected fault address 0xffffffbb00000777' 的错误。
故障排除为什么在 GODEBUG=netmarshal=1 下，对 net.HardwareAddr 执行 json.Marshal 成功后，json.Unmarshal 会失败并返回 "invalid MAC address"？
这是 Go 标准库的一个 bug（golang/go#82360）。在设置 GODEBUG=netmarshal=1 时，net.HardwareAddr.MarshalText 使用 HardwareAddr.String()，它会将任意长度的字节切片进行十六进制格式化，而 UnmarshalText 使用 ParseMAC，后者只接受 6、8 或 20 字节的地址。因此，像 {0x01, 0x02, 0x03} 这样的 HardwareAddr 会序列化为 "01:02:03"，但反序列化时会失败，报错 address 01:02:03: invalid MAC address。修复/变通方法：（1）升级到包含 CL 851265（net: marshal and unmarshal invalid HardwareAddr values）的 Go 版本，该 CL 使序列化/反序列化能够处理无效长度；（2）移除 GODEBUG=netmarshal=1 以恢复旧的 base64 JSON 编码，该编码对任意长度的切片都能正常往返转换；（3）如果需要文本序列化行为，则仅使用标准 MAC 长度（6、8 或 20 字节）。