概要
Go は Google が開発した静的型付けコンパイル言語で、シンプルさ、高い並行処理（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
FAQ (5)
トラブル対応code actions 使用時に canRemoveParameter で発生する gopls のパニックを修正する方法
これは gopls v0.14.0 の既知のバグです。「remove unused parameter」リファクタリング（refactorRewrite）は、関数パラメータが本体を持たない外部関数に属している場合、canRemoveParameter が nil の本体に対して go/ast.Inspect を呼び出すため、nil ポインターデリファレンスでパニックを起こします。この修正は CL 537878 で取り込まれ、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 には一切書き込まれない状態でした。
修正するには、CL 849405 を含むバージョンへ golang.org/x/sys をアップグレードしてください。この CL では windows/386 上の PartitionId フィールドが削除され、構造体がネイティブの 32 ビット MEMORY_BASIC_INFORMATION ABI と一致するようになります。
go get golang.org/x/sys@latest
go mod tidyコード内で 386 上の MemoryBasicInformation.PartitionId を参照している場合は、アップグレード後にその使用箇所を削除してください（コンパイルできなくなります）。なお、この削除は意図的にソースレベルの互換性を壊すものです。誤ったレイアウトを維持すると、後続のすべてのフィールドが誤ったオフセットのままになってしまうためです。
トラブル対応There are a couple of false premises in the question worth clearing up before answering:
1. **Go 1.28 doesn't exist** as of my knowledge cutoff (early 2025), where the latest releases are around Go 1.23/1.24. I can't speak to behavior changes in versions after that.
2. **`net.IPMask` has no `MarshalText` method** in the standard library. It only has `Size()` and `String()`. Code calling `mask.MarshalText()` wouldn't compile.
That said, the symptom you describe matches a real behavior — just on `net.IP`, not `IPMask`:
```go
func (ip IP) MarshalText() ([]byte, error) {
if len(ip) == 0 {
return []byte(""), nil
}
...
}
```
A nil or empty `net.IP` marshals to an empty byte slice with a **nil error** by design, so that a zero-value field round-trips cleanly through JSON/text encoding. So if you're seeing empty output with no error, the IP value being marshaled is almost certainly nil or zero-length — for example, an unset struct field, a failed lookup that returned nil, or a conversion from something else that produced an empty slice.
A few related gotchas:
- If you're converting a mask, e.g. `net.IP(mask).MarshalText()`, an empty or invalid mask will produce that empty result. Check with `mask.Size()` — it returns `(0, 0)` for invalid masks.
- `encoding/json` doesn't use `MarshalText` for `IPMask` anyway; since it's a `[]byte` without marshaler methods, it gets base64-encoded instead, which surprises people expecting CIDR notation.
If you're hitting this in real code, check whether the value is nil before marshaling, or consider switching to `net/netip`, which has more explicit zero-value semantics. And if you genuinely observed this on a future Go release, it's worth checking the release notes or filing an issue, since silently returning empty output for a non-empty mask would be a bug.
これは、GODEBUG=netmarshal=1 によって新しいテキストマーシャリング形式が有効になっている場合の Go 1.28-devel のバグです。長さが 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 スピルオフセットのバグで、Go master では CL 828585 によってすでに修正済みです（2026-10-02 にマージ）。このクラッシュは arm64 の memmove FP/SIMD 変更（CL 840906）が原因ではありません。trybot でこの問題が現れたのは、LUCI がアップロードされた patchset のコミットをそのままビルドするためであり、この CL のすべての patchset が修正以前の 2026-09-28 時点の master（a696473376）をベースにしていたためです。修正/回避策: あなたの CL を現在の master（2026-10-02 以降の任意のコミット）に rebase して再アップロードしてください。そうすれば trybot の実行にコンパイラの修正が含まれます。症状の確認: morestack 呼び出し中にスピルされた SVE（Z レジスタ）引数が誤ったスタックオフセットに書き込まれ、近傍のスロットを破壊します（例: sp+0x88 にあるクロージャポインタが MulHigh の結果レーンで上書きされる）。これにより 'unexpected fault address 0xffffffbb00000777' のようなフォールトが発生します。
トラブル対応GODEBUG=netmarshal=1 が設定されている場合、net.HardwareAddr に対して json.Marshal が成功した後、json.Unmarshal が "invalid MAC address" で失敗するのはなぜですか？
これは Go 標準ライブラリのバグです (golang/go#82360)。GODEBUG=netmarshal=1 を設定すると、net.HardwareAddr.MarshalText は HardwareAddr.String() を使用します。これは任意の長さのバイトスライスを16進数形式でフォーマットしますが、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 バージョンにアップグレードする。これにより、マーシャル/アンマーシャルが無効な長さを処理できるようになります。(2) GODEBUG=netmarshal=1 を削除して古い base64 JSON エンコーディングに戻す。これは任意のスライス長でラウンドトリップします。(3) テキストマーシャリングの動作が必要な場合は、標準的な MAC の長さ (6、8、または20バイト) のみを使用する。