2026.05.28 —— 今日 10 則
TODAY'S THREAD 今天偏系統底層——Go 終於讓 method 帶自己的型別參數、ZJIT 換上全域 register allocator、Zig 把 build 拆成 configurer 與 maker；同一天 Meta 把整個推薦檢索棧縮進一次 forward pass、有限射影平面被拿來重畫 Raft 的法定人數，BEAM 的 atom 表則提醒大家三分之一的 CVE 都長同一個樣——主旋律是「把某一層的成本與假設重新拆開來算一次」。
SilverTorch——把推薦系統的檢索索引寫成一個 PyTorch 模型
Meta 提出 Index as Model：把 ANN 檢索、eligibility 過濾、reranking 與多任務評分全部寫成同一個 PyTorch 模型裡的 module，在單一 forward pass、單一 GPU 上跑完，取代傳統那串各自為政的微服務。省下來的是服務間搬資料的延遲、版本不一致，以及在 PyTorch 與 C++ 兩套程式碼間來回翻譯的成本。數字很硬：比多服務 baseline 多 23.7 倍 RPS、Bloom 索引比 CPU inverted index 快 291 到 523 倍，Int8 量化下 recall 不掉，延遲仍壓在 100ms 以內。
FuzzingBrain V2——多智能體 LLM 在 12 個專案挖出 29 個 zero-day
這套多智能體 LLM 系統專攻 C/C++ 漏洞挖掘：用 Google OSS-Fuzz 做可重現驗證、靠一個基於控制流的「Suspicious Point」抽象做精準定位，再用雙層 fuzzing 與 MCP 靜動態分析工具補覆蓋率。在 AIxCC 2025 資料集上 40 個漏洞抓到 36 個（90%），實戰更在 12 個開源專案挖出 29 個 zero-day，全部被維護者確認修補、其中 2 個拿到 CVE 編號。最務實的一點是用 fuzzer 驗證壓掉 LLM 漏洞報告常見的高誤報。
Go 要支援泛型方法了——method 終於能帶自己的型別參數
醞釀多年、兩個舊提案各自破 900 個讚之後，Go 團隊正式接受讓具體型別的 method 自己宣告型別參數，語法跟泛型函式一致（func (*S) m[P any](x P)），已排進 Go 1.27。設計上刻意劃了一條線：泛型 method 不能用來滿足非泛型 interface，因為 interface 語法本來就放不進帶型別參數的 method，兩者天生互不相干。它完全向後相容、只是拿掉限制，但跟今天的泛型函式一樣不支援 reflection。
Atom 用完，VM 就掛——BEAM 三分之一 CVE 的同一個根
Erlang／Elixir 的 atom 存在一張全域、不做 GC 的表裡，填滿了整個 VM 就崩——這讓「從不可信輸入造 atom」變成一條乾淨的 DoS 路徑。Erlang Ecosystem Foundation 統計，35.8% 的 CVE 屬於這類不受控資源耗盡，String.to_atom、binary_to_atom、Jason.decode(keys: :atoms) 與動態插值的原子都是常見入口。解法是改用 *_to_existing_atom 系列、把已知值收進查表，並打開 Credo.Check.Warning.UnsafeToAtom 這類 lint。
ZJIT 換上全域 register allocator——SSA 上的線性掃描
Ruby 的新 JIT「ZJIT」把舊的 block-local 配置器換成跨基本塊的全域線性掃描配置器，做法依循 Wimmer 的「Linear Scan Register Allocation on SSA Form」。舊做法只看單一基本塊的生命週期，每到塊邊界就得把所有活著的值搬到固定位置給下一塊接手；全域配置直接省掉這些來回搬運。更關鍵的是 method inlining 重度依賴這種全域視野，等於替後續最佳化先鋪好路。
Zig 重寫 build system——把 configurer 與 maker 拆開
Andrew Kelley 把 Zig 的 build 拆成兩段：Debug 模式編的「configurer」負責跑你的 build.zig、把 build graph 序列化成二進位設定檔，Release 模式編一次的「maker」再讀檔執行。好處是改設定時只重編你的 build 邏輯、不再連整個 build system 一起編，加個 -freference-trace 之類旗標甚至能跳過重跑。zig build --help 的牆鐘時間從 150ms 砍到 14.3ms、CPU cycles 從 5.93 億降到 2410 萬，代價是 b.args 改走 addPassthruArgs 的破壞性變更。
用有限射影平面重畫 Raft 的法定人數
標準 Raft 要求多數決，這篇改用「有限射影平面」導出的投票區塊（bloc）當法定單位——射影平面的任兩條線必相交於一點，正好保證任兩個 bloc 至少共用一個節點，於是 Raft 的安全性原封不動。在 7 節點用 Fano plane，一個 bloc 只要 3 個節點就能提交，少於多數決的 4 個；57 節點則是 8 對 29。代價也很誠實：它不再保證「多數活著就能前進」，57 節點在 29 個隨機存活時落在合法 bloc 的機率只有約 15%。
NGINX Gateway Fabric 2.6——把 F5 WAF 帶進 Gateway API
NGINX Gateway Fabric（Ingress Controller 的接班人）在 2.6 把 F5 WAF 接進 Kubernetes Gateway API：SecOps 可以編好 WAF policy、透過管理平面或 HTTP endpoint 取得，再掛到 Gateway 與 HTTPRoute 上，不必再外接一套 WAF。這版同時補上 ListenerSet（把 port／TLS 設定從 Gateway 解耦）、給入站流量的 FrontendTLS client mTLS，以及 ProxySettings 的逾時指令。官方說這是把企業級安全能力放進 Gateway API 標準的第一步。
動畫該交給 CSS 還是 JS——關鍵在主執行緒之爭
Josh Comeau 把動畫的選擇收斂成一個判準：誰在主執行緒上跑。CSS keyframes 跑在獨立的合成執行緒，JS 卡住時動畫照樣順；純 requestAnimationFrame 與 GSAP 這類在主執行緒上算每一幀的做法，就得跟整個 app 搶 CPU，一卡就掉幀。有趣的是 Motion 用 Web Animations API，所以它跟 CSS 一樣能離開主執行緒——作者的結論是能用原生 CSS 就用、需要時才上 Motion，只包一層抽象卻沒帶新能力的函式庫不值得。
PostgreSQL 鎖的 5 個地雷——SELECT 為什麼會卡在 ALTER TABLE 後面
這篇拆解 PostgreSQL 18 五個反直覺的鎖行為：ALTER TABLE 的 ACCESS EXCLUSIVE 會讓後面排隊的 SELECT 一起卡死，因為鎖佇列是 FIFO，新請求即使不衝突也得跟著等。外鍵 INSERT 會偷偷拿 parent row 的 FOR KEY SHARE 鎖、唯一約束的併發插入會互等成死結，連 VACUUM 的 truncate 階段都會短暫升級成 ACCESS EXCLUSIVE。最毒的是防 wraparound 的 autovacuum——它不讓步、也不會被自動取消，一旦卡在鏈條最前面就誰都別想動。
today's deep reads
Index as Model——Meta 把推薦檢索棧縮進一個 PyTorch forward pass
當檢索、過濾、reranking 與評分各自是一個微服務，慢的不是模型而是服務之間搬資料。SilverTorch 把整條檢索棧寫成同一個 PyTorch 模型，會換來什麼？為什麼 Bloom 索引能比 CPU inverted index 快上百倍、Int8 量化又能不掉 recall？23.7 倍 RPS 的背後，犧牲與限制各是什麼？
Atom 用完，VM 就掛——拆解 BEAM 那張全域 atom 表
atom 到底是什麼，為什麼它不被 GC、又為什麼一張表填滿整個節點就崩？從不可信輸入造 atom 怎麼變成一條乾淨的 DoS，而它又怎麼累積成 EEF 三分之一的 CVE？哪些函式是入口、*_to_existing_atom 與查表為什麼是正解，邊界該怎麼守？
CSS 還是 JS 做動畫——勝負在主執行緒之爭
為什麼同一個動畫，CSS 在 JS 卡死時還能順順跑、純 requestAnimationFrame 卻會掉幀？合成執行緒與主執行緒的分界線到底劃在哪，transform／opacity 為什麼特別？Motion 靠 Web Animations API 拿回 CSS 的優勢，而只包一層抽象的函式庫又輸在哪裡？