はじめに — この記事の読み方

この記事は、Go 言語の基本概念を 🧑‍🎓（ギャル）と 🧑‍🏫（熱血先生）の対話形式 で解説するものである。

対象読者は「他の言語（Python, Ruby, Java など）を触ったことがあるが、Go は初めて」という人。Go 独特の設計思想には「なぜそうなっているのか」が分かると一気に腹落ちするポイントが多い。各トピックの対話を通じて、その「なぜ」を掴んでほしい。

コード例はすべて Go 1.21+ で動作する。手元で go run main.go しながら読むと効果的である。

静的型付けって何が嬉しいの？

🧑‍🎓 Python だと型とか書かなくてもサクサク動くじゃん？なんで Go ってわざわざ型書くの？めんどくない？

🧑‍🏫 いい質問だ！荷物の仕分け作業を想像してくれ！動的型付けは「箱を開封して中身を確認してから仕分けする」やり方。静的型付けは「箱にラベルが貼ってあるから開封せずに仕分けできる」やり方なんだ！

動的型付けだと「実行してみるまで型の間違いに気づけない」。この Python コードを見てくれ！

def add(a, b):
    return a + b

add("hello", 1)  # 実行時に TypeError

これはテストで通すか実際に動かすまでエラーにならない。Go なら同じミスをコンパイル時に弾けるんだ！

func add(a, b int) int {
    return a + b
}

add("hello", 1) // コンパイルエラー: cannot use "hello" (type string) as type int

ラベル（型情報）があるから、箱を開ける前に「これは入れる場所が違う」と分かるわけだぜ！

🧑‍🎓 あー、なるほどね〜。動かす前にミスわかるのはたしかにアガるかも。でもさ、毎回 int とか string とか書くのだるくない？

🧑‍🏫 そこだよ！実は Go には型推論があるんだ！ := を使えば、コンパイラが右辺から型を推論してくれる！

name := "Alice"   // string と推論される
age := 30         // int と推論される
rate := 0.85      // float64 と推論される

明示的に型を書かなくても、コンパイラは name が string であることを知っている。name + 1 のような間違いはちゃんと弾いてくれるぞ！

🧑‍🎓 えっ、まじ？じゃあ書き心地は Python とあんま変わんないってこと？

🧑‍🏫 その通りだ！お前、センスあるな！「型推論で書き心地は動的型付けに近く、安全性は静的型付け」— これが Go のバランスなんだ！

🧑‍🎓 てかそれめっちゃ賢いじゃん。いいとこ取りってやつ？それはアガる〜

🧑‍🏫 まさにそうだぜ！楽に書けるのに安全、それが Go の設計哲学だ！覚えとけ！

値渡しと参照渡し — Go は"全部コピー"

🧑‍🎓 てかさ、Go って関数に引数渡すとき、値渡し？参照渡し？どっち系なの？

🧑‍🏫 よく聞いてくれた！ここ超大事だからな！ Go は基本すべて値渡し だ！書類のコピーを渡すイメージだぜ。コピーに何を書き込んでも原本には影響しない！

func double(n int) {
    n = n * 2
    fmt.Println("inside:", n) // inside: 20
}

func main() {
    x := 10
    double(x)
    fmt.Println("outside:", x) // outside: 10（変わらない）
}

一方、ポインタ渡しは「原本の保管場所を教える」やり方だ。保管場所を知っているので、原本を直接書き換えられる！

🧑‍🎓 ふーん、なるほどね〜。じゃあ slice はどうなの？関数の中で変更したら反映されるって聞いたんだけど

🧑‍🏫 おお、いいところ突くな！ここが初学者が一番混乱するポイントだ！ slice の内部構造を知ると一発で理解できるぞ！

slice の実体（24バイトの struct）
┌──────────┬─────┬─────┐
│ pointer  │ len │ cap │
│ (8byte)  │(8)  │(8)  │
└──────────┴─────┴─────┘
      │
      ▼
  [背後の配列: a, b, c, d, ...]

封筒（24バイトの struct）はコピーされるが、中に入っている地図（pointer）は同じ場所を指している。だから封筒が2つあっても、地図をたどれば同じ宝物（配列）にたどり着くんだ！

func modify(s []int) {
    s[0] = 999 // 同じ配列を指しているので反映される
}

func main() {
    nums := []int{1, 2, 3}
    modify(nums)
    fmt.Println(nums) // [999 2 3]
}

🧑‍🎓 えー、じゃあ slice って実質参照渡しみたいなもんじゃん？

🧑‍🏫 要素の変更に関してはそうだ！だが append で容量（cap）を超えると話が変わるんだ！いいか、ここ絶対覚えとけよ！

func appendItem(s []int) {
    s = append(s, 100)
    fmt.Println("inside:", s)
}

func main() {
    nums := make([]int, 3, 3)
    appendItem(nums)
    fmt.Println("outside:", nums) // [0 0 0]（100 が反映されていない！）
}

🧑‍🎓 うそ、append したのに反映されないとかやばくない？バグかと思うじゃん！

🧑‍🏫 だろ！？だからここが超大事なんだ！

append で cap を超えると、Go は新しい配列を確保して要素をコピーする。関数内の s は新しい配列を指すが、呼び出し元の slice は古い配列を指したままである。封筒のコピーが持つ地図だけが新しい場所に書き換わり、元の封筒の地図は古いまま。対策はポインタで渡すか、戻り値で返すこと。

🧑‍🎓 なるほどね〜、封筒のコピーって考えるとわかりやすい。戻り値で返すのが安全ってことね

🧑‍🏫 その通りだぜ！ s = append(s, x) の結果を必ず受け取る — これが Go の鉄則だ！

ポインタ — アドレスを渡すという発想

🧑‍🎓 ポインタってやつ、C言語のでしょ？まじ怖いんだけど〜

🧑‍🏫 安心しろ！ Go のポインタは C より圧倒的に安全だ！ポインタ演算ができないし、ガベージコレクタがメモリを管理してくれる！覚えるのは2つの記号だけだぜ！

「住所と家」で考えるとわかりやすい。& は「家の住所を教える」、* は「その住所に行って中を見る」操作だ！

x := 42
p := &x  // & で家の住所を取得する
fmt.Println(*p) // * でその住所に行って中を見る → 42

*p = 100        // その住所に行って中身を書き換える
fmt.Println(x)  // 100（p 経由で x が変更された）

🧑‍🎓 えっ、2つだけ？ & が住所で * が訪問？それなら覚えられるかも

🧑‍🏫 だろ！シンプルだぜ！で、なんでポインタが必要かっていうと、さっきの値渡しの話と直結するんだ！値渡しだと「家をまるごとコピーして渡す」ことになる。コピーした家をリフォームしても、元の家は変わらない。でも住所（ポインタ）を渡せば、相手は元の家に直接行けるんだ！

🧑‍🎓 あー、さっきの slice の話とつながるね。で、具体的にどういうとき使うの？

🧑‍🏫 ポインタが必要な理由は主に2つだ！よく聞けよ！

① 呼び出し元の値を変更したいとき

住所を教えれば、相手がその家の中身を直接変えられる。

func increment(n *int) {
    *n++ // 住所に行って中身を +1
}

func main() {
    x := 10
    increment(&x) // x の住所を教える
    fmt.Println(x) // 11
}

② 大きなデータのコピーを避けたいとき

豪邸をまるごとコピーするのは大変だが、住所を伝えるだけなら一瞬だ！

type BigData struct {
    Records [10000]int
}

func processValue(d BigData) { /* 80KB のコピーが発生 */ }
func processPointer(d *BigData) { /* 8バイトのポインタだけ */ }

🧑‍🎓 なるほどね〜、住所渡すだけなら一瞬だもんね。てかそれめっちゃ賢い

🧑‍🏫 お前、呑み込み早いな！ただし nil ポインタには注意が必要だ！存在しない住所に行こうとすると panic になるぞ！

var p *int
fmt.Println(*p)  // panic: nil pointer dereference

🧑‍🎓 えっ、やばくない？ panic って落ちるってこと？

🧑‍🏫 そうだ！だからこれだけは絶対覚えとけ！

ポインタのゼロ値は nil である。nil ポインタをデリファレンスすると panic が発生する。関数がポインタを受け取る場合、nil チェックを習慣にすること。

struct とメソッド — ポインタレシーバ vs 値レシーバ

🧑‍🎓 Go にはクラスがないって聞いたんだけど、まじ？オブジェクト指向っぽいことどうやんの？

🧑‍🏫 いい質問だ！ Go では struct にメソッドを紐づけるんだ！クラスがなくてもオブジェクト指向的な設計は十分できるぞ！

type User struct {
    Name string
    Age  int
}

func (u User) Greet() string {
    return "Hi, I'm " + u.Name
}

🧑‍🎓 ふーん。でもさ、(u User) と (u *User) ってあるじゃん？あれ何が違うの？

🧑‍🏫 よく聞いてくれた！ここ超大事だからな！値レシーバとポインタレシーバの違いだ！

func (u User) SetNameValue(name string) {
    u.Name = name // コピーに対する変更なので反映されない
}

func (u *User) SetNamePointer(name string) {
    u.Name = name // 元の struct を変更するので反映される
}

🧑‍🎓 あー、さっきの値渡しの話と同じパターンじゃん！コピーに書いても元は変わんないってやつ

🧑‍🏫 その通りだ！お前、Go のセンスあるぞ！使い分けの基準はこうだ！

条件	レシーバ
struct のフィールドを変更する	ポインタレシーバ `*T`
読み取りだけ＆struct が小さい	値レシーバ `T`
読み取りだけだが struct が大きい	ポインタレシーバ `*T`

実務では「迷ったらポインタレシーバ」で問題ないことが多いぞ！

🧑‍🎓 おっけ〜。でもさ、クラスがないってことは継承もないんでしょ？それでオブジェクト指向成り立つの？ぴえん

🧑‍🏫 泣くな！ Go は継承の代わりに composition（埋め込み） を使うんだ！ struct の中に別の struct を埋め込むことで、フィールドとメソッドを再利用できる！

type Animal struct {
    Name string
}
func (a Animal) String() string { return a.Name }

type Dog struct {
    Animal  // 埋め込み。Dog は Animal のフィールドとメソッドを持つ
    Breed string
}

func main() {
    d := Dog{Animal: Animal{Name: "Pochi"}, Breed: "Shiba"}
    fmt.Println(d.String()) // "Pochi" — Animal のメソッドが直接呼べる
}

🧑‍🎓 えー、継承っぽいけど継承じゃないの？なんか不思議

🧑‍🏫 「is-a（犬は動物である）」ではなく「has-a（犬は動物の性質を持つ）」で考えるのが Go 流だ！実際、継承の複雑さ — ダイヤモンド問題とか — を避けつつ、コードの再利用は十分にできる。こっちの方がシンプルで強いんだぜ！

🧑‍🎓 なるほどね〜、継承の闇を回避しつつ再利用できるのはウケる。Go、意外と攻めてるね

interface — 暗黙的に満たす設計

🧑‍🎓 Java の interface と Go の interface って何が違うの？ implements とか書くの？

🧑‍🏫 よく聞いてくれた！まず「もし interface がなかったら」を考えてみろ！

// interface がない世界
func MakeDogNoise(d Dog)   { fmt.Println(d.Speak()) }
func MakeCatNoise(c Cat)   { fmt.Println(c.Speak()) }
func MakeBirdNoise(b Bird) { fmt.Println(b.Speak()) }
// 新しい動物が増えるたびに関数を追加…

🧑‍🎓 えー、動物増えるたびに関数書くとかだるすぎじゃん

🧑‍🏫 だろ！ interface があれば1つの関数で済むんだ！コンセント（interface）の形さえ合えば、どんな家電（実装）でも挿せるのと同じ発想だぜ！

type Speaker interface {
    Speak() string
}

type Dog struct{}
func (d Dog) Speak() string { return "Woof!" }

type Cat struct{}
func (c Cat) Speak() string { return "Meow!" }

// 1つの関数であらゆる Speaker を受け取れる
func MakeNoise(s Speaker) {
    fmt.Println(s.Speak())
}

func main() {
    MakeNoise(Dog{}) // Woof!
    MakeNoise(Cat{}) // Meow!
}

そして Go の最大の特徴はここだ！ implements キーワードが不要なんだ！メソッドをすべて持っていれば自動的に interface を満たす！

🧑‍🎓 まじ？宣言しなくていいの？それって Python のダックタイピングと同じじゃない？

🧑‍🏫 発想は近い！だが大きな違いがあるぞ！ Python は実行時に判定するので実行時エラーになる。Go はコンパイル時にチェックされる。これを Structural Typing と呼ぶんだ！

🧑‍🎓 へー。てかさ、後から interface を定義しても既存の struct に適用できるってこと？

🧑‍🏫 その通りだ！サードパーティの struct に対して、自分のコードで interface を定義して抽象化できるんだ。コンセントの規格を後から決めても、形が合う家電は最初から対応していた — そういうことだぜ！

🧑‍🎓 うそ、それやばくない？めっちゃ柔軟じゃん。他の言語だと既存のコードに手入れなきゃダメなのに

🧑‍🏫 そう！それが Go の interface の一番カッコいいところなんだ！覚えとけ！

クリーンアーキテクチャ — interface で層を分離する

🧑‍🎓 Go の interface がクリーンアーキテクチャと相性いいって聞いたんだけど、なんで？

🧑‍🏫 おお、いいところに目をつけたな！まず「なぜ層を分けるのか」から考えよう。全部 main.go に書いたらどうなるか見てみろ！

// 全部 main.go に書いた例（ハンドラ・ロジック・DB操作が混在）
func main() {
    http.HandleFunc("/users", func(w http.ResponseWriter, r *http.Request) {
        db, _ := sql.Open("mysql", "user:pass@/mydb")
        rows, _ := db.Query("SELECT id, name FROM users")
        // ... JSON に変換して返す
    })
    http.ListenAndServe(":8080", nil)
}

🧑‍🎓 うわ、全部ごちゃ混ぜじゃん。これで「MySQL やめて PostgreSQL にして」って言われたら地獄じゃない？

🧑‍🏫 まさにそうだ！ DB 操作がハンドラに直書きされているから、全箇所を書き直す羽目になる。テストも本物の DB がないと動かない！

レストランの厨房に例えると分かりやすいぞ。ホール（handler）、シェフ（usecase）、食材仕入れ（repository）、レシピ（domain）がすべて一人の仕事だったら、仕入れ先を変えるだけで厨房全体が混乱する。役割を分ければ、仕入れ先が変わってもシェフの仕事は変わらないんだ！

🧑‍🎓 なるほどね〜、レストランで考えるとわかりやすい。で、具体的にどう分けるの？

🧑‍🏫 クリーンアーキテクチャの4層構成はこうだ！

Handler（ホール）→ Usecase（シェフ）→ Repository（食材仕入れ）→ Domain（レシピ・interface定義）

ポイントは domain 層に interface を定義し、repository 層がそれを実装するという構造だ！

// domain/user.go — レシピと仕入れ先の「規格」を定義
type User struct {
    ID   int
    Name string
}

type UserRepository interface {
    FindByID(id int) (*User, error)
    Save(user *User) error
}

// repository/user_repository.go — 実際の仕入れ先（MySQL）
type userRepository struct {
    db *sql.DB
}

func (r *userRepository) FindByID(id int) (*domain.User, error) {
    // DB から取得する処理
}

func (r *userRepository) Save(user *domain.User) error {
    // DB に保存する処理
}

// usecase/user_usecase.go — シェフは「規格」だけ知っていればいい
type UserUsecase struct {
    repo domain.UserRepository
}

func NewUserUsecase(repo domain.UserRepository) *UserUsecase {
    return &UserUsecase{repo: repo}
}

🧑‍🎓 あー、Usecase は interface しか知らないから、裏側が MySQL でも PostgreSQL でもどっちでもいいってこと？

🧑‍🏫 完璧だ！ MySQL から PostgreSQL に変えたいときは、userRepository の実装を差し替えるだけ。Usecase も Handler も一切変更しなくてよい！

🧑‍🎓 それはアガる〜。てか Go の interface が implements いらないから、余計にハマるってこと？

🧑‍🏫 その通りだ！ Go の interface がクリーンアーキテクチャと特に相性が良い理由は4つある！

暗黙的実装で循環依存が起きない — repository が domain パッケージを import するだけで済む
小さい interface がイディオム — 1〜3メソッドの interface が推奨される。DIP がシンプルに実現できる
明示的な依存注入が自然 — コンストラクタ関数で interface を受け取るパターンが標準的。DI コンテナ不要
テスタビリティ — interface を満たすモックを簡単に作れる

🧑‍🎓 Go、めっちゃ設計のこと考えてるじゃん。見直したわ〜

goroutine — 並行処理を気軽に始める

🧑‍🎓 並行処理ってなんか難しそうなイメージあるんだけど、Go だと簡単なの？

🧑‍🏫 料理で考えてみろ！パスタを茹でている間にソースを作る、サラダを盛り付ける — これが並行処理だ！ Go では go キーワードを関数の前に置くだけで goroutine（並行する調理タスク）が起動する！

func sayHello(name string) {
    fmt.Println("Hello,", name)
}

func main() {
    go sayHello("Alice") // goroutine として起動
    go sayHello("Bob")
    time.Sleep(time.Second) // goroutine の完了を待つ（仮の方法）
}

🧑‍🎓 え、go って書くだけ？めっちゃ簡単じゃん。でも OS のスレッドとは違うの？

🧑‍🏫 まったく違うぞ！ここが Go のカッコいいところなんだ！

	OS スレッド	goroutine
初期スタック	約 1MB	約 2KB
スタックサイズ	固定	動的に成長
管理	OS カーネル	Go ランタイム
生成コスト	高い	非常に低い

goroutine は Go ランタイムの GMP スケジューラ によって管理される。M個の goroutine を N個の OS スレッドにマッピングする仕組み（M:N スケジューリング）だ。数万の goroutine を同時に動かしても問題ない！

🧑‍🎓 数万！？やばくない？スレッドだとそんなの無理でしょ

🧑‍🏫 その通り！ OS スレッドで数万は現実的じゃないが、goroutine なら余裕だぜ！

🧑‍🎓 てかさ、さっきの time.Sleep で待つの雑すぎない？終わったかどうかわかんないじゃん

🧑‍🏫 鋭い！ sync.WaitGroup を使うんだ！全品揃ったら配膳する、というイメージだぜ！

func worker(id int, wg *sync.WaitGroup) {
    defer wg.Done() // この料理は完成した、と報告
    fmt.Printf("Worker %d done\n", id)
}

func main() {
    var wg sync.WaitGroup
    for i := 1; i <= 5; i++ {
        wg.Add(1) // 作る料理を1品追加
        go worker(i, &wg)
    }
    wg.Wait() // 全品揃うまで待つ
}

🧑‍🎓 なるほどね〜、Add して Done して Wait。わかりやすい。名前がそのまんまなのウケる

channel — goroutine 同士の会話

🧑‍🎓 goroutine の結果を受け取りたいときってどうすんの？ WaitGroup だと「終わった」しかわかんないじゃん

🧑‍🏫 いいところに気づいたな！ channel を使うんだ！料理人同士の声かけだと思えばいい。「ソースできたよ！」「了解、パスタに合わせるね」というやり取りが channel だ！

func compute(ch chan int) {
    result := 42
    ch <- result // 「42できたよ！」と送る
}

func main() {
    ch := make(chan int)   // 声をかけ合うための経路を作る
    go compute(ch)
    result := <-ch         // 「受け取った！」
    fmt.Println(result)    // 42
}

🧑‍🎓 あー、矢印の向きで送る・受け取るが決まるのね。直感的でいいかも

🧑‍🏫 そうだ！ ch <- が送信、<-ch が受信だ！で、channel にはバッファなしとバッファありがあるんだ！

🧑‍🎓 バッファ？何それ

🧑‍🏫 バッファなし channel は「手渡し」だ — 相手が受け取るまで送り手は待つ。バッファあり channel は「郵便受け」— 受け手がいなくてもバッファに空きがあれば送れるんだ！

ch := make(chan int, 3) // バッファサイズ3の郵便受け
ch <- 1 // 即座に送れる
ch <- 2 // まだ空きがある
ch <- 3 // まだ空きがある
// ch <- 4 // ここでブロックされる（郵便受けが一杯）

🧑‍🎓 手渡し vs 郵便受け、めっちゃわかりやすいじゃん。でも複数の channel を同時に待ちたいときはどうすんの？

🧑‍🏫 select 文を使う！複数の channel のうち、準備ができたものを処理できるんだ！

select {
case msg := <-ch1:
    fmt.Println("ch1:", msg)
case msg := <-ch2:
    fmt.Println("ch2:", msg)
case <-time.After(3 * time.Second):
    fmt.Println("timeout")
}

🧑‍🎓 へー、switch 文みたいな見た目だけど channel 用ってことか。タイムアウトも書けるのいいね

🧑‍🏫 その通り！ select + time.After のパターンは実務で超頻出だ！覚えとけ！

エラーハンドリング — 例外がない世界

🧑‍🎓 Go には try-catch がないって聞いたんだけど、まじ？じゃあエラーどうすんの？

🧑‍🏫 本当だ！ Go ではエラーはただの値であり、戻り値として返すんだ！

file, err := os.Open("data.txt")
if err != nil {
    log.Fatal(err)
}
defer file.Close()

🧑‍🎓 えー、if err != nil を毎回書くの？だるくない？ try-catch の方が楽じゃん

🧑‍🏫 一見冗長に見えるが、try-catch には「どこで例外が飛ぶか分かりにくい」という問題があるんだ！ 10行のコードを try で囲んだとき、どの行が例外を投げうるかは読み手が把握しなければならない。Go では if err != nil が「ここでエラーが起きうる」という明示的なマーカーになる。エラーの発生箇所と処理が常に隣り合っているから、コードの流れを追いやすいんだ！

🧑‍🎓 あー、たしかに。try の中で5個くらい関数呼んでると、どれが例外出すかわかんないもんね

🧑‍🏫 そう！冗長さと引き換えに可読性を得ている。これが Go の設計思想だ！

🧑‍🎓 なるほどね〜、納得。じゃあエラーの種類を判定したいときはどうすんの？

🧑‍🏫 Go 1.13+ では errors.Is / errors.As / %w でエラーチェーンを扱えるぞ！

// エラーをラップして文脈を追加
if err != nil {
    return fmt.Errorf("failed to open config: %w", err)
}

errors.Is は「このエラーチェーンの中に特定のエラーが含まれるか」を判定する！

if errors.Is(err, os.ErrNotExist) {
    fmt.Println("ファイルが存在しない")
}

🧑‍🎓 errors.As ってのもあるんでしょ？あれはどういうとき使うの？

🧑‍🏫 エラーの「種類」で分岐しつつ、そのエラーの詳細情報にアクセスしたいときに使うんだ！

type ValidationError struct {
    Field   string
    Message string
}
func (e *ValidationError) Error() string {
    return fmt.Sprintf("%s: %s", e.Field, e.Message)
}

// エラーを返す側
func validateAge(age int) error {
    if age < 0 {
        return &ValidationError{Field: "age", Message: "must be non-negative"}
    }
    return nil
}

// エラーを受け取る側
err := validateAge(-1)
var ve *ValidationError
if errors.As(err, &ve) {
    // ValidationError の詳細フィールドにアクセスできる
    fmt.Println("invalid field:", ve.Field)   // "age"
    fmt.Println("reason:", ve.Message)         // "must be non-negative"
}

🧑‍🎓 ラップされたエラーでも errors.As 使えるの？ %w で包んでても大丈夫？

🧑‍🏫 使える！ %w でラップされていても、チェーンを辿って型を見つけてくれるんだ！

// ラップされたエラー
wrapped := fmt.Errorf("input validation failed: %w",
    &ValidationError{Field: "email", Message: "invalid format"})

var ve *ValidationError
if errors.As(wrapped, &ve) {
    fmt.Println(ve.Field) // "email" — ラップを解いて取り出せる
}

🧑‍🎓 まじ？ラップ解いて中身取れるとかめっちゃ賢いじゃん

🧑‍🏫 だろ！使い分けだけ覚えとけ！

使い分けの目安 — errors.Is は「どのエラーか（値の一致）」、errors.As は「どの種類のエラーか（型の一致）＋詳細情報へのアクセス」。

Go ならではの "知っておくべき" まとめ

defer — 後始末の保証

defer は関数の終了時に実行される。ファイルのクローズやロックの解放に使う。

func readFile(path string) error {
    f, err := os.Open(path)
    if err != nil {
        return err
    }
    defer f.Close() // この関数を抜けるときに必ず実行される

    // f を使った処理...
    return nil
}

複数の defer は LIFO（後入れ先出し） で実行される。

defer fmt.Println("1st")
defer fmt.Println("2nd")
defer fmt.Println("3rd")
// 出力: 3rd → 2nd → 1st

panic と recover

panic はプログラムを異常終了させる。recover は defer の中でのみ panic を捕捉できる。

func safeDivide(a, b int) (result int, err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("recovered: %v", r)
        }
    }()
    return a / b, nil // b=0 なら panic
}

panic / recover は Go における例外処理 ではない。通常のエラーハンドリングには error を使い、panic は「プログラムを続行できない致命的な状況」に限定すること。

ゼロ値 — 宣言しただけで使える

Go の変数は宣言時に自動的にゼロ値で初期化される。

型	ゼロ値
`int`, `float64`	`0`
`string`	`""`
`bool`	`false`
`pointer`, `slice`, `map`, `channel`, `func`, `interface`	`nil`
`struct`	各フィールドのゼロ値

nil の扱いで注意すべき非対称性がある。

// nil slice は append OK
var s []int
s = append(s, 1) // 問題なし

// nil map への書き込みは panic
var m map[string]int
m["key"] = 1 // panic: assignment to entry in nil map

map は make で初期化してから使うこと。

m := make(map[string]int)
m["key"] = 1 // OK

未使用変数・import はコンパイルエラー

Go はコードの清潔さに厳格だ。使っていない変数や import があるとコンパイルが通らない。

import "fmt" // fmt を使っていなければコンパイルエラー

func main() {
    x := 10 // x を使っていなければコンパイルエラー
}

開発中に一時的に無視したい場合は _（ブランク識別子）を使う。

_ = x // 「使った」ことにする

init() 関数 — パッケージ初期化

init() はパッケージが読み込まれたときに自動実行される特殊な関数である。main() より前に呼ばれる。

var config Config

func init() {
    // パッケージ読み込み時に設定をロード
    config = loadConfig()
}

init() はテストしにくく、実行順序の把握も難しい。多用は避け、明示的な初期化関数（NewXxx() など）を優先するのが現代の Go のプラクティスである。

🧑‍🏫 🧑‍🎓 以上が Go の基本概念の「なぜ」である！Go の設計は「シンプルさ」と「明示性」を徹底している！最初は冗長に感じる部分もあるが、コードベースが大きくなるほど、その設計判断の意味が分かってくるはずだ！！！🔥

P.S.

ギャル生徒が優秀すぎる