収録問題 70問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
append後も元スライスが必ず同じ下層配列を指すと仮定したコードが壊れました。適切な理解はどれですか？
答え： 容量不足なら新しい下層配列を割り当て得る
スライスはポインタ、長さ、容量を持つビューです。appendの戻り値には再割当て後のスライスが入るため、必ず受け取ります。
mapから値を取得するとき、キーが存在しない場合とゼロ値を区別したい。適切なのはどれですか？
答え： value, ok := m[key]の二値形式を使う
カンマOKイディオムのokがキーの存在を示します。不存在でも値には要素型のゼロ値が返るため、値だけでは区別できません。
外部パッケージの型に自作インタフェースを実装させたい。Goで必要なことはどれですか？
答え： 必要なメソッドセットを持てば暗黙に満たす
Goのインタフェース実装は暗黙的です。利用側が必要最小限のインタフェースを定義すると、外部型でもメソッドセットが一致すれば利用できます。
構造体の状態を書き換えるメソッドを定義したい。レシーバとして適切なのはどれですか？
答え： ポインタレシーバを使う
ポインタレシーバは元の値を更新でき、大きな構造体のコピーも避けられます。同じ型のメソッド群ではレシーバ種別を一貫させます。
下位エラーに操作情報を加えつつ、呼出側が番兵エラーを判定できるようにしたい。適切なのはどれですか？
答え： %wでラップしてerrors.Isで判定する
%wでエラーチェーンを保持すると、文脈を追加しながらerrors.Isやerrors.Asで原因を判定できます。
ファイルを開いた後、途中にreturnが複数ある処理でClose漏れを防ぎたい。適切なのはどれですか？
答え： Openの成功直後にdefer Closeを登録する
リソース取得成功後すぐdeferを登録すると、以降のreturn経路でCloseが実行されます。Closeエラーの扱いが重要なら名前付き戻り値等で明示します。
ライブラリの入力バリデーション失敗をpanicで返している。実務APIとして望ましい改善はどれですか？
答え： 通常予想される失敗はerrorとして返す
panicは不変条件破壊など継続不能な事象向けです。入力不備や外部I/O失敗は呼び出し側が判断できるerrorとして返します。
外部API呼出しをリクエスト中断やデッドラインに連動させたい。適切な設計はどれですか？
答え： 呼び出し側のContextを第一引数で受けてリクエストへ付ける
コンテキストは呼出チェーンで伝播させ、HTTPリクエストやDBクエリへ渡します。CancelFuncを作った側はdefer cancel()でリソースを解放します。
パイプラインのコンシューマーが途中終了するとプロデューサーゴルーチンがチャネル送信で永久ブロックする。改善はどれですか？
答え： Doneと送信をselectしキャンセルを全ステージへ伝播する
各ステージがキャンセルを監視し、送受信のブロックから抜けられるようにするとゴルーチンリークを防げます。
複数ワーカーへジョブを送るチャネルをCloseする責任は通常どこに置きますか？
答え： 送信完了を把握している送信側オーナー
本来は送信完了を把握する送信者オーナーがCloseします。レシーバがCloseすると並行送信者のsend on closed channelを招きます。
バッファなしチャネルの送信が完了する条件はどれですか？
答え： 対応するレシーバが受信可能になったとき
バッファなしチャネルは送信と受信のRendezvousを作り、双方が準備できるまでブロックします。通信と同期を兼ねます。
selectにdefaultを入れた結果、ループがCPUを使い切りました。原因と改善はどれですか？
答え： defaultが待機せず実行されるので待機かタイマーを設計する
準備完了なケースがないとdefaultが即時実行され、ビジーループになります。待つべき処理ではdefaultを外すかタイマー等を使います。
大量ジョブを並列処理したいが、入力数だけゴルーチンを作ってメモリを圧迫したくない。適切なのはどれですか？
答え： 固定数ワーカーがジョブチャネルを読む上限付きプール
ワーカー数で同時実行数を制限し、キューとバックプレッシャーを設計します。コンテキストで停止し、エラー回収と終了待ちも行います。
複数ゴルーチンが同じmapを読み書きする。適切な保護はどれですか？
答え： 所有権を1ゴルーチンへ集約するかMutexで同期する
通常mapの並行Read/Writeは安全ではありません。所有権移譲、Mutex、用途に合うsync.Map等を選びます。
CIで共有変数のデータ競合を検出したい。使うべきコマンドはどれですか？
答え： go test -race ./...
レース検出器は実行されたメモリアクセスを計装で監視します。並行経路を通るテストや結合テストで実行します。
複数ゴルーチンの完了を待ってから結果チャネルをCloseしたい。適切なのはどれですか？
答え： WaitGroupで完了を数えWait後にCloseする
Addは開始前、各ワーカーはdefer Done、コーディネーターがWait後に一度だけCloseします。二重Closeと送信中Closeを防げます。
高価なクライアント初期化を複数ゴルーチンから呼んでも一度だけ実行したい。適切なのはどれですか？
答え： sync.Once
sync.Once.Doは並行呼び出し下でも関数を一度だけ実行し、完了のメモリVisibilityも同期します。
複数フィールドを一貫した状態で更新する必要がある。atomicカウンターだけで十分ですか？
答え： 複合不変条件にはMutexか不変スナップショット公開を使う
アトミック操作は単一値の更新には有効ですが、複数値間の不変条件を自動では守りません。クリティカルSectionかスナップショット単位で同期します。
外部HTTP APIクライアントが応答しないとゴルーチンが溜まる。基本改善はどれですか？
答え： 再利用するClientへタイムアウトを設定しコンテキストも伝播する
クライアント/トランスポートは再利用し、接続・ヘッダー・全体デッドラインを要件に合わせます。レスポンスボディは必ずCloseし、リトライは回数とバックオフを制限します。
受信HTTPリクエストが切断されたら下流DBクエリも中断したい。適切なのはどれですか？
答え： r.Context()をQueryContextへ渡す
http.Requestのコンテキストはクライアント切断やサーバー処理終了でキャンセルされます。対応APIへ渡すと不要な下流処理を止められます。
公開HTTPサーバーをSlowloris等から守る基本設定はどれですか？
答え： ReadHeaderTimeout等のサーバータイムアウトを設定する
ReadHeaderTimeout、ReadTimeout、WriteTimeout、IdleTimeoutをトラフィック特性に合わせ、リバースプロキシのタイムアウトとも整合させます。
Kubernetes終了シグナル時にGo HTTPサーバーを安全に停止したい。適切なのはどれですか？
答え： シグナルコンテキストを受け期限付きでShutdownを呼ぶ
新規受付を止め、処理中リクエストへ猶予を与え、デッドライン超過時は強制終了方針へ移ります。レディネスも先に落とします。
JSON APIで構造体のフィールド名とJSONのキー名を分離し、空値を省略したい。適切なのはどれですか？
答え： エクスポート済みフィールドへomitempty付きjsonタグを付ける
encoding/jsonはエクスポート済みフィールドを扱い、構造体タグでWire Nameやomitemptyを指定します。omitemptyのゼロ判定は型ごとに理解します。
設定JSONのタイプミスを静かに無視せず、未知フィールドとしてエラーにしたい。適切なのはどれですか？
答え： DecoderのDisallowUnknownFieldsを有効にする
厳格な設定読込ではデコーダーのDisallowUnknownFieldsを使い、必須値や範囲はデコード後に別途バリデーションします。
database/sqlでユーザー入力を含むクエリを安全に実行したい。適切なのはどれですか？
答え： プレースホルダと引数バインディングを使う
ドライバーに合うプレースホルダで値をバインディングし、識別子の動的切替は許可リストで設計します。文字列連結はSQLインジェクションを招きます。
複数SQL更新をトランザクションで実行し、途中エラーなら確実にロールバックしたい。定石はどれですか？
答え： BeginTx後にdefer Rollbackを登録し成功時だけCommitする
defer tx.Rollback()はコミット済みなら無害なエラーとなり、途中returnをカバーします。トランザクション中はtxのメソッドを使います。
数GBのアップロードをメモリへ全読込せず処理したい。適切な抽象はどれですか？
答え： io.Readerからストリーミングし必要ならio.Copyを使う
io.Reader/Writerはチャンク単位のストリーミングを可能にします。サイズLimit、コンテキストキャンセル、部分的Writeエラーも扱います。
bufio.Scannerで非常に長い1行を読むとスキャンが停止した。適切な対応はどれですか？
答え： Scanner.Bufferの上限設定かbufio.Readerを使いErrを確認する
Scannerにはトークンサイズ上限があります。信頼境界では無制限化せず妥当な上限を定め、スキャン終了後のErrを処理します。
同じ関数へ多数の入力と期待値を適用するテストを読みやすくしたい。適切なのはどれですか？
答え： テーブル駆動テストとt.Runでケース名を付ける
入力・期待値・名前をテーブルにし、Subtest化すると追加と失敗特定が容易です。並列化する場合は共有状態に注意します。
HTTPハンドラを実ポートなしで単体テストしたい。適切なのはどれですか？
答え： httptest.NewRequestとNewRecorderを使う
httptestのリクエスト/レコーダーでハンドラを直接呼び、ステータス、ヘッダー、ボディを検証できます。クライアント統合にはhttptest.Serverも使えます。
最適化前後の処理時間と割り当てを比較したい。適切なのはどれですか？
答え： testing.Bのベンチマークと-benchmemを使う
Goベンチマークは反復回数を調整し、ns/opやallocs/opを測れます。安定環境で複数回測りbenchstat等で比較します。
パーサーへ予想外の入力を与えてクラッシュや不変条件破壊を探したい。適切なのはどれですか？
答え： Fuzzテストへシードコーパスと不変条件を定義する
ファジングはシードから入力を変異させ、panicやテスト失敗を最小化して保存します。セキュリティ境界のパーサーに有効です。
インポート変更後にgo.mod/go.sumの不要・不足依存関係を整理したい。適切なコマンドはどれですか？
答え： go mod tidy
go mod tidyは必要なモジュールRequirementとチェックサムを追加し、不要なものを削除します。CIでは実行後差分がないことを確認できます。
go.sumの主な役割はどれですか？
答え： モジュール内容のチェックサムを記録し検証に使う
go.sumはモジュールバージョンとgo.modコンテンツのハッシュを記録し、同じバージョンの改ざんや不一致検出に使われます。通常リポジトリへコミットします。
リポジトリ内だけで使うパッケージを外部モジュールからインポート不能にしたい。適切なのはどれですか？
答え： internalディレクトリの配下へ置く
Goツールチェーンはinternalディレクトリのインポート範囲を強制します。APIを不用意に公開せずリファクタリング余地を保てます。
複数モジュールをローカルで同時開発するためgo.workを使う。CIで注意すべきことはどれですか？
答え： CIがローカル構成だけを試さないようGOWORKと各モジュール単体を確認する
go.workは便利ですが、CIで依存モジュールのReleasedバージョンではなくローカルモジュールを選ぶ可能性があります。各モジュールの単体成立を検証します。
利用中依存関係の既知脆弱性が実際の呼び出しパスへ到達するかGo向けに確認したい。適切なのはどれですか？
答え： govulncheck ./...
govulncheckはGo Vulnerabilityデータベースと呼び出しグラフ分析を使い、利用コードに影響する既知脆弱性を低ノイズで報告します。
本番相当負荷でCPUホットスポットと割り当て元を調査したい。適切なのはどれですか？
答え： pprofでプロファイルを採取しgo tool pprofで分析する
CPU、ヒープ、ゴルーチン等のプロファイルを対象期間で採取し、Flameグラフや上位でコストCenterを特定します。エンドポイントは認証・ネットワーク制限します。
分散環境のログを検索しやすくし、リクエストを追跡したい。Goサービスのログ設計として適切なのはどれですか？
答え： slog等でレベル・リクエストID・操作・エラーを構造化して出す
構造化ロギングはフィールド単位のフィルタと集計を容易にします。トレース/リクエストIDをコンテキストから渡し、認証情報や個人情報を秘匿化します。
コンテナ化したGoサービスを小さく安全に配布し、シグナルで正常終了させたい。適切な組合せはどれですか？
答え： Multi-stageで最小イメージを作りNotifyContextで終了処理する
ビルドツールチェーンをランタイムから分離し、必要なCA証明書・タイムゾーン等だけを含めます。シグナルコンテキストから期限付きグレースフルシャットダウンを実行します。
*MyErrorがnilのままerrorインタフェースへ代入され、err != nilがtrueになりました。中核となる理解はどれですか？
答え： インタフェースは型と値の組なので型付きnilはnilではない
インタフェースがnilなのは動的な型と値の両方がnilのときです。型付きnilを返さず、失敗がない経路では明示的にnilのerrorを返します。
sync.Mutexを含む構造体をLock使用後に値コピーして、不整合が発生しました。適切な改善はどれですか？
答え： Lockを含む値はポインタで扱いgo vetのcopylocksも確認する
Mutex等の同期プリミティブは使用開始後にコピーしてはいけません。ポインタレシーバやポインタ保持を使い、値渡し・値return・構造体代入も点検します。
古いgoディレクティブのモジュールでrange変数をクロージャへ渡す並列処理を保守しています。安全な移行方針はどれですか？
答え： goバージョンとテストを確認し必要なら反復値を明示キャプチャして更新する
ループ変数の反復ごとの扱いはGo 1.22で変更され、モジュールのgoバージョンが意味論に関係します。移行時はgo vetと並列テストを使い、意図した値をクロージャ引数として明示すると安全です。
大量ファイルを読むループ内でdefer file.Close()を登録し、処理終了までディスクリプタが解放されません。適切な修正はどれですか？
答え： 1件の処理を小さな関数へ分けその中でdefer Closeする
deferは囲んだ関数のreturn時に実行されます。反復単位の関数スコープを作ると、早期returnへの安全性を保ちながら各ファイルを速やかに解放できます。
高頻度処理の一時バッファ割り当てを減らすためsync.Poolを検討しています。適切な使い方はどれですか？
答え： 消えても正しさに影響しない一時オブジェクトを置き取得時にResetする
sync.Poolのアイテムはいつでも削除され得るためキャッシュや所有権管理には使えません。プロファイルで割り当て効果を確認し、再利用時は長さ・参照・機密データをResetします。
Go 1.25以降で、複数の独立タスクを起動してすべての完了を待つ単純な処理を簡潔に書きたい。適切なのはどれですか？
答え： WaitGroup.Goで起動しWaitするがエラー伝播は別途設計する
WaitGroup.GoはAdd、ゴルーチン起動、Doneの定型処理をまとめます。エラー収集や最初の失敗によるキャンセルが必要なら、結果チャネルやerrgroup等を選びます。
並列な下流API呼出しで、最初のエラー時に兄弟処理をキャンセルし、全タスクの終了を待ちたい。適切な構成はどれですか？
答え： errgroup.WithContextで共通コンテキストを配りWaitのエラーを返す
errgroupは関連タスクのエラー伝播、キャンセル、Waitをまとめられます。ただし下流呼び出しにもグループコンテキストを渡し、ブロック中の処理がキャンセルから抜けられる必要があります。
リクエスト固有のトレースIDをcontextへ格納するライブラリAPIを設計します。キー衝突を避ける方法はどれですか？
答え： 非エクスポートのキー型を使いリクエストスコープの値だけ格納する
コンテキストキーには独自型を使うと他パッケージのキーと衝突しません。コンテキストはデッドライン、キャンセル、リクエストスコープ値向けであり、必須引数や長期設定の隠し場所にはしません。
各リクエストで新しいhttp.Clientとトランスポートを作った結果、接続数とレイテンシが増えました。基本改善はどれですか？
答え： 設定済みのClientとTransportを長期再利用しタイムアウトと上限を明示する
http.Clientとトランスポートは並行利用と再利用を前提にしています。接続再利用でハンドシェイクコストを抑え、アイドル接続数、ホスト別上限、タイムアウトをワークロードに合わせます。
外部HTTP APIのレスポンスボディを一部だけ読んでreturnするクライアントで、接続再利用が不安定です。必要な対応はどれですか？
答え： ボディを必ずCloseし再利用時は安全な上限内で読み切る
クライアントレスポンスボディは呼び出し側がCloseする責任を持ちます。巨大・無限ボディを無制限にドレインせず、レスポンスサイズ制限やリクエストコンテキストも組み合わせます。
JSON APIへ巨大なリクエストボディを送られ、io.ReadAllでメモリを圧迫されました。ハンドラ側の中核対策はどれですか？
答え： MaxBytesReader等で読取上限を強制し超過はクライアントエラーにする
クライアント申告値ではなく実際の読取量をサーバー側で制限します。ストリーミングデコーダー、フィールドバリデーション、タイムアウト、レート制限も防御in深さとして組み合わせます。
リバースプロキシ配下のGo APIでX-Forwarded-Forをそのまま監査ログとレート制限へ使っています。安全な設計はどれですか？
答え： 信頼するプロキシ境界を定めそのプロキシが正規化したヘッダーだけ使う
Forwardedヘッダーは直接接続クライアントが偽装できます。接続元が信頼済みプロキシかを確認し、プロキシで外部入力ヘッダーを除去・再設定してホップチェーンを解釈します。
database/sqlでトラフィック増加時にDB接続が急増し、DB側上限へ達しました。最初に行うプール設計はどれですか？
答え： DB容量とレプリカ数からMaxOpenConnsを制限しWait統計を計測する
sql.DBは接続プールです。全レプリカの合計がDB容量を超えない予算を設定し、DBStatsのWaitCount・WaitDuration等から飽和とクエリ遅延を区別します。
SQLのNULL可能な時刻をtime.Timeへスキャンし、NULL行だけエラーになりました。適切なモデリングはどれですか？
答え： sql.NullTime等へスキャンしValidをドメインの省略可能表現へ変換する
DBのNULLとGoのゼロ値は意味が異なります。永続化境界でnull許容性を明示し、ドメインではポインタや省略可能型など業務上の意味に変換します。
独自定義された整数型も受け取るジェネリック関数の制約を定義したい。適切なのはどれですか？
答え： 必要な演算に合わせて~intのような基底型の項を制約へ含める
~Tは基底型がTである定義型を型セットへ含めます。制約は実装で必要な演算だけを許し、広すぎるanyや不必要なリフレクションを避けます。
社内モジュールパスが公開プロキシやチェックサムデータベースへ送信されるのを防ぎ、非公開リポジトリから取得したい。適切な設定はどれですか？
答え： 社内プレフィックスをGOPRIVATEへ設定し認証済みVCSかプロキシを使う
GOPRIVATEは一致するモジュールを非公開として扱い、GONOPROXYとGONOSUMDBのデフォルトにもなります。公開依存関係のチェックサム検証は維持し、認証情報は専用ストアで管理します。
開発者とCIで異なるGoツールチェーンが選ばれ、ビルド結果が揺れています。再現性を高める対応はどれですか？
答え： go要件とtoolchain方針を明示しCIイメージと更新手順を固定・検証する
goディレクティブは言語・モジュール動作の最低要件に関係し、ツールチェーン選択もビルド入力です。パッチ更新はセキュリティ情報を追跡し、同じバージョンでテストして段階的に更新します。
タイムアウトとゴルーチン協調を含むテストがスリープ依存で遅く不安定です。Go 1.25以降で有効な改善はどれですか？
答え： testing/synctestの隔離環境で実行しWaitでブロック状態を同期する
testing/synctestはテスト対象ゴルーチンと仮想時間を隔離し、実時間スリープなしで待機条件を検証できます。バブル外のI/Oは別途フェイクや結合テストで扱います。
Go 1.24以降でベンチマークのセットアップ時間混入やデッドコード除去を減らし、測定ループを明確にしたい。推奨形式はどれですか？
答え： セットアップ後にfor b.Loop()で実行し反復内セットアップはタイマー制御する
B.Loopは外側のセットアップ・クリーンアップを測定から除外し、コンパイラによるループ内処理の不適切な除去も防ぎやすくします。入力準備が各反復に必要ならタイマーを明示制御します。
本番ワークロードのCPUプロファイルを使ってGoバイナリを最適化したい。PGO導入として適切なのはどれですか？
答え： 代表的なCPUプロファイルを収集しdefault.pgoでビルドしカナリアで検証する
GoのPGOは代表的なCPUプロファイルをコンパイラ入力にしてホットパスの最適化判断へ使います。ワークロードごとの代表性、プロファイル更新、ビルド再現性、性能・バイナリサイズの回帰を継続監視します。
リクエストごとの集計に var counts map[string]int を宣言しました。counts["ok"] の参照はできるのに、counts["ok"]++ でpanicになります。原因と修正として適切なのはどれですか？
答え： nilのmapは参照できるが書けないため、makeで初期化する
宣言だけのmapはnilです。存在しないキーの参照は値型のゼロ値を返しますが、要素の追加や更新はpanicになります。make(map[string]int) またはmapリテラルで初期化してから加算します。並行アクセスがなくても初期化は必要です。
単一のgoroutineがselectで二つの受信チャネルを監視しています。片方が終了した後も、もう片方とキャンセル通知を待ち続けたい設計です。終了を検知した側を以後のselect候補から外す方法はどれですか？
答え： 終了した側のローカル変数へnilを代入して監視を続ける
nilチャネルからの受信は進行しないため、selectではそのcaseが選ばれなくなります。終了を検知した受信側のローカル変数をnilにすると、他の入力やキャンセルを待ち続けられます。共有変数を書き換える設計ではなく、監視goroutineが所有する変数を変更します。
件数をintチャネルで受信しています。送信側は0も有効な値として送り、最後にcloseします。バッファが空になった後の終了と、正当な0の受信を区別する方法はどれですか？
答え： 二値受信のokを確認し、falseなら終了として扱う
v, ok := <-ch のokは、送られた値を受け取る間はtrueです。close後でもバッファ内の0にはtrueが付きます。閉じてバッファを読み切ると、値型のゼロ値とfalseが返るため、値そのものではなくokで終了を判断します。
処理時間のログに defer logDuration(time.Since(start)) を使うと、長い処理でもほぼ0になります。logDurationは渡されたDurationを記録するだけです。終了時点までの経過時間を記録する修正はどれですか？
答え： 無名関数をdeferし、その中でtime.Sinceを呼ぶ
deferの関数呼び出しで使う引数は、deferを登録する時点で評価されます。defer func() { logDuration(time.Since(start)) }() とすればtime.Sinceは終了時に実行されます。startは処理開始時に記録し、後から変更しない前提です。
独自の *ValidationError を上位層がfmt.Errorfの %w で包んで返しています。呼び出し元で元のエラーのFieldを取り出したい場合、適切なのはどれですか？
答え： 対象のポインタ変数を用意し、errors.Asで探索する
var ve *ValidationError; if errors.As(err, &ve) { ... } とすると、ラップされたエラーをたどり、合致するエラーをveに設定できます。直接の型アサーションは最外層だけを調べます。Fieldの参照はAsがtrueを返した分岐で行います。
database/sqlで売上行を読み、rows.Scanのエラーは毎回確認しています。しかし通信断でrows.Nextがfalseになった場合にも集計を成功扱いしていました。追加すべき確認はどれですか？
答え： ループ終了後にrows.Errを確認して成否を判断する
Nextのfalseは正常な末尾だけでなく、次の行を準備する際のエラーも表します。Scanの確認に加え、反復終了後にrows.Errを調べないと、一部しか読めなかった集計を確定してしまいます。エラーなら部分結果を完成したレポートとして公開しない設計にします。
外部APIがHTTP 503を返したのに、Goの処理は成功として記録しました。client.Doのerrがnilなら成功とする実装です。APIの契約上、成功は2xxだけの場合、必要な修正はどれですか？
答え： 通信エラーに加え、StatusCodeが2xxかを確認する
client.Doは非2xxステータスだけを理由にerrorを返しません。errの確認後、APIの成功条件に沿ってStatusCodeを判定します。503を再試行するかは冪等性や待機方針を別途考慮し、応答Bodyも適切にCloseします。
JSONの数値ID 9007199254740993 をmap[string]anyへデコードすると値が丸められました。標準encoding/jsonのDecoderを使い、int64の範囲のIDを正確に取得する方法はどれですか？
答え： UseNumberを指定し、json.Number.Int64で検証する
anyへの通常のデコードではJSON数値はfloat64となり、このIDを正確に表せません。Decodeより前にUseNumberを呼ぶとjson.Numberで保持でき、Int64の戻り値とエラーで整数・範囲を確認できます。丸めた後の型変換では失われた桁は戻りません。
同じ瞬間を示すUTCと日本時間のtime.Timeを比較しています。表示用のタイムゾーンが異なっても同じ瞬間なら一致としたい場合、適切な比較はどれですか？
答え： t.Equal(u)で比較し、同じ瞬間かを判断する
Equalは表す瞬間を比較します。==はLocationや単調時計の情報も含むため、同じ瞬間でも一致しないことがあります。文字列表現や時だけの比較も、タイムゾーンの違いや日付を正しく扱えません。
map[string]intの集計結果をfor rangeで行ごとに出力するテストが、内容不変でも順序の違いで失敗します。キーの辞書順で安定して出力する方法はどれですか？
答え： キーをスライスへ集めてソートし、その順に参照する
Goのmapの反復順序は規定されず、同じmapでも同じ順序になる保証はありません。キーを[]stringへ取り出し、sort.Stringsなどで整列してからmapの値を引くと、指定した順序で出力できます。処理中にmapが変更されない前提です。