2026.09.04 —— 今日 10 則
TODAY'S THREAD 今天三篇深入文章講的都是同一種取捨：把成本從一個地方搬到另一個地方，然後量它有沒有真的變小——Meta 把百萬 client 的連線收進一層 proxy，每台主機的連線少了九成七；gingerbill 把型別資訊從編譯期搬到執行期，指數換成線性；瀏覽器那篇則是把工作搬離主執行緒，換來的預算只有一幀十毫秒左右。
agent 的護欄，不能放在 agent 自己的迴圈裡
Docker 把 1988 年的 confused deputy 問題重新套到 coding agent 身上：agent 繼承使用者的憑證與 repo 權限，但行為是機率性的，會照著 support ticket、網頁、文件裡的指令走。他們舉的例子是一則惡意 GitHub issue 把 agent 誘去讀私有 repo，再用一個 PR 把內容送出去——護欄若寫在 harness 裡，agent 可以在同一個迴圈裡跟它談判。Docker 的主張是把強制點下沉到 runtime 層，也就是 process 執行、憑證使用、網路請求真正發生的地方，換到的是跨 harness 的單一政策與單一稽核紀錄。
讓模型自己宣告要看哪一段 context
現行 sparse attention 其中一條主流路線是靠外部 proxy score 先挑 token，每一步仍是 O(N)；這篇提出的 Declarative Attention 換個方向，讓模型在 chain-of-thought 裡自己宣告注意力範圍，分成 <global>、<focus>、<local> 三種模式，推論引擎像解析 tool call 一樣讀這些宣告，然後跳過大半 KV cache。在 15 項 long-context 任務的 zero-shot 評測裡，Gemma-4-31B 與 Qwen-3.6-27B 分別少讀 52.0% 與 31.1% 的 token，準確率各掉 1.27 與 2.75 個百分點。作者說這個差距會隨模型規模縮小，而且整套方法不需要重訓——直接套在 off-the-shelf 模型上。
編譯期展開是指數，執行期查表是線性
gingerbill 反對把 compile-time type information 當成零成本：接受 K 個型別參數的程序，在 N 種型別下最多會長出 N 的 K 次方份實體，他用一個四型別的列印系統示範，限制五個參數就是 1,365 份實體，多一個型別變成 3,906 份，再放寬到六個參數就是 19,531 份。文章的核心句子是 CTTI 的最壞情況「exponential, in three places at once」——語意檢查、程式碼產生、二進位大小三處同時爆。相對地 RTTI 是一支程序走一張放在唯讀記憶體的型別表，程式碼大小固定，只有表隨型別數線性成長。
Go 的 map 換成 Swiss table 之後，探測變成一次比八格
Go 1.24 起 map 底層改成 Swiss table：每 8 個 key-value slot 組成一個 group，雜湊值拆成上 57 位的 H1 與下 7 位的 H2，H2 存進 control byte，查表時用 SIMD 一次比對 8 個 control byte 得到候選 bitmap。滿了之後走三角探測序列（+1、+2、+3⋯），保證每個 group 恰好走過一次；再上層用 directory 與 global/local depth 做可擴充雜湊，table 到 7/8 載入率就分裂。舊設計那條 overflow bucket 鏈每多一個 bucket 就多一次指標載入與掃描，這正是被換掉的東西——Go 團隊的微基準是 map 操作最多快 60%，但整體應用的幾何平均 CPU 時間只改善約 1.5%。
資料庫前面加一層，連線的扇入不再跟著 client 數長
ZippyDB 原本讓上百萬 client 各自對數十萬台主機開 TLS 連線，Meta 描述過一次事故：一個路由 bug 讓每個 client 對每個 shard 都開了連線，主機撞上 file descriptor 上限，整個 fleet 陷進重新啟動的迴圈。ZGateway 是擺在中間的無狀態 proxy 層，跑的是 Meta 自家的 C++ ZippyDB client，負責終結 TLS、做 per-tenant 准入控制、把同 shard 的請求批次化與去重。代價是多一跳與多一層要維運，換到的是每台主機連線數降約 97 到 98%、總長連線數降約 19 倍，計算開銷約 6%，目前承載四成 ZippyDB 流量，能撐每秒十億次以上的操作。
NGINX 讓 location 可以用變數當條件，也能先讀 body 再決定路由
1.31.5 把四件事一起放進來：predicate location 讓 location $var 用任何求值結果當比對條件，不再只看 URI；client_body_early_read 允許在 location 比對之前就緩衝並解析請求本體；新的 JSON parser 用 json_set $var $request_body "key" 把欄位直接抽進變數，不必寫腳本；原本屬於 NGINX Plus 的 Control API 也進了開源版，走 /1/control/processes 與 /1/control/config 做執行期查詢與重新載入設定。前三者合起來的意思是 payload-direct routing——依 JSON 內容而不是端點路徑分流。Control API 沒有認證，官方的建議是綁在只有特權使用者能觸及的 UNIX domain socket 上。
主執行緒的一幀，實際只剩十毫秒左右可以花
JavaScript 執行與畫面渲染（樣式計算、版面、繪製）共用同一條主執行緒，60Hz 下一幀預算是 16.6 毫秒，扣掉瀏覽器自身開銷實務上只剩約 10 毫秒，而超過 50 毫秒的任務一般就算有問題。文章示範一個 200 毫秒的阻塞任務會凍住所有互動，然後把手段分成兩類：在主執行緒上切分、批次、排序、延後，以及把工作搬去 Web Worker 或交給合成器執行緒——CSS 動畫在 JavaScript 卡住時仍然順暢，正是因為它不在主執行緒上跑。
.name 第三級網域整層被取消，作者的站二月先消失
Verisign 在 2026 年 4 月 15 日提案取消所有第三級 .name 網域，ICANN 於 7 月 28 日核准，作者從註冊商的信裡才得知，而他的網域其實付到 2040 年。受影響的約有 22,000 個網域持有者，作者最在意的不是網站消失，是用了二十五年的 email 位址失效之後，空出來的 fraser.name 可以被別人註冊——拿它去做帳號接管，而且沒有任何機制能列舉出有哪些服務綁著那個位址。他強調 .name 不是那種來路不明的第三級操作方，而是跟 *.co.uk、*.ny.us 同性質、受規範的註冊管理機構。
把一次 schema 變更拆成六段，中間不必停機
Azure SQL 團隊把 expand-and-contract 拆成六個階段走完：先用 ALTER TABLE 加可為 null 的新欄位，接著應用端同時寫新舊欄位，再用 TOP 1000 分批 UPDATE 回填歷史資料避免長鎖，然後靠 feature flag 分批把讀切到新欄位，停掉舊欄位的寫入，最後才 DROP COLUMN。關鍵不在任何單一 DDL，而在新舊版本應用程式必須在整段過渡期裡同時能跑。他們也提到用 Query Store 觀察舊欄位還有沒有人在讀，但同時說單一工具都不完整，要合併多種方法。
測試也跟著 Native AOT 一起裁，才算測到出貨的那份
MSTest 加上 source generation，在編譯期就把測試清單、建構測試類別與呼叫測試方法的委派、以及裁剪時要保留哪些型別的參照全部產生出來，取代執行期的 Assembly.GetTypes() 掃描。動機寫得直白：應用程式若用 Native AOT 出貨，一次綠燈的 managed 測試 run 其實留了一個缺口——測的不是實際部署的那份。開啟方式就是在專案檔把 PublishAot 設成 true；文章沒有給啟動時間或二進位大小的數字，並明說「Performance is secondary」。