Blogs

前言 開始之前先看這支影片，講的是 Quake III 那個 0x5f3759df。它跟本文沒有直接關係，但用的是同一類招式：把浮點數的 bit pattern 當成整數讀，用整數的乘加移位取代超越函數。差別在於那一招接受 3.4% 的誤差，而本文接下來要講的東西，一個 bit 的誤差都不能有。這個對照後面定點對數那節會再回來收。 TL;DR 中間一大段是演算法拆解，有興趣再啃。只想知道「Go 1.27 實際上改了什麼、變多快、輸出有沒有跑掉」的話，可以直接跳到 Go 1.27 到底改了什麼，結論是 878 行三套演算法變成 290 行一套、快了 11–21%、輸出零變化。如果你在意的是「那我平常記帳該用什麼」，跳到 附錄，那一節比較了 float64、math/big 三兄弟與 shopspring/decimal。 我把 Go 升到 1.27 之後，照慣例翻了一遍 release notes，也寫了新特性整理。整份文件從頭到尾沒有一個字提到 strconv。 但是 Go 1.27 把 fmt.Sprintf("%v", f)、strconv.ParseFloat、json.Marshal 底下那顆浮點數轉換引擎整個換掉了。舊的實作是三套演算法各自為政：最短列印用 Dragonbox、固定位數列印用 Ryū 風格的程式碼、解析用 Eisel-Lemire，新的實作是一個叫 unrounded scaling 的東西，作者是 Russ Cox，論文是 2026 年 1 月才發表的。 這件事之所以值得寫一篇，是因為 Russ Cox 在 2011 年寫過一篇 Floating Point to Decimal Conversion is Easy，副標題是 Part 1。文章的論點是： ...

前言 事情是這樣開始的。 我請 agent 幫忙加一個 endpoint，它三分鐘寫完，handler 乾淨、error handling 完整、unit test 也跟著補齊，go test ./... 全綠。此時我想到的是，agent 真的有做完嗎？route 真的有被註冊嗎？ 換成三年前的我，也會漏，那要怎麼樣讓 Agent 不會漏？這個系統從一開始就沒有任何機制能發現有人漏改。以前它靠的是 reviewer 的眼力與同一批人的肌肉記憶撐著；現在把產出速度乘上十倍，這條防線就直接被沖垮了。這不是 agent 的問題，是架構債被提早引爆。 這篇想記錄的，就是後來把這個服務從 code-first 遷移到 spec-first 的過程：用 OpenAPI 當單一真值來源(SSOT)，用 oapi-codegen 產生 typed interface，讓 compiler 與 CI 去做原本靠人記憶的事情。 問題不是「有三份檔案」 遷移前，同一條 API 的定義散落在三個地方： infra route definition ← path / method / authorizer cmd/*/main.go ← mux.HandleFunc 手寫註冊 Go swag comments ← @Router / @Param / @Success 三份檔案本身不是問題，同一個概念散在多個檔案是常態。 真正的問題是，它們彼此不知道對方存在。 改 path，可能只改到 Go route，忘了 infra；改 response shape，可能只改 handler struct，忘了註解；授權設定只活在 infra 層，Go 跟 OpenAPI 都不知道有這回事。而 swaggo 的註解在 repo 裡形同空轉，它是「程式碼的產物」，而我們沒有任何機制拿它回頭驗證程式碼。 ...

半年前寫完 Go 1.26 新特性 那篇，文末問了一句「準備好更新你的 go.mod 到 go 1.26 了嗎？」，沒想到一轉眼 Go 1.27 也要來了。撰文的當下 Go 1.27 即將正式發布，以下內容是根據 release candidate 整理，如果正式版有微調，還是以官方 release notes 為準。 如果說 Go 1.26 給我的感覺是數量多、廣度大，那 Go 1.27 更像是把之前欠的債還一還。generic method 從 issue 一路等到現在終於落地，goroutineleak profile 從需要 GOEXPERIMENT 才能開的實驗功能轉正成預設行為，encoding/json/v2 也從實驗畢業成為預設實作。這篇就挑幾個我覺得值得記錄的改動來聊聊。 語言層面：泛型設計的最後一塊拼圖 Generic Method 真的來了 這件事我在 Go 1.27 即將支援 Generic Method 那篇已經寫得很詳細了，這裡就不重複展開，只放結論：method 現在可以宣告自己的 type parameter，不用再繞道用 package-level function 把 receiver 當參數傳進去。 type List[T any] struct { items []T } func NewList[T any](items ...T) List[T] { return List[T]{items: items} } // MapTo 是 generic method，帶著自己的型別參數 U， // 跟 receiver 的型別參數 T 是兩回事。 func (l List[T]) MapTo[U any](f func(T) U) List[U] { out := make([]U, len(l.items)) for i, v := range l.items { out[i] = f(v) } return List[U]{items: out} } type Cat struct { Name string Age int } cats := NewList(Cat{"Mittens", 3}, Cat{"Tama", 5}) names := cats.MapTo(func(c Cat) string { return c.Name }) fmt.Println(names.items) // [Mittens Tama] 老話一句：interface 目前還是無法宣告帶 type parameter 的 method，這是 dynamic dispatch 架構性的限制，不是漏掉沒做。想看完整的來龍去脈跟 workaround 的比較，去讀前面連結的那篇。 ...

前言 Go 1.18 帶來泛型之後，我們終於可以寫出型別安全的通用函式，不再需要到處 interface{} 加型別斷言。但一個眾所周知的限制一直存在到現在，method 沒辦法有自己的 type parameter。 換句話說，這段程式碼在目前的 Go 版本中是非法的： func (c *Client) doRequest[T any](ctx context.Context, method, path string, body any) (*T, error) { // 編譯錯誤：cannot use generic method doRequest without instantiation } 為了繞過這個限制，大家只能退而求其次，把 receiver 當作普通參數傳進去，改用 package-level 的 generic function。 最近 Go issue #77273 的進展讓這件事有了轉機，generic method 的設計已被接受，預計在 Go 1.27 正式釋出。 為什麼現在沒有 Generic Method？ 這不是 Go team 沒想到，而是刻意的設計決策。 Go 的 interface 是核心功能，method 必須能夠被 dispatch 到具體的實作上。如果 method 自身帶有 type parameter，編譯器在 dispatch 時需要知道 T 是什麼，這在動態 dispatch（interface dispatch）的情境下是個難題，runtime 無法事先知道要生成哪個型別的實例化版本。 所以泛型剛推出時，generic method 被刻意排除在外，等待一個比較完整的設計方案。這個等待從 Go 1.18 一路等到了 1.27（暫定）。 ...

前言 我的 Homelab 跑著一台 Proxmox VE，底下有一個 Ubuntu Server 24.04 的 VM 負責跑 k3s cluster，這個 cluster 接管了家裡所有的自架服務：從 Vaultwarden 密碼管理、Karakeep 書籤、Filebrowser 文件管理，到 Wakapi 開發時間追蹤，大大小小跑了十幾個服務。 這個架構一直跑得很穩。直到 Linux kernel 7.0 發布，我才開始動搖。 kernel 7.0 的各種新特性讓我心癢，Ubuntu 26.04 LTS 剛好以 kernel 7.0 作為預設核心，理論上從 24.04 升上去就能一步到位。但在一個跑著十幾個服務的生產 VM 上執行 do-release-upgrade，那種心臟發抖的感覺，即便有做好備份，還是讓我遲遲下不了手。 就在猶豫要不要升級的當下，我問了自己一個問題：「我要繼續用 Ubuntu 嗎？」 這個問題打開了一扇門。我的 Linux desktop 是 openSUSE Tumbleweed + KDE Plasma，用了三年、換過兩台裝置（筆電和桌電），沒有遇到太多問題。Tumbleweed 的滾動更新讓我一直跑著最新的 kernel，升級這件事從來不是一個需要另外排行程的壓力事件。 既然 desktop 側已經對 openSUSE 生態有信心，server 側為什麼不試試看？ 這讓我開始認真考慮：有沒有一種 OS，讓 server 的升級這件事也變成「預設安全」而不是「需要勇氣」？ 為什麼選 OpenSUSE MicroOS OpenSUSE MicroOS 是一個 Immutable OS（不可變作業系統），核心特性有幾個： ...

前言 在大型系統或需要長期維護的產品中，導入 DDD（Domain-Driven Design）或 Clean Architecture 幾乎是業界的標準答案，分層清晰、職責明確、可測試性高，這些優點毋庸置疑。 但問題是，不是每個專案都是大型系統。 當你面對的是一個內部工具、side project、或是剛起步的新產品，Clean Architecture 的大全套 Use Case、Port、Adapter、Aggregate、Repository Interface 全放 domain，往往會讓你在還沒寫第一行商業邏輯之前，就先在資料夾結構裡迷路了三個小時，或是讓不熟悉的貢獻者花費大量時間在閱讀架構。 這篇文章想討論的是：在不犧牲可測試性與可維護性的前提下，哪些抽象可以捨棄、哪些值得保留，以及我自己踩過的一些坑。 捨棄什麼 獨立的 Port/Adapter 層 Clean Architecture 中，Use Case 透過明確定義的 input/output port 與外界溝通，搭配 Adapter 負責格式轉換。這在大型系統中確實有其價值，但它帶來的代價是：為了讓每一層都能獨立替換，你需要維護大量的介面與轉換邏輯，而這些轉換邏輯往往只是把 A struct 的欄位複製到 B struct。 在小專案中，這條轉換鏈可以大幅縮短。HTTP handler 本身就可以負責 DTO 的轉換，不需要再多一層 Adapter。 DDD 的 Aggregate Aggregate 是 DDD 中保護業務不變式（invariant）的邊界，透過 Aggregate Root 統一管理相關物件的存取。這個概念本身沒有問題，但在小專案中，如果業務規則還不夠複雜到需要嚴格的不變式保護，過早引入 Aggregate 反而會讓簡單的 CRUD 操作變得冗長。 保留什麼 捨棄了部分複雜度之後，剩下的四層架構已經足以應付絕大多數的小專案需求。 package domain 這裡只放 Domain Model 與 Value Object。 值得特別說明 Domain Model 的定義。它不等同於 DDD 裡的 Domain，不是什麼深奧的設計概念，Domain Model 只是在描述「這個應用程式如何跟外部世界互動、邊界在哪」，也就是你的核心資料結構與它們身上的行為。有些「賣課」的人喜歡把 Domain Model 直接等同於 DDD 的 Domain，實際上它是個更基礎、更普遍的概念，可以參考這支影片的解釋。Domain Model 中不需要也不該出現任何技術細節，例如回傳是否是 JSON 等等，這些 Domain Model 甚至要能讓 PM 與非技術人員也「聽的懂」。 ...

TL;DR 馬上就看到有小王八蛋想壞壞 前言 2025 年 11 月，Kubernetes SIG Network 發布了一篇公告：ingress-nginx 將正式退役。 這個消息讓不少人震驚，但嚴格來說有個細節需要釐清。目前市場上有兩個長得很像的 nginx ingress controller： kubernetes/ingress-nginx：由 Kubernetes SIG Network 維護，這次宣布 EOL 的就是它。 nginx/kubernetes-ingress（又稱 NKS）：由 F5 / NGINX Inc. 維護，目前仍持續開發中。 我的 homelab k3s cluster 一直以來用的是 F5 維護的版本，嚴格來說不在這次 EOL 的範圍內。但這個公告還是給了我一個動力，與其繼續追蹤兩個版本之間的差異、擔心哪天又有什麼變化，不如趁這個機會把遷移一次做完。 遷移目標選定 Traefik v3，原因有兩個： k3s 內建 Traefik 作為預設 Ingress Controller，1.32 版本後升級為 Traefik v3，搭配 HelmChartConfig 管理，和 cluster 的整合度最高。 順手引入 CrowdSec 主動防護——長期以來我的服務靠著 Cloudflare proxy 當唯一守門人，但我一直想要在 Ingress 層就能即時判斷並封鎖攻擊者 IP，而不只是依賴前端的 CDN 過濾。 為什麼不選 Cilium Gateway API 在決定遷移到 Traefik 之前，我也閱讀了 Gene 的告別 ingress-nginx：Cilium Gateway API 遷移筆記，評估過 Cilium Gateway API 方案。Cilium 在 CNI 層整合了 Gateway API，理論上能提供更底層、效能更好的流量控制，且完全符合 Kubernetes Gateway API 的標準規範。 ...

前言 如果你有認真對待自己的資料，應該聽過 3-2-1 備份原則： 3 份備份 2 種不同的儲存媒介 1 份異地備援 前兩項在家中的 Homelab 環境相對容易做到，但「異地」這個字往往是大多數人的盲點。硬碟壞掉？用 Proxmox Backup Server (PBS) 還原。系統崩潰？從 PBS 拉一份回來。但若是家裡發生火災、淹水，或是更平凡的情況——你不小心把整台 Proxmox VE 的 NVMe 連資料一起刪掉——這時候同一個屋簷下的所有備份都會跟著陪葬。 我的 Homelab 環境是一台 Proxmox VE 搭配一台 Proxmox Backup Server，跑著包含 k3s、Vaultwarden 等各種服務。在研究了很久的異地備援方案後，我決定在歐洲架設一台 PBS，讓它透過 WireGuard 隧道主動把家裡的備份「拉」過去，讓 321 中的那個「1」真正落地。 這篇文章會記錄完整的架構決策過程，從為什麼選 Hetzner、選哪個方案、到實際的設定步驟，以及中間踩過的坑。 為什麼選 Hetzner Hetzner 是一間位於德國的基礎設施供應商，在評估異地備援的雲端供應商時，我的優先考量是：便宜、隱私安全、技術友善。 GCP / AWS 的問題 第一個念頭當然是最熟悉的 GCP 或 AWS，畢竟都是主流雲端。但把兩者丟進計算機後，答案很快就出來了： 以我「最終」需要的規格： 2 vCPU / 4GB RAM VM 80GB 高速 Storage 用於 PBS 備份 500GB 慢速 Storage 用於 NAS 備份 方案 預估月費 Hetzner- CX23- 80GB Volume- BX11 Storage Box 約 $15.73 USD AWS 同級配置- t3.medium- gp3 80GB- S3 500GB 約 $50 USD GCP 同級配置 相近 光是這個差距就已經結案了。AWS 和 GCP 的小型運算實例本身就已經比 Hetzner 貴好幾倍，Block Storage 的單價更是幾乎翻倍，再加上對外流量費用（下載資料還要另外收），災難復原時光是把 500GB 拉回來就可能要多付幾十美元。 ...

Web 仔要有 Web 仔的自覺 前言 前陣子收到了 Murphy 的需求，嘗試使用 Tauri 寫了一個桌面 App。Tauri 結合 Rust 與 React 的體驗相當不錯，打包出來的體積也十分理想。 但身為一個主要撰寫 Golang 的後端工程師，內心總有一個聲音：「如果能用 Go 來寫桌面應用，那該有多好？」 眾所周知，Golang 在原生的 Desktop GUI 框架上一直沒有特別強勢的殺手級專案（過去使用 Fyne 的經驗不算太好）。在環顧了一眾基於 Chromium 的 Electron 或是基於系統 WebView 的 Tauri 後，決定走一條稍微不一樣的「老路」：使用 Wails 搭配 HTMX 與 Templ。 最終的產物就是 Dub 一個跨平台的批次檔案重新命名工具。更甚，在 Linux 上打包出來的可執行檔只有約 3MB，並且完美支援 macOS 與 Linux，且幾乎沒有複雜的前端狀態管理負擔。 為什麼是 Wails + HTMX？ 在選擇桌面應用程式的技術方案時，我們通常有幾個考量 Electron: 開發體驗極佳，生態系最豐富，但代價是動輒上百 MB 的體積與高昂的記憶體佔用。對於一個小工具來說，太過沉重。（這也是我優先選擇 Zed.dev 作為主要編輯器的原因） Tauri: 效能極佳，體積小，但後端需要寫 Rust。雖然 Rust 很香，但有時候只想用最熟悉的 Go 快速把邏輯刻出來。 Wails: 與 Tauri 類似，採用前端網頁技術結合系統原生 WebView，但後端語言是 Golang。 既然選了 Wails，前端該用什麼？ 現代前端框架（React, Vue, Svelte）通常需要建置複雜的 SPA（Single Page Application），並透過 JSON API 與後端溝通。但對於一個狀態並不複雜的工具軟體，不想在前端再維護一份狀態。 ...

在 2025 Recap 的展望中寫下了「與 +1 首次踏足國外」，沒想到兌現的速度比預期快得多，2026 年的第二天，我跟 Murphy 就站在了關西國際機場。 會選擇日本關西作為首次出國的目的地，原因很單純：我們都各自來過，作為初次日本自由行，熟悉的地方還是比較安心。加上 2025 年 10 月才從五十音開始學日文，正好拿這趟旅程來驗收 N87 的日文實力（？ 五天的行程，從京都走到大阪，從零度的細雪走到通天閣的暖陽。這篇拖了快兩個月才動筆的遊記，就當作是對這趟旅程的交代吧。 Day 1（1/2）：初雪與初売り 搭乘星宇航空 JX820 班次，Airbux A330-900neo 機型，這次旅行選擇星宇也是為了體驗 Airbus 的飛機。11:10 分落地後，11:20 分就開始排隊出關（這邊禁止拍照），11:40 順利出關拿完行李！原本預計出關會要約莫一個半小時，訂了 12:44 分的 JR Haruka 由於關西國際機場極高的效率讓我們在機場空等了一小時 XD。 由於吃了暈機藥，在 Haruka 時仍持續處於昏迷狀態，抵達京都時已經下午兩點，隨即轉乘烏丸線到烏丸御池站，出站走了一小段路就到了這兩晚的住所，Hotel Resol Trinity Kyoto（京都RESOL TRINITY酒店）。 我與 Murphy 在這次旅行的分工是，我負責京都部份，Murphy 負責大阪部份，而京都的住宿，我只花了半小時搜尋「京都 住宿 ptt」就搞定了，我並沒有過多研究 Hotel Resol 整體的歷史等等，單純是因為飯店的窗戶有一個紙門設計，我就被迷惑了。好在運氣始終不錯，當從京都的大馬路上轉進小巷子，一間外裝不太起眼的飯店映入眼前，進入飯店後裝潢與外裝截然不同，雖然知道他是ホテル但濃濃的りょかん味，特別是一樓還有大浴場，這兩天我都在這邊洗澡，所以並沒有感受到評價所說的「浴室很小」的感覺。由於是新年期間，附近的學校也跟著放假，大廳還提供了原先供應給學校的鮮乳，屬實幸運。 下榻的飯店距離錦市場只有十分鐘的步行距離，放完行李後，緊接著步行前往藤井大丸，體驗日本新年的「初売り」，此時室外的溫度零度，天空飄下了細雪，即便十分興奮，還是會擔心外套濕掉。我高估了我耐寒的能力，只穿了短袖、中層與棉質的薄外套就來了這零度的京都，Murphy 在大丸買了件新的羽絨外套後，我就把他身上的搶過來穿，撐過了這幾天。買完戰利品後先回到飯店放下，畢竟我們接下來還有行程，這就是飯店距離商圈近的好處。 ...