道地 Go 語言 Enum 與 Union 實踐方式
Go 既沒有 Enum（枚舉）也沒有 Union（聯合）的關鍵字，因此會使用現有的語言特性來達成相同的效果。藉由研究其他語言如 TypeScript 來了解如何重現相同的特性。Enum 組合 (const + iota)與Union 組合 (interface + struct)。
Go 既沒有 Enum（枚舉）也沒有 Union（聯合）的關鍵字，因此會使用現有的語言特性來達成相同的效果。藉由研究其他語言如 TypeScript 來了解如何重現相同的特性。Enum 組合 (const + iota)與Union 組合 (interface + struct)。
最近用到 Go 官方 uuid 庫產生 UUID v7 時候留意到一種使用方式是：Must，他的描述也很簡單：Must returns uuid if err is nil and panics otherwise. 用途是「當錯誤不是一個可以恢復的選項時」，使用包裝好的 `Must` 直接 panic 錯誤。
你有遇過格式不一的後端專案嗎？近期在翻新某個 Go 後端專案痛苦的因素就是請求與回應格式不一，這是一個很直白且簡單的問題，但實際會造成很大的困擾。藉由定義完整的 Agent Skills 文件與 goal 來自動達成目標。
最近在撰寫的 Go 後端使用到大量的本地檔案存取，其中最需要被防範的問題之一就是「路徑遍歷」。而在 Go 1.24 新增了 `os.Root` API 簡潔優雅的避免安全問題。可以考慮所有 `os.Open` 的使用情境是否安全，並替換上 `os.Root` 確保「操作不應存取該目錄之外的檔案」。
服務通常會經過各種代理轉發請求，但當我們要做判斷請求身份、審計日誌、一切與來源請求 IP 相關的功能時要如何拿到正確的資訊？記錄一下我根據 Go Gin 受信任代理文件學習到的最佳安全實踐。與同事討論讓我反思並挖掘真正設置所謂 `ClientIP` gin 做了哪些策略讓 ip 獲取是安全合理的。
還記得小時候的電腦都是 32-bits 的系統，大約在 win7 的時代已經逐步的替換成 64-bits 系統了，但我還是不了解具體來說有什麼差異，只記得有段時間有兩種軟體規格可以選擇，或是某些軟體需要用「兼容模式」來執行。
當處理多個加解密應用時我納悶：「多一份金鑰需要管理，意味著多一個需要防守的東西」、「如何避免用戶使用一串非常簡單的金鑰讓破解變得非常容易」。而正好有個專門的算法：金鑰衍生函式 Key Derivation Function 正是為此類問題而生。
在學習 Go 時會了解到 `struct` 其實就是一串自訂的資料結構，而其中欄位的「順序」將直接影響到在記憶體中所佔用的實際大小甚至程式的速度。了解記憶體對齊的概念除了「節省空間」外也能為打造「更佳的緩存局部性（Cache locality）」。
近期在開發 Go 專案時發現到提交代碼流程總是有些摩擦，像是開發時習慣用 Tab 到 GitLab 上寬度就會變得很奇怪，或是一些簡單的對齊問題都在無形消耗專注力。所以透過把一些原生的 Go 靜態檢查工具搬到 CI 上執行，確保統一的開發體驗。
最近有較多的時間思考開發上的最佳實踐，考慮到目前開發的一個後端項目基本就是拿 go 原生的 log 到處打印儲存片面狀態而已。在閱讀一些文件與最佳實踐後，我想著手改善現有的 logging 體驗透過導入 Go 1.21 引入的原生 slog 庫。
大多程式都可以採取「並行 Concurrency」的方式來達成簡單安全且高效的運行，但隨著多核 CPU 出現以及特定場景對於效率的追求「平行 Parallelism」運行程式是另一個提高運行效率方向。本文練習透過 Go 複習平行程式開發下資料存取相關技巧：原子操作、鎖、信號量⋯⋯
Redis 是十分常見的 In-Memory 資料庫，工作上時不時會碰到它但很少仔細從頭了解它，所以透過撰寫重現一些案例達成更深刻的理解。快取就是把常存取的資料放在能夠快速獲取的地方，缺點是記憶體不像硬碟適合長久保存資料，但不管是提高速度、降低延遲、降低負擔或減輕成本⋯⋯快取都是很棒的選擇。
相較於 C 讀取未定義數值的變數會造成安全漏洞或崩潰，或是動態語言如 JavaScript 沒有數值型別初始化的問題，Go 的設計上就自動賦予了確定意義的數值避免出錯與創建即可使用。具體來說在例如使用 json 反射的標籤中 `omitempty` 也正是運用了 Zero Value 的概念來判斷。
雖然在 AI 出現之前很難想像，但 2026 年工作上我已經很少「手寫程式」而是透過 AI 更有效率的輔助開發，我相信在 AI 百家爭鳴的時代不用特別執著用哪個模型或工具，挑個最新順手的免費方案就夠了，未來模型只會更便宜更有效率。
前端測試主要重點在與瀏覽器打交道（Jsdom、Headless Browser）且通常只與單一後端進行溝通，而後端測試則是面臨截然不同的難題：分散服務與狀態。這篇文章介紹實戰上我如何透過 Testcontainers 創建 Docker 測試環境來達成完整的後端整合測試流程。