📝 筆記

逐字抄、整齊存起來是把負荷卸到紙上（跑步跳上車）；在紙上猜關係、重排、修正才是讓紙面扛記憶、大腦專心理解。

這樣對起來記，口訣就不只是口號，而是每次寫筆記時的三個自檢問題。

要求它正確等於要求自己在思考前就想完，紙面反而沒分擔任何負荷，於是陷入 analysis paralysis。

一開始排整齊等於偷偷在做分類決定；不確定的口吻讓之後讀到相關內容時大腦自動去核對，這就是 priming 運作的方式。

所以不是開始前的心理建設，而是那一刻提醒自己：不是在做傑作，只是在整理思緒。

作者說 AI 讓 reference notes 過時，理解成「必要性大幅下降」比「完全不需要」穩：版權書、課堂口述、需精確引用時摘錄仍有價值。

研究的關鍵變因是「有沒有經過自己改寫整理」而非字數本身；不經處理的長筆記才是問題。fast / examine / guess 對別人無資訊量，對寫的人足以喚回整句。

變亂和發現錯誤不是副作用，是方法故意製造的兩個觸發條件。作者的例子：explicit memory 按能否被意識到分，working / long-term 按保存時間分，分類軸混用才會重疊。

局部修補只重新處理被改到的幾個點；整張重畫等於把猜連結的動作對全部內容再做一遍，這才是「重整強化記憶」的機制。太亂靠 re-arranging，有錯靠 re-grouping / re-connecting。

「記憶垃圾桶」與「跑步跳上車」是同一件事：把感覺消掉但沒處理。

會議情境的 make it again 發生在會議結束後那幾分鐘的重整；看完這支不代表學習系統已完整。

留下量 = 讀入量 × 保留率。保留率低時，提高保留率（消化）的效益遠大於提高讀入量。

P procedural / A analogous / C conceptual / E evidence / R reference。

程序性知識的本質是動作序列與情境判斷，背只留住文字，沒留住技能；一兩週後再練早忘光。

「忘掉九成」只是方向性主張，作者沒給出處，不要當精確數字。

類比只在相似處有效；不找不相似處，會把錯誤知識一起接進來。

邊讀邊畫、邊加邊重組；A（類比）不是獨立一類，而是附著在 P 或 C 上的策略。

兩者都是讀時 store、之後 rehearse；reference 用 flashcards + spaced repetition（Anki），evidence 用解題、寫、教的方式演練。讀的當下絕不反覆重讀。

所以投錯職級等於自己換到更嚴格的評分尺。錯誤「一再出現」代表準備策略系統性偏掉，不是運氣。

補三四小時是把已經會的東西整理成能開口講的形狀，不是學新知識。REST 題多半是具體場景：這動作用哪個 verb、URL 怎麼設計、失敗回什麼狀態碼。

mid 做完明確任務、senior 自己界定問題帶動跨團隊、staff 對組織技術方向負責。越高職級技術題比重越低、行為題越高。

最常失分是講成團隊流水帳（通篇「我們」）或結果不可量化：「順利上線」vs「建置 40 分鐘壓到 9 分鐘、每天省兩小時」。

釐清需求 → 估流量 → 定介面 → 畫資料流 → 講瓶頸與取捨。設計題完全講不出結構會被記成「不知道自己寫的東西跑在什麼上面」，是能力印象問題。

斷掉的不是進度而是連續性。把時間切成「練新題」與「回顧舊題」，隔幾天重看卡住的題只回想解法骨架。習慣的敵人是無聊不是難度。

累積三四次會看出固定失分點，比再刷五十題有用。多投只有在每次都複盤時才提高機率，否則用同一份弱點重複撞牆。冷卻期從上一次面試起算。

英文最常用一千字覆蓋日常對話八成；做菜基礎技法可遷移。問「這領域裡最常被用到、其他東西都建立在它上面的是什麼」。

成功只告訴你「這次可以」，不告訴你哪裡是邊界。要的是小而快的失敗（投籃不進、講到一半卡住），不是高代價的失敗。

「學慢」不是降低速度，是縮小每一輪的範圍讓每輪都真的留下東西。跟「盡快失敗」不衝突：全部的失敗集中在同一個子技能上。

「妄想程度的自信」要的是對「最終能搞懂」的信心，不是對「現在就會」的錯覺——後者反而讓你跳過反思。immersion 是 active recall 的低成本版，用空檔多跑幾輪循環。

這正是後面「兩種 ack 方式」的根源。中間層解的是 N×M 義大利麵：producer 與 consumer 互不認識、只約定 channel。

「處理能力」和「資料在哪」綁在同一台，擴充其中一個必然牽動另一個——compute / storage 分離就是把兩者拆開。

broker 是交通指揮（stateless），BookKeeper 是獨立的分散式 write-ahead log 服務，預設三份複本。

ZooKeeper（或 etcd / Oxia）是協調大腦：哪個 broker 擁有哪個 topic、ledger 在哪些 bookie。三個角色各自獨立擴展。

不必把大家塞進幾個共享 channel 再過濾。Netdata 每個 agent 一個 topic 就是這用法。geo-replication 能 client failover 是因為 broker 無狀態、資料在儲存層有複本。

Kafka 有 ACL 與 quota，但沒有 tenant/namespace 這種一等結構，隔離要靠命名慣例拼湊。

producer 收到 ack 那一刻資料已在多台機器的磁碟上。topic 便宜到可以每個請求路徑一個，所以能做 RPC over topics。

所以只能由 client 定期去探。這裡的 ping/pong 是應用層自訂訊息，瀏覽器 JS API 沒暴露協定層的 ping。

斷線期間把更新存 localStorage 重連後補送，只保證不遺失、不保證順序與不重複。server 收到任何訊息就回 pong 沒檢查內容，真實應用要區分。

把 pong 改成 pongo 就能不殺 server 驗證重連。重連解決不了邏輯錯誤，只會一直循環。

server 整台死掉 SSE 一樣連不上——備援只是換一種方式失敗。EventSource 內建自動重連 + Last-Event-ID 續傳，是 WebSocket 沒有的。下行 SSE、上行 POST 是正常組合。

好處是跟 WebSocket 共用同一個 RECONNECT_INTERVAL。「WebSocket is closed before the connection is established」是重連太快的競態，暗示要退避與狀態檢查。

proxy_http_version 1.1 + Upgrade / Connection 標頭不是裝飾：nginx 預設 1.0 且不轉 hop-by-hop 標頭。client 只認 LB 的 URL 所以 reconnect 邏輯完全不用改。

靠 cookie 的黏性是另一套機制（hash $cookie_xxx 或 NGINX Plus sticky cookie）。要回同一台是因為 WebSocket server 有狀態：連線物件、訂閱、未送完訊息。

照影片畫面直接抄會得到「一半的 client 收不到」。broker 把 N×N 互連變 N×1，新 server 連上 broker 就自動加入廣播，代價是多一跳毫秒級延遲。

所以「不用改程式碼」是設計的直接後果不是行銷。靈感來自 Solid JS：從第一天就沒有 virtual DOM。

render function 執行時記錄讀到哪些 reactive data，只有那些變動才 trigger。這個「知道一半」是整條推理的關鍵。

編譯器把 template 分成「死的」與「活的」，樹在編譯那一刻就塗好顏色。patch flag、block tree 同一套路：把編譯期看出來的事實編進輸出。

mount 仍要走一次，被拿掉的是之後每次更新的中介。省的不只 diff 的 CPU，還有短命 v-node 的配置與回收（記憶體那半句的出處）。

watch([myDep], () => { node.nodeValue = myDep.value })。最硬的工程問題是那個 node 參照從哪來：編譯器要替每個會變的位置產生穩定參照。

vdom 輸出裡 v-if 為 false 仍留註解節點佔位（diff 位置要對得上）；512 NEED_PATCH 這些數字是編譯器留給 runtime 的提示。_delegate 把事件委派到祖先省記憶體。

實際收益來自大型清單、頻繁更新的表格。opt-in 的代價是兩條 runtime 並存，最易出問題的是模式交界（slot、provide/inject、transition）。只支援 Composition API 是模型衝突不是任性。

在什麼條件下用、代價是什麼、不用會怎樣。前端基礎、系統設計、AI 輔助是同一個能力在三個尺度的展現：說得出「為什麼」。

規則是看你動的是哪個屬性，不是看用 transition 還是 JS。layer promotion 吃 GPU 記憶體，will-change 短暫開啟動畫結束就拿掉。

bug 不在寫的時候出現，而在其中一份忘了更新時。programming to interfaces 在前端 = 先決定 props 形狀再讓 AI 填實作。

三層遞進：TypeScript → linter（Oxlint）→ complexity 與 duplication。AI 的重複常是結構同字面不同，要 token / AST 級比對（jscpd）。檔案再肥靜態也會過，看檔案長度。

65% 以上、別衝過 85%：過高往往是沒人驗證過的假覆蓋率。AAA 骨架直接交代給 AI。

prompt caching 讓「穩定的放前面、變動的放後面」與檔案結構穩定有金錢價值。換成 GPU 時間計價結論不變。micro-frontend 判準是同時改同一份程式碼的人數。

預設 content-box 的 padding/border 往外加；幾乎所有專案寫 * { box-sizing: border-box }。margin collapsing 只在垂直、父子間無 padding/border/BFC 時發生。

所以 !important 在更前面的關卡就分勝負；@layer 生效時低分規則可能贏。:where() 一律 0 分、:is() 取最高——設計系統靠這寫容易被覆寫的預設。

「永遠不用 px」太滿：border 寬度與圖示用 px 反而對。會隨使用者設定或容器改變的才用相對單位。rem 相對 root、em 相對父層。

你怎麼切 bundle 決定能不能分開快取。HTML 不快取、帶雜湊資產 max-age=31536000。邊緣讀寫分離的痛：使用者看不到自己剛寫的——讀自己的寫入或樂觀更新。

Google 挑的是「與跳出率相關性最高、且開發者改得動」的三件事。先建立量測的語言，再拿工具。

Amazon 行動版 333 個請求、大多是 479 B 的 beacon，每個都快卻靠數量把連線數吃光。找 LCP 元素比看整張瀑布圖更快。

瀏覽器沒解析完 CSSOM 就不畫任何東西，「關鍵 CSS 內嵌、其餘非同步」通常比動 JS 更快見效。SPA 初次載入要先跑一堆 JS 才畫得出主要內容。

preload 是「提早發現」不是「提早畫出」，濫用讓所有東西都高優先權等於沒有優先權。

有效做法是把大工作切小、中間主動讓出主執行緒（scheduler.yield / setTimeout 切片）。判定用真實使用者第 75 百分位，你自己點一次快不算。FID 已被 INP 取代。

width/height 屬性只拿來算長寬比，搭 width:100%; height:auto 沒衝突。使用者互動後 500ms 內的位移豁免。動畫只動 transform 與 opacity。

Web Vitals 擴充套件在正常瀏覽時就收數據、直接印出 LCP element 與造成位移的 DOM 元素。它是定位問題的工具不是驗收成績的（單次觀測 vs p75）。

npx unlighthouse --site <url>，自動爬路由平行跑 Lighthouse。不同站路由數差四倍、預設模擬行動裝置節流，數字只當相對參考。

一次決定會被重複套用幾百次——所以決定變少但影響更多人，錯誤也同樣被重複幾百次且發現得晚。要的不是不參與，是不當瓶頸。

三種代價：營運（復原 15 → 90 分鐘）、設計（40% 操作跨服務 = 邊界切錯）、機會成本（18 個月）。架構 = 帶著後果的 trade-off 記帳。

五個選項彼此會打架：對擴展好的通常對除錯差。「被 call 起來的團隊」是唯一不會出現在架構圖上的成本。

翻譯機是把 A 的話轉述給 B，影響力是在任何會議裡你都是提案的人。成本給財務、風險給營運法遵、價值給產品、工程現實給工程師。

攤開後要嘛找沒計入的價值（上市時間、故障成本），要嘛承認這一年不該做。8 → 5.5 FTE 在財務眼中是省人力，在工程眼中是裁員訊號。

10 人時知識裝得進一場對話；80 人溝通路徑平方成長。六個動作裡最易略過的是遷移路徑與防止 recouple——只做前四項得到漂亮文件加沒變的程式庫。

service discovery 讓新舊並存能互找、API gateway 決定流量往哪走、circuit breaker 不讓失敗擴散。只有目標架構圖的是牆上的裝飾畫。

第三條需要觸發機制：在 issue/PR 標記受影響模組，每季看哪個交界處最常出現。寫下 trade-off 會逼出你其實沒想清楚的部分。

跨團隊協調次數、同類問題重複率、新人第一次上線天數——給自己看的儀表板。要放下的是把程式當價值來源的習慣，不是讀程式的能力。

判定「不必要的 re-render」= 重畫了卻沒改任何像素（DevTools Profiler highlight updates）。memo 有比較成本，先修 state 結構通常比到處包 memo 有效。

virtual DOM 用便宜的 JS 物件比對換掉昂貴的 DOM 寫入。memo 是在 reconciliation 之前就剪掉一整棵子樹。

這是「動畫用 transform 不要用 top/left」的來源。外部 CSS 是 render-blocking，沒 defer 的 script 擋住 HTML 解析。

按鈕防連點需要 leading（立刻執行第一次、後續忽略），debounce 預設是 trailing。

硬規則：ref 的改變不會通知 React，任何要顯示在畫面上的東西不能只放 ref。

漏填造成 stale closure。是 componentWillUnmount 不是 DidUnmount——卸載後沒有實例可呼叫。StrictMode 刻意掛載兩次逼出沒清理的 effect。

電商商品列表最常用 ISR，比 SSR 便宜得多。SEO 真正的價值：Google 排隊渲染 JS 會延遲索引，社群平台爬蟲多半不執行 JS。

需要 getDerivedStateFromError（顯示 fallback）+ componentDidCatch（記錄）。Next.js 的 error.tsx 就是綁定路由層級的 boundary。

clearInterval 收到不存在的 id 只會靜靜什麼都不做，所以這類 bug 難找。受試者對 useRef 的記憶只有「取 DOM」這個用例，而不是「跨 render 不變的容器」。

Rules of Hooks：hook 只能在元件或自訂 hook 頂層，useEffect 的 callback 是巢狀函式。React 靠呼叫順序對應 hook 狀態。

debounce 錯（隔十秒點兩次仍開兩個 interval）、hasStarted 錯（平行真相來源）、useCallback 無關。TypeScript 的 Timeout not assignable to null 就是線索。

受試者第 7 段正確說出「useRef 記住跨 re-render 的值」，拿到「把 interval 存進 ref」的明示提示，仍需逐行帶著走。

來源會不會 complete、時間間隔對不對得上、比的是不是同一個物件、有沒有人還在訂閱。測試環境好好的、上線偶爾出事的那種錯。

「先初始化、再持續追加」的資料流同時具備兩個觸發條件：初始筆數不被批次大小整除、來源不結束。實務上加逾時或手動 flush 讓「湊不滿」有出路。

預設 leading edge：第 0 個立刻放行然後關窗。interval(100) + throttleTime(120) 穩定隔一個放一個。飄移正是最後值被吃的溫床。

重現不了、寫不出穩定測試、看起來像別人的問題——最難查的一種 bug。

反過來就地 mutation 同一個物件又會判定相等而擋掉真正的變更——同一機制的另一半災情，更難察覺。

前兩個坑給的都是繞路，這次是直接把旋鈕轉過來。參數順序是 (previous, current)，不對稱的比較邏輯順序不能寫錯。

加上 share 後兩個訂閱收到的數字同步（都 0、都 1），cold 版本各自從 0 開始數。

真實 HTTP（非同步）通常不會踩到：第二個訂閱在回應前就建好。用假資料測出事、換真 API 又好了。share 重置條件不只 refCount 歸零，complete 本身也會（resetOnComplete）。

shareReplay 沒人訂閱還繼續跑 = 記憶體洩漏：來源仍持訂閱、計時器仍排程、緩衝區握著值；隨元件開關累積成殭屍串流。

每個重置條件獨立表態：ReplaySubject 換來記憶、refCountZero 為 true 沒人時停、resetOnComplete false 解 of() 那個坑、resetOnError false 不重打失敗請求。九成五情境。

路線：需求 → 狀態 → 實作 → 非功能需求 → AI 工具鏈。不能用電腦時你唯一能依賴的就是腦中那條路線。

只有效能能給真正的數字（SLO、Core Web Vitals + RUM）；無障礙與安全改用「有沒有法規」逼出標準。先切「初始載入 vs 持續刷新」。

列舉法只會寫下你想得到的。「不在範圍」要跟面試官達成共識並說出口。current price 跟折線末端是同一個值。

它產出的是 DB schema 而不是前端狀態型別。正確用法是把 AI 當成會提出你沒想到選項的同事（decimal(18,2) 反而更貼近金融精度），由你來砍。

start/end 是查詢參數，data/loading/error 是查詢結果——因果不是並列。把 [start, end] 當 queryKey，其餘由 TanStack 托管，你一份狀態都不用寫。

你不是在管束人類，是在替模型設定窄的輸出空間。靜態品質要靠 CI 閘門強制，否則 agent 會繞過。

先問使用情境（公開？SEO？流量？）：公開頁面在意首屏，登入後儀表板在意互動延遲。SSR 與 hydration 之間「看得到但按不動」的空窗是 INP 在抓的。

反方向：形狀貼合且服務自己擁有時，多一層只是多一個要部署、監控、on-call 的東西。另兩個好處：金鑰留伺服器端、多次下游收斂成一次。

規則：能從「一份基準」加「當前值」算出來就只存這兩個。SSE 在 HTTP/1.1 每網域 6 條連線，一頁十個圖表要共用一條連線帶 asset id 分流或走 HTTP/2。

否則每個使用者 URL 都不一樣，共用快取形同虛設。設計系統 CSS 比應用穩定，值得從 bundle 拆出獨立快取。HTTP 快取與 TanStack 快取是兩層互補。

系統設計不是「AI 會寫程式後就不用學」，反而是 AI 時代唯一要親自產出的東西。審查代理與 coding agent 互修要大量監督，否則無窮迴圈。

junior 工具導向（該用 styled-components），senior 先講決策因素（顧效能就得看 bundle size）。別練 Uber，練你每天在做的有大量資料與表單的企業軟體。

功能需求產出畫面與資料結構，非功能需求產出架構；混著談兩邊都講不深。

不可再簡測試擋掉最常見錯誤：把可以算出來的東西存成狀態（篩選後的商品陣列）。面試裡可以主動宣告某狀態超出範圍，但要說出口。

as low as possible, as high as necessary。抬高的代價是整個子樹重算。

資源分得越乾淨，一個畫面要組的資源就越多——under-fetching 是 REST 的必然結果不是失誤，也是 BFF 與 GraphQL 的動機。

月 21.1 億 → 週 → 週二至四 → 週四 → 尖峰小時 2100 萬造訪 × 6.8 頁 = 1.36 億頁面瀏覽。行動佔七成：JS 要輕，圖片可以更小。

Core Web Vitals 是 SLI（量出多少），加一條目標線（LCP p75 ≤ 2.5s）才是目標。自己筆電量的數字過於樂觀，要靠 RUM。

來回次數 × 地理距離是你付不起的成本，縮短距離是唯一能同時砍掉每一次來回的手段。TLS 1.3 一次來回，HTTP/3 合併 TCP 與 TLS 交握。

搬完資產剩渲染，搬完渲染剩取資料，搬完資料才收斂。唯讀副本選的是可用性，換來最終一致性。hydration 空窗直接反映在 INP。

判斷需要哪一個看痛點是「重複實作」還是「前端要打很多支再拼」。畫面差異不大時一個 BFF 加參數比兩個划算。BFF 由前端擁有是康威定律的伏筆。

微前端代價：重複相依讓總下載量變大、跨應用路由與狀態變複雜——所以要補 design system（統一使用者看到的）與 monorepo（統一工程師碰到的）。

active-passive 不是免費的：待命台閒置也要付費，切換空窗就是停機時間；待命節點要定期演練否則設定早就過期。

面試中把「順帶解決了什麼」講出來。分析工具丟給 web worker，主執行緒才不會被自己加的工具拖慢 INP。

@vue/reactivity 是獨立 npm 套件，不裝 Vue 也能單獨用。這支影片重建的就是它內部真正的資料結構。

函式是 JavaScript 裡唯一能把「還沒發生的計算」當成資料傳來傳去的東西。

所以 track / trigger 都手動呼叫不是忘了，是自動化被刻意排在後面。真實 Vue 是在執行 effect 過程中讀到 price 才順手登記。

用陣列存改一次就重繪三次，effect 寫回自己讀過的值還可能無窮迴圈。demo 跑得動是因為 effect 是閉包，抓的是變數本身不是值。

屬性剛好叫 constructor 或 toString 時普通物件會出事。effect 也從裸變數改成 product.price——讀「某物件的某 key」才有東西可當 key。

depsMap.set(key, (dep = new Set())) 一行做三件事：建 Set、讓 dep 指向它、存進 map——賦值本身是運算式會回傳值。

targetMap 是全域永遠活著的變數，普通 Map 會永久扣住每個曾響應式的物件，元件卸載一千次就洩漏一千份。

真實版本還要處理巢狀 effect、重跑前清掉舊依賴、觸發丟進排程佇列去重。

作者把「怕失去優勢」這種通常不會公開講的動機攤開，變化不是漸進而是已完成（Yesterday honestly）。

「如果你選擇不進化」才可怕——重點在「選擇」二字。兩個現象（別人用新工具更快、差異化工作被 normalize）是同一件事的兩面。

五十年前拍片要團隊、幾萬美元、幾週，現在一支 iPhone。喜歡剪膠卷沒有錯，但得接受它不再是原本那份工作。

努力、持續學習、產出看得見的成果——不綁在舊工具上，所以新時代一樣管用。hold back the ocean 典出 Canute 命潮水退去：把「進化」重新定義成「不抵抗」。

它把你電腦上已裝好的各種 agent 接進同一個介面。後面每個功能都可歸到「工頭的工作」。

agent 選單：Claude、Claude Agent Teams、Codex、OpenCode、Pi、Gemini、Antigravity、Kiro、Cline、Cursor…——agent-agnostic。

DOM 和原始碼不一定一一對應（框架會加 class、hash）。提示列還能按 S 截圖給 agent 看。

Orca 在 agent 開始做事後依任務內容自動幫 worktree / 分支取有意義的名字，資料夾名不變。

PR 標題直接拿分支名轉成，內文 No description provided——個人專案 OK，團隊協作是缺口。

TypeScript 錯誤、SEO metadata、lint 清理——小、獨立、不會碰同一批檔案。會改到同一個檔案的任務，收成時 merge 會打架。

Antigravity Starter Quota 做到一半用完；做到一半的改動仍在 worktree 裡，關鍵任務可換 agent 接手同一個 worktree。

Orca 把註解組成 prompt 塞回該 worktree 的 agent 對話，agent 再改、你再看 diff，人機閉環。

比稿把 Orca 從生產工具變評測工具；sub agents 是 handoff 的變體，拆解與分派由 agent 決定。後兩種影片沒示範。

IDE 的使用者是人，工具幫人寫程式；ADE 幫人「管理正在寫程式的 agent」。

claude --dangerously-skip-permissions、copilot --yolo、aider --yes-always。所以新 agent 很容易加進清單；agent 在 Orca 裡常無人看管地跑。

這是「多個 agent 同時跑不會互踩檔案」的技術基礎。Create worktree 可貼 issue 編號或 PR/MR 網址，Orca 據此命名 branch——worktree 對應一個工作項目。

feature 彼此依賴就不能這樣切。Orca 監看每個 terminal 分頁的程序，認出已註冊的 agent 命令就掛上 session 條目。

skill 教它在訊息尾加「continue your implementation afterward」，避免被打斷的 agent 忘記回去做原本的事。

作者誤判「它加了我真實的 Proxmox 節點」，其實是 RFC 8375 保留網域與教科書式私有位址。agent prompt 型 quick command 每次用都多一個 session，用完記得關。

消除「用文字向 agent 描述我在說頁面上哪個東西」的溝通成本。送出時其實是新開一個 agent：沒有前面脈絡、但不打斷正在做事的。

「大部分時候重啟就好」不是玄學。程式邏輯錯重啟沒用，那時才叫 agent 修。手機端最實用的是回應 agent 的權限確認。

建了 MR 之後還要有人在 GitLab 上接受它 main 才會有 commit——影片剪掉了這步。19 個新檔、package-lock +1845 行是「五分鐘」的實際規模。

Pi 沒有旗標因為它本來就不問——這是選 Pi 的原因。多個 agent 各自持有一份 context，prompt cache 閒置失效要重送整份。sub agent 用低 thinking mode。

反過來也可以刻意混用：前端給 Claude、簡單 API 給 Pi + MiniMax。

queue 分別用非同步、重新派送、緩衝來解——三個性質對三個痛點。

decoupling 還有時間解耦：兩端不必同時在線。餐廳 ticket rail：服務生放單就走，廚師準備好再取。

「處理完、ack 前掛掉」無法消除——所以下一步是投遞保證。

只能在「可能重複」和「可能遺失」之間選一個。重複的責任歸 consumer，因為只有它知道業務操作能不能重做。

初中階常犯：看到 queue 很好就到處用。另一個反例：需要嚴格全域順序的工作流，partition 後只能保證 partition 內順序。

存 100 再提 50 落到不同 partition 提款可能先跑，用 account ID 當 key；用城市當 key 紐約爆滿。獨占 partition 既避免重複消費也是順序來源。

三層對策：scaling 增加容量、back pressure 減少輸入、alerting 知道何時該做前兩者。最低限度對 queue depth 設告警。

poison message 沒護欄會無限重試、卡住後面所有訊息。DLQ 是隔離思想的再應用。

consumer 有 bug 處理錯了，換新版告訴它「從一小時前重來」。複製到幾個 broker 才算寫入成功（acks）影響延遲與耐久取捨。

沒有 go-to 就選 Kafka；但它運維成本高，面試裡要說得出你需要它的哪個能力。SQS standard 盡力排序、FIFO 嚴格排序但吞吐低。

主線變成「Observable 裡裝著 Observable」，必須有人決定怎麼攤平；map 沒有這個決策點所以沒得比。pipe 那行只是描述，subscribe 才執行。

沒有 delay，五個工作瞬間結束彼此不重疊，四個 operator 輸出一模一樣。差別只存在於重疊的那一刻。

示範裡五個 delay 都 500ms 才剛好看起來是 0 到 4；五個 HTTP 同時發，回來順序由伺服器決定。flatMap 只是別名。

適合「每一筆都不能丟、順序不能亂」：離線累積的操作依序送出、照順序寫日誌；不適合綁在使用者連續輸入上。

搜尋框即時建議的經典解：一次解決浪費與「舊結果晚回來蓋掉新的」兩個問題。

exhaustMap 是靜悄悄丟掉不排隊不報錯：送出鈕連點只送一次、token 續期只續一次。

getUser 只吐一個 user 就完成，只有一個內層被建立，四個策略都無事可做——所以 concatMap 與 switchMap 看起來一樣。選錯是「使用者手快才重現」的 bug。

能跑起來、能驗證、有硬規則擋著。會說「我不確定」的模型輸出可以分流，永遠篤定的逼你每次全部檢查。

它不保證「好」程式，只保證「正確」的程式——把品質拆成兩個可分別處理的問題。四個例子涵蓋正確性、CPU、記憶體、實際介面。

好的 verification skill 大半內容不是「怎麼操作」，而是「多個 agent 同時跑時怎麼不互相干擾」（worktree 各自 port 與 user-data-dir）。

驗收標準：一張截圖加三個問號的回報，agent 也要能對應到功能。密度高到人手寫跟不上，要 create / maintain skill 自動產與更新。

每觀察到一種失敗模式就寫成一個 skill；面對「能力強但零脈絡、五秒前才報到的新人」，教法就是寫下來。

單次結果分不出「skill 改好了」和「這次運氣好」。

人只出現在第一步和最後一步。同一模型既寫又評，偏好會同時出現在兩邊。品味最終體現在 rubric 上。

「AI slop 之前就有 human slop」：把 agent 放進「能力不均的貢獻者」這個位置。vibe code 的原型會長成 organic architecture——被捷徑堆出來的。

原則：agent 做不好的事就全部禁掉（useEffect 直接禁，CI 失敗）。

前兩層會讓 CI 變紅是硬約束；rules、skill、style guide 是軟的，agent 會忘，只能疊加不能當唯一防線。敢不看程式碼是因為信的是第一二層。

靠人 review 維持的不變量，成本正比於 PR 數量，往曲線右邊走時率先崩潰。編譯器擋掉的那類錯誤人就不必檢查，但能編過 ≠ 邏輯正確。

信任的對象從來不是模型本身，而是那個讓錯誤難以發生的環境。介面決定誰進得來，架構決定他們送的東西能不能合。

應用層被動等訊息就永遠不會知道。這裡的 ping/pong 是應用層自訂的一問一答，不是 WebSocket 協定內建的控制訊框。

{ binary: true } 是 ws 套件 send() 的選項。影片裡 client 只檢查是不是 binary 不比對值，所以還是能動。

沒先 import，TypeScript 會把 declare module 當成全新模組，型別整個被蓋掉。狀態掛在 socket 上：terminate 從 clients 移除時狀態跟著消失，不用另外清。

這一輪把旗子放下，下一輪檢查有沒有被 pong 舉回來。

server 主動方用 setInterval 固定節奏；client 被動方只要「倒數歸零重來」。寫成 1000 * (5 + 1) 把緩衝寫清楚。

瀏覽器 setTimeout 其實回傳 number，編輯器顯示 NodeJS.Timeout 是 @types/node 蓋過 DOM；可攜寫法是 ReturnType<typeof setTimeout>。

server 的 isBinary 才會是 true，data[0] === 1 才成立；否則 pong 被當一般訊息廣播出去。

binaryType 設成 'arraybuffer' 就改比對 '[object ArrayBuffer]'。

影片沒處理這個邊界：server 在第一個 interval 內就死，client 永遠不會逾時。沒清 timeout 的 close 會錯誤觸發重連邏輯。

實測「pong 數 = 活連線數」同時證明三件事。影片只驗了正常關閉；真正的死連線要 DevTools 切 offline 等兩個 interval。下一步：exponential backoff 重連。

Promise Capability Record 把一顆 promise 與它專屬的兩個函式綁成一組。方向搞反會誤以為能在別處拿到某顆 promise 的 resolve。

new Promise 還沒回傳，executor 裡的程式碼就已經執行完了。

fulfill reactions 是列表不是單格，同一顆 promise 可串多個 then。record 裡還記著「跑完要 resolve 哪顆下游 promise」，這是鏈式的伏筆。

Promise 不會讓程式多執行緒、不會讓同步重運算變快；它只是把「一件正在等的工作何時完成」包成可掛 handler 的物件。new Promise 幾乎總是出現在 promisify 舊 callback API 的場合。

少算一次就把輸出順序算錯。非阻塞分兩層：等待是環境在等不佔 JS 執行緒；結果處理排進 microtask 不插隊。

錯誤沿鏈往下找第一個 catch，因為 reject reactions 用同一套 record 機制——所以 catch 放鏈尾能接住整條鏈。鏈越長結果出現越晚。

1、3、2 那題：then 在已 resolve 的 promise 上跳過存列表、直接排一份 job，但仍至少延後一輪 microtask。排程不等於執行。

畫面上每一個叫「某某 environment」的欄位，本質都只是指向某個 environment record 的一條線。

之後所有「為什麼可以在宣告前呼叫函式」「為什麼 const 提前存取報錯」都只是在問：這件事發生在哪個階段。

名字掛在 global object 上，實體住在 intrinsics 裡（規格記作 %Array%）；把 Array 重新賦值只改 global object 屬性，引擎內部仍走 intrinsics。

spec 屬性是每個 JS 環境都要有的，host 屬性是宿主自己加的——document 在 Node 不存在不是缺陷。

outer env 在全域是 null，這是遞迴查找的終止條件：走到 null 還沒找到就 ReferenceError。

這正是 if 區塊裡的 var 會洩漏到區塊外、let 不會的原因；全域兩者重合只是因為外面沒有更大的區塊。

function object 的 environment 屬性在建立那一刻就固定指向宣告處，之後傳到哪、被誰呼叫都不變——語彙作用域的具體實作。

如果 outer env 抄呼叫者的環境，JavaScript 就變成動態作用域，scope chain 與 closure 都不成立。

TDZ 起點是所在區塊的開頭不是檔案開頭。let 重複宣告是 SyntaxError（解析階段），跟 hoisting 無關。var 的 undefined 危險在讓錯誤靜默。

同一次呼叫 outer 產生的多個內層函式共用同一份 record；每次重新呼叫 outer 都是新的一份。查找是沿 outer env 走，不是往下翻 call stack。

所以 setTimeout、fetch 在 ECMAScript 規格裡找不到；同一份 JS 換到 Node.js，engine 一樣但周邊零件換了一套。

凍結的是整個分頁：算繪、捲動、點擊都跟你的 JS 共用主執行緒。web API 那套只解「在等別人」的那種。

你在 call stack 上轉一下門把（登記工作），實際的活由門後的瀏覽器做，堆疊立刻恢復空閒。

讓 callback 想回來就回來，你讀完 obj.a 正要讀 obj.b 之間值就可能被改。登記的 callback 不保證會回來（使用者一直不理授權視窗）。

「空了」指整支同步程式碼跑完，不是某個函式回傳。佇列 FIFO，但兩個 fetch 誰先回來由瀏覽器背景決定，不等於呼叫順序。

背景分頁降頻到一秒一次；重運算長任務會讓所有計時器一起遲到——所以它不能拿來精準計時。同步 console.log 永遠贏過任何 setTimeout。

microtask queue 收：then/catch/finally、await 之後、queueMicrotask、MutationObserver。setTimeout 0 vs Promise.resolve().then 永遠 promise 先。

優先權的設計目的是讓同一件事的後續處理不被點擊或計時器插隊，promise 鏈看起來連續發生。

setTimeout 寫 10ms 或 0ms 都排最後，跟延遲長短無關。promisify 只是可讀性：resolve 進 task queue，落定後 handler 才進 microtask，多繞一層。

練習順序：同步 vs setTimeout 0 → 加 Promise.then → 巢狀 queueMicrotask → 遞迴 queueMicrotask 親眼看卡死。Node.js 多了 process.nextTick 與多個 phase，先固定瀏覽器。

outer 執行完 context 與 record 被回收，但 outer function object 留著——因為全域 record 裡有綁定指著它。整支影片就是在製造第二個參考者。

你讀程式碼看到的巢狀結構，就是引擎最後串出來的那條鏈。宣告函式就有這條線，免費的。

問題從來不是「有沒有人指著它」，而是「從外面走不走得到它」。早期 IE 的 DOM 循環參考就是參考計數漏的。

execution context 死了，environment record 活著。return inner 不是 inner()——一字之差決定外面接到函式還是數字。

鏈是單向的：inner 找得到 outer 的、outer 找不到 inner 的；盡頭是 global record（[[OuterEnv]] 為 null），再找不到就 ReferenceError。

closure 不是呼叫時才建立：function object 一建立關係就定了，只是要等外層結束、參考仍在，才用這個名字稱呼它。

createCounter 測驗答案 1、1、2：答 1、2、3 是把 count 當函式共用狀態，答 1、1、1 是以為每次呼叫都重跑外層。每次呼叫 counter1() 的 increment record 用完就丟，累積的只有外層那份。

cache 被 closure 釘住永遠不會自己縮小，用 Map 要自己管容量。

事件監聽器、setInterval 回呼沒解除註冊，是前端記憶體洩漏最典型的來源——同一個機制。

所以後面任何把負載搬到別台的做法都得先處理這些狀態要放哪——這是整個題目的主軸。

Batteries not included：Heartbeat、Buffer undelivered、Message routing、Broadcast、Backpressure、Reconnection、Acks、Encryption、Multiplexing。

空連線一台 16 GB 可到數十萬，加上九項電池與真實訊息流可能掉一個數量級。別人的數字沒有參考價值。

按峰值配置的浪費在垂直擴展下無解——單台不能半夜縮小白天變大。memory leak 或雲端 AZ 離線都會整個下線。

某個使用者這輩子的所有訊息都只經過他被分到的那一台。舊連線不會走，round robin 對長連線不一定平均。

socket 搬不走，能搬走的是「誰在哪、訂閱什麼、有什麼要送」這層應用狀態。A → LB → Server 1 → Redis → Server 2 → B。

presence 用帶 TTL 的 Redis 紀錄自動過期；Redis 用 Sentinel / Cluster；重連用 exponential backoff + jitter。autoscaling 縮機器直接砍就是人為的 thundering herd。

停機代價低（內部工具、早期產品）先用單台加好的容錯；金融、交易、即時協作一開始就水平擴展。「連線數」不是好的容量單位，因為連線各不相同。

macro 決定的影響更遠、更快，錯的 macro 會被 LLM 以同樣速度放大，所以他把力氣花在 spec 與 review。

標準決定體感：「能動就好」幾分鐘達成所以輕鬆；「line for line」得像 junior 一樣反覆被拒絕。

價值集中在有判斷力的人身上，而判斷力的生產線壞了。學徒制被提出：讓新人在有判斷力的人旁邊做真實的事。

用「中位數」不用「平均」：平均被少數重度使用者拉高。token 變成需要治理的稀缺資源，Uber 四個月燒光全年預算後設硬上限。

要建立自己對模型的直覺需要穩定的實驗環境。Pi 極簡可客製，Herdr 是為多 agent 同時跑設計的 tmux。

300–800 行是「一個人能真正讀懂」的上限；agent 能一次吐三千行但刻意不讓它。Plannotator 的註解直接注入回 agent session。

agent 提案、他標註、agent 修、再標註；用 /plannotator last 直接編輯 agent 的話，修正它的理解而不是寫文件。「終於相信有共同理解」是 senior 判斷，junior 可能太早相信。

知道答案才能判斷 agent 研究對不對；結論留在對話裡實作時不用重講；每個主題在自己分支研究，/tree 跳回根部只留審過的小結。

型別定形狀、call stack 定路徑（防它開你不想要的新路）、測試定驗收（防過型別檢查但行為不對）。spec 比實作長：思考成本刻意放在動手前。

漂亮的摘要讓 senior 也不再自己想。sub-agent 真正解的是 context 容量問題；工作單位本來就小（300–800 行）容量問題就不存在。

自動化的是流程不是判斷：queue 裡每一步都是他手動走過幾百次的步驟；品味明確寫下；期望值很低。

HTTP/1.1 有 keep-alive 可重用連線，但仍是客戶端問、伺服器答；伺服器不能主動推才是 WebSocket 真正要解的。

Connection: Upgrade 是 hop-by-hop 標頭告訴 proxy 要換協定，Upgrade: websocket 才指名換成什麼，少一個伺服器都該拒絕。Origin 可擋跨站連線。

GUID 是 RFC 6455 寫死的 258EAFA5-E014-47DA-95CA-C5AB0DC85B11；普通 HTTP 伺服器原樣回音也算不出。SHA-1 在此只是指紋不涉安全強度。

wss 順序是 TCP 三向交握 → TLS 交握 → 才送 upgrade GET，所以 handshake 本身也加密。ws 預設 80、wss 預設 443。安全來自 TLS，身分靠 Origin / cookie / token。

opcode：0x0 接續、0x1 文字（合法 UTF-8）、0x2 二進位、0x8 關閉、0x9 ping、0xA pong。客戶端→伺服器一律遮罩，伺服器送出不可遮罩。

惡意網頁可讓 payload 長成 GET /script.js HTTP/1.1，舊 proxy 誤快取後污染其他使用者。所以 key 每個 frame 都要重新隨機、且只有客戶端→伺服器要遮罩。

所以大訊息傳到一半仍能回 pong 保活。兩則資料訊息的片段不可交錯。瀏覽器 API 不讓你控制分片，伺服器端函式庫才有選項。

擴展時要處理連線親和性與斷線重連。聊天與報價吃持續連線 + 小標頭；遊戲與協作畫布吃同一條 TCP 的有序傳輸。

問題要從「怎麼背下正確設計」改寫成「需求不完整時怎麼做出合理決定並解釋取捨」——後者才有可練習的動作。

導入成本不只是寫程式的時間，是往後每次上線、除錯、招人、交接都要付的持有成本。

搜尋結果是靜態快照，offset 的位移弱點幾乎不發生、跳任意頁正是使用者要的；feed 新貼文隨時插到最前面，cursor 指向資料本身所以免疫。

白板上兩人同時改同一個形狀是常態（要 CRDT / OT）；看板上同時改同一欄位罕見，後寫覆蓋就夠。選了 WebSocket 不等於得整套上。

Clarify 問的三件事（使用者體驗、規模／一致性／交付速度、限制）正是會翻轉答案的變數，不是禮貌性暖身。

先講完最薄的一條線就有完整可討論的設計，之後每次加複雜度都綁在具體理由上。offset 起步再換 cursor 成本不高——可撤回決定的典型。

第四句把決定變成有觸發條件的決定，「我可能選錯」不再是弱點而是計畫的一部分。列五個方案等面試官挑的人聽起來不像能做決定。

大部分前端架構決定其實是可逆的。

契約（有哪些端點、進出什麼形狀）穩定、可讀、跨語言；實作才需要語言知識。不認得 swagger 會被解讀成「沒待過成熟團隊」。

safe = 完全不改變狀態。PUT 冪等不安全，POST 兩者皆非。面試問「哪些動詞冪等」其實在確認你分不分得清這兩個維度。

帶 If-None-Match 去問，沒變就回無 body 的 304。真要連往返都省靠的是還沒過期的 max-age：檔名帶 hash 的給極長 max-age，HTML 入口每次驗證。

DataLoader 不是快取：把同一個事件迴圈週期內的取值請求攢起來一次送出，不改 resolver 寫法只改打出去的時機。ORM 迴圈讀關聯也是同款問題。

這才是「SSE 更好擴展」的實際含義。判準：客戶端送的遠少於伺服器送的就用 SSE；低延遲雙向（協作、遊戲、語音）才 WebSocket。

三段 base64：header、payload、signature；伺服器只驗簽章不查 DB。「JWT 怎麼登出」面試官想聽的就是這個。controller 要薄，商業規則放 service 層才能脫離 HTTP 測試。

順序是先 validate 再 sanitize；真正防 XSS 的關鍵在輸出時依情境轉義（HTML、屬性、JS 各不同），寫入時清洗只是輔助。

「NoSQL 比較快」限於單一文件讀寫與水平擴展；要跨文件關聯就得在應用層自己 JOIN。判準是存取模式確定了沒。

網路正常時一致性與可用性可以同時擁有。正確順序幾乎總是：先垂直擴展、先加快取、先修慢查詢，撐不住才動架構。

每次 INSERT / UPDATE / DELETE 都要維護每個索引。分片：範圍分片有熱點、雜湊分片範圍查詢要問遍所有片；shard key 選錯重分片極痛。

所以全片都是「回你的 codebase 找」而不是「去修一門課」：課程給的知識離邊界太遠，你沒有能驗證它的參照系。

IDE 外掛綁在「一個視窗、一個工作目錄」的模型上，接了多個 AI 也只是輪流不是並行。所以編排工具的技術核心一定得先解「多個工作目錄」。

不用切分支就能並行不是 Orca 的魔法，是 Git 本來就有、很少人用的功能；Orca 的貢獻是把「開 worktree → 派代理 → 收 diff」自動化。

用管線接 stdin/stdout 會失去彩色、進度動畫、確認提示。Electron + xterm.js + node-pty 跟 VS Code 內建終端是同一套技術。

跟 DevTools 檢查元素相同的資訊，只是自動送給代理而不是給人看。SSH 模式下 worktree 與代理都在遠端，本機只是介面。

真正吃資源的是代理本身（每個 CLI 都是幾百 MB 的 Node 程式），Electron 只是加上去的一份 Chromium 固定成本。

指揮官要能判斷五個方案哪個好，得看得懂 diff、想得到邊界情況、知道什麼是壞味道。

Orca 與代理的介面是終端機文字流，CLI 沒對它承諾任何穩定 API，改個提示文字整合就可能壞——這是「不自己造 AI」的代價。

多代理會不會成主流看兩個訊號：代理便宜到能同時跑五個嗎？各家答案越來越像的話並行比較的價值就下降。

同一份技術清單，中階講出來像背誦，資深講出來像決策紀錄。面試官在觀察你會不會自己界定問題、主動指出方案的缺點。

框線切的是團隊不是技術層級——它是組織問題的技術解法，不是效能手段。代價：共用 React 版本、跨片段路由與登入、設計系統抽共用、e2e 跨多個部署。

monorepo 和 micro-frontend 是兩個獨立的軸：同一份程式碼庫、各自的發布流程很常見。

同一個 React.lazy 動態 import 語法，先前切自家 chunk，現在跨網路拿別人的模組。代價：URL 掛掉 host 開天窗；React 要在 shared 協調否則載兩份。

否則使用者拿著舊地圖找新檔案。延遲主因是光速加 TCP / TLS 來回次數，所以縮距離的收益是成倍的。

import _ from 'lodash' 拉整包 70KB+，子路徑 2KB。用 bundle analyzer 查有沒有中招。

無屬性擋住解析與繪製；defer 平行下載、解析完依序執行；async 下載完立刻執行，適合彼此無關的第三方腳本。

早年把 API 資料塞進 Redux，於是自己寫 loading、error、快取、race condition——這些全是 server state 特有的副本管理問題。

重播需要伺服器保留事件序號與歷史；整份重抓只要重載快照。伺服器一掛，成千上萬客戶端同時重連會再打掛一次。

CI 裡加 lighthouse 效能預算，載入效能才變成會被擋下來的硬指標，否則 bundle 只會單向惡化。清不掉的舊 flag 讓程式碼難推理。

每個 micro-frontend 各包一層——各片段獨立部署就必須獨立失敗。錯誤報告要帶 userId 與 route 才可能重現。

沒有限制條件就沒有正確答案，先問限制不是禮貌，是取捨的前提。

可比的前提：同一段程式、同一批資料、同一台機器、同一種 build。沒有 baseline 可能改到更慢卻不自知。

Date.now() 在 NTP 校時瞬間可能量出負值；瀏覽器因 Spectre 疑慮把時鐘解析度調粗。

performance.now() 只活在區域變數裡。名稱字串打錯不會報錯，只會安靜少一列。看表格看比例不看絕對值：96% 落在 search 才是拆解買到的。

同樣 200ms 可能是 JS 迴圈也可能是改 class 觸發整頁 reflow。PerformanceObserver 的 long-animation-frame 能給部分歸因，但給不出 call stack。

重跑同一個操作，新工具量的才跟 baseline 對得起來。

Summary 裡 Scripting 壓倒 Rendering / Painting 時，還沒放大就知道不必查樣式或繪製。

只包在意的子樹，不 profile 整個 app；onRender 其實還有 startTime / commitTime，要對到 Chrome 時間軸時會用到。

production build 關掉 Profiler 是因為每個 commit 都要記時間戳；接近正式環境要用 profiling build。React 的 Scheduler ⚛ / Components ⚛ 軌道會寫進 Chrome 時間軸。

Performance API 是你自己插的探針、Chrome Performance 是瀏覽器全景錄影、React Profiler 是一棵子樹一次 commit。找到瓶頸後每個改法都改變結構，所以都要先有 baseline。

同一段 code 在 20 萬行單體裡要跑完整回歸，在 3,000 行邊界清楚的微前端裡讀 diff 就知道影響範圍。AI 時代的架構目標是讓系統容易被驗證。

微服務多半讓系統更慢更貴（網路延遲、運維成本），它換到的是團隊能平行前進。

三個代價：每個微前端各帶一份 React（要 Module Federation 共享）、shell 的 global state 是沒型別檢查的分散式 API、CSS 不會自動隔離。shell 是單點故障所以要極薄。

垂直整合的邊界：你驗證不了的領域 AI 幫不了你。廣度用來知道要問什麼、跟誰對接，深度仍要自己選一兩個方向長。

技術上叫後端多開一個聚合端點也行，但排程仍在他們手上——BFF 的價值是把決定權搬到前端團隊。

CDN 邊緣節點是 pull 模式：每區第一位使用者仍回源付完整延遲。光速是不可談判的限制，所以 CDN 是投入產出比最高的效能手段。

agent 不知道你的品牌色就會發明一個；有 --color-primary 和既有 <Button> 時它只需選用哪個。約束越強驗證越快。太早做元件庫是猜測，太晚要重寫。

對 agent 的價值是能沿 import 路徑追蹤真實依賴、看得到誰用了這個元件；跨 repo 時它以為在做局部修改，實際動到別人的介面。

讓 LLM 輸出決定畫面等於把不可信來源接到渲染路徑。第二個難題是狀態歸屬：使用者在 LLM 渲染的卡片上按了按鈕，要同時回到對話 context 與應用資料。

點下去才載入會把延遲從載入期搬到互動期，變成 INP 問題；閒置或 hover 時先偷偷載好。

同一站不同路由用不同策略是正常的。SSR 的成本不在渲染而在你多了一台要維運的伺服器；SEO 只涵蓋幾個公開頁時 SSG 幾乎總是更划算。

SSE 跑在普通 HTTP 上，CDN、代理、壓縮照用，內建自動重連；HTTP/1.1 每網域 6 條連線上限，幾個分頁就卡。AI 通訊不對稱，所以 LLM 應用都用它。

MVC 的 view 在伺服器：SEO 好、首屏快、不需要前端工程師，但任何互動都得整頁重載。歷史順序不是好壞順序。

這是後來冒出那麼多狀態管理工具的原因。今天 SEO 差的理由從「搜不到」變成「慢且不可靠」（社群預覽卡片不跑 JS）。

client 越厚版本管理越痛（使用者跑的可能是三週前的舊版）；厚度可以逐畫面選，RSC 就是讓元件樹一部分 thin 一部分 thick。

BFF 由前端擁有意味著接下部署、監控、on-call 與資安責任，比學 GraphQL 語法貴得多。

SSG 在 build 時產生（頁數 = build 時間），ISR 移到第一個過期後的請求。兩者前提都是內容不因人而異，要個人化就得 SSR。

實務兩個痛點：hydration mismatch（依賴時間、隨機值、window 的程式碼兩邊對不上）；RSC 的代價在心智模型，跨界只能傳可序列化資料。

靜態檔案曲線幾乎水平，每個請求跑一次 React 的伺服器曲線是斜的。該不該搬 Next.js 的問法：載入速度真的在傷害轉換率或排名嗎？有數據嗎？

真正值得留下的是依賴方向那條規則：讓不穩定的依賴穩定的——別讓資料抓取細節滲進元件、別讓 API 回應形狀直接當畫面狀態。

共用狀態把各團隊綁在同一份契約上，共用 CSS 沒有天然隔離。module federation 讓各應用共用一份 React 實例，但要求版本相容——版本協調正是這模式想消滅的。上千工程師才需要它。

「用 SSG 是因為商品頁要 SEO，個人化才用 SSR，因為不想放棄 CDN 快取」——有理由才從背下來的清單變成自己的決策。先稽核自己的 code base：在哪一站、為什麼、下一步。

Promise 一出生就在跑、沒有擁有者，所以 AbortController 得從外面另補一條取消通道。push-based 指值由來源主動推給你。

外面動不了，Observable 才能保證每次 subscribe 都重跑同一份說明書；這個限制之後由 Subject 補洞。

陣列的 map 立刻算完，stream 的 map 只是宣告「以後每個進來的值都這樣處理」，真正執行要等 subscribe。

元件掛載時就該看到現在的值，而不是等下一次變化；這是實務上最常見的 Subject 選型錯誤。

受控輸入是一個完整迴路：inputValue 下去、handleChange 上來、再下去，值繞一圈才回到畫面，中間才有位置插 debounce 與驗證。

marble diagram 上那條豎線在不在，決定你要不要自己收尾。

反過來說，一旦在手寫「這個請求過期要忽略」「這個訂閱要記得清」的旗標，stream 已經在你的程式裡了，只是還沒有名字。

請求照樣送出、伺服器照樣執行、cookie 照樣附帶，瀏覽器只是不把回應交給發起的頁面。同源 = 協定、網域、連接埠三者全等。

受害者必須在目標站已登入；攻擊者不需要知道帳密，只是借用你的瀏覽器。所以防禦不能靠「檢查請求長得對不對」。

CSRF 的根本問題不是「資訊不存在」而是「沒有人去驗」。SameSite cookie 2019 年後已成瀏覽器預設。

同源政策保護的是「資料」不是「動作」，CSRF 偷的是動作，兩者從頭到尾沒衝突。防線在伺服器的驗證，不在瀏覽器。

不對抗限制而是把限制納入設計：「把不可控的字元吞進字串字面值」在注入類漏洞裡反覆出現。預設 urlencoded 會把大括號百分號編碼。

主控台的同源錯誤無關緊要——失敗的只是「讀回應」，攻擊不需要那一步。但這條捷徑的短建立在「不設 Content-Type」上。

帶 cookie 的跨來源請求還需要 Allow-Credentials: true 且 ACAO 不能是 *；把 Origin 反射回 ACAO 就是對全世界敞開大門。

307 / 308 規範上必須維持方法與 body（301/302 會降級成 GET）。Flash 已死，但「換一個不受主流安全模型管的執行環境」這個模式沒消失。

有防護不等於安全：token 從別的端點外洩、或 token 可預測，任一成立防線就垮。

所以 DevTools 上 INP 顯示一橫槓不是頁面快，是還沒人按過。

preload scanner 在 parser 被卡住時已把 <img src> 請求發出去；LCP 記的是「畫完」不是「下載完」。所以修法要同時動 defer 和 preload。

defer 保證在解析後、DOMContentLoaded 前、多支維持書寫順序，適合有相依的應用碼；async 適合獨立的分析腳本。

所以「先讓使用者按了才長出來」是合法策略；分母是視窗，視窗縮小同一次位移罰得更重。現在用 session window 取最高的一段。

「寫死寬高會壞 RWD」2019 年後已不成立。長寬比真的未知時，容器直接寫 CSS aspect-ratio 或固定高度骨架。慢不會造成位移，資訊不足才會。

單次互動延遲 = input delay + processing time + presentation delay；長工作放大的是頭尾兩段，所以修法是切開讓出時間而不是把運算寫快。

少了那層包裝，同步設完文字緊接著開跑，畫面從 Process Data 直接跳 Done!。不碰 DOM 的運算更該丟 Web Worker。

三個病灶同一句話：瀏覽器需要的資訊或時間被別的東西佔走——繪製時機被腳本佔、排版尺寸缺席、執行緒時間被長工作佔。

兩個字都縮寫成 auth、常塞進同一個 middleware；看別人的 API 時別被 401 的名稱誤導。

token 上編碼的欄位叫 claims：sub 是誰、exp 何時到期、roles 角色；後面所有權限判斷讀的就是這些。

攻擊者合法登入、token 有效、每次請求都通過認證，但拿到不屬於他的東西——授權要防的是內部人。

判斷發生在主體帶來的角色與客體要求的角色相遇那一刻，所以不能只在入口做一次。漏寫一條規則的後果應該是打不開門。

藏按鈕的畫面看起來對了，但 API 照收請求、curl 就繞過；只信任入口，一個入口被繞過就全面失守。認證一 session 一次、授權每次存取都做。

新功能只需決定掛進哪些角色，新同事只需指派角色。role 給人看（你是哪類人），permission 給資源看（可以做哪件事）。

從管理員複製幾乎必留多餘權限；「北區付款管理員」「南區…」是角色爆炸，該換成 ABAC。

認證的難處是密碼雜湊、暴力破解、MFA、帳號復原這些跟業務無關卻極易做錯的細節；外部服務只能提供承載規則的機制。

這一行 div.innerHTML = comment.text 是整個 stored XSS 的根。人會忘記，所以防禦不能建立在「開發者永遠不犯錯」上。

DOM-based 是前端 JS 自己把 location.hash 寫進 DOM，server 從頭到尾沒碰過 payload。

CSP 是 server 告訴瀏覽器的規則，由瀏覽器執行，不是 server 自己做的過濾。嚴格政策還會擋 inline script 與 eval。

語法是「directive 空格 value；」不是 JS 的 key: value。另有 Content-Security-Policy-Report-Only 只回報不阻擋。

像 switch 的 default 分支：找不到資源類型對應的 directive 才用它。'self' 要加單引號，指同 scheme/host/port。

SPA 的主要阻力是打包工具產生的 inline script / style（webpack runtime、CSS-in-JS）；Next.js、Angular 已內建 nonce 支援。

upgrade-insecure-requests 把子資源 http 自動改 https；這其實防的是中間人竊聽竄改，不是 XSS。

寬鬆的 CSP 防不了什麼；'strict-dynamic' 可以省掉維護 origin 白名單。

檔案變了就換 URL，所以快取可以極長；age 由 CDN 回報「這份在快取裡待了多久」。

HTTPS 給兩件事：機密性來自加密、身分可信來自憑證鏈；自簽憑證有前者沒後者。TLS 1.3 已壓到 1-RTT。

SSE 自帶 id / retry，斷線後瀏覽器帶 Last-Event-ID 續傳；LLM 逐 token 串流正好是單向，所以 AI 應用幾乎都用 SSE。

同一個請求送一次和送十次最終狀態相同才叫冪等，這是 POST 之外還需要其他動詞的理由。

認清是控制權問題，才理解為什麼下一步要換一整層（GraphQL）而不是再開一個 /mobile-list 端點。

它靠事件迴圈一個 tick 收集所有 .load(id)，合併成一次 WHERE id IN (...)。N+1 也是 ORM lazy loading 的同款問題。

訂價或庫存邏輯一寫進 BFF，剛拆開的耦合就搬回前端團隊身上。自主權有價碼。

解法是 sticky session（分流不均）或 session 外置到 Redis；LB 自己也是單點，交給託管服務跨可用區。

design→code、效能（Core Web Vitals）、測試（覆蓋率）都寫得清楚所以被塗灰；邊界、code quality、狀態設計寫不清楚。

纏成一團的 codebase 逼 agent 讀整片檔案才敢動手，token 多、幻覺也多。

所以 AI 的產出「當下看起來很合理」——它確實對那一點做了最佳解，代價是推翻你之前的決定。

不能隨裝置縮放、跟其他頁面不一致；一致性重要是因為使用者的認知負荷，不是潔癖。

React 裡把元件定義在另一個元件內部，每次 render 產生新元件型別，子樹會被卸載重建、狀態丟失。

畢卡索公牛：找出不能再少的那組線；同一份資料只存一次，兩份就一定有不同步的那天。

不可能讀完每一行，但必須真的嘗過：邊界告訴你看哪裡、code smell 告訴你看什麼、靜態分析告訴你漏了多少。

所以無限產生 micro-task 會讓畫面卡死，無限的 setTimeout 不會。event listener 與 timer 進 macro，Promise 進 micro。

new Promise 的執行器同步跑、resolve 只是把 .then 丟進 micro-task；setTimeout 0 改成 1000 答案不變，考的是佇列優先權。

內層 scope 是外層的延伸不是複本：讀到的是外層變數當下的值，不是宣告時的快照。

忘了 removeEventListener、沒 clearInterval、閉包抓著大物件，都是「一個永生的根抓著一條你沒注意到的鏈」。

callback hell 難除錯的根因是錯誤沒有統一路徑，每層都得自己 if (err)，漏一層就靜默失敗。

await 把右邊包成 Promise、函式暫停交回 call stack，決議後剩下的本體當一個 micro-task 排隊。

async/await 讓程式碼看起來像同步，也讓人不小心真的寫成同步。

closure 記住外層變數，generator 更進一步記住自己執行到哪。這也是 async/await 能用 Babel + regenerator 在舊瀏覽器跑的原因。

「症狀」是儀表不是目標：不是越困惑越好，而是可以拿它讀出自己有沒有在連結資料點。

多數人的時間浪費在把困惑停在情緒層；操作層的困惑才是可以行動的。

篩選條件就是困惑感本身：困惑指向缺口，問句把缺口寫成可行動的形式。寫的當下大腦就已在歸位。

不困惑是因為資料沒有目的地、大腦不必歸位；指定目的地（現有 workflow）後才需要比對、才會發現對不上。

「有沒有 use case」對應的是「無法想像它長什麼樣」這種困惑；問句的粒度隨困惑種類調整。

答案會引出新困惑與新問題，所以它不是一次性工序。

困惑 = 有幾個點還沒連；overwhelmed = 點多到不知道從哪條線開始，而後者是自己讀出來的。

費曼技巧用「解釋不出來」、active recall 用「想不起來」當困惑訊號，核心動作同構。

server → HTML → CSS/JS/fonts → CSSOM/DOM → render tree → 四步渲染；head 裡的資源會擋住渲染。

LCP = 最大元素出現的時刻；CLS = 持續渲染時版面被推動；INP = 互動後重繪多久。

static import 在 build time 就進主 bundle、擋在渲染路徑上；dynamic import 才會被切成獨立 chunk，捲到／點到才載。

瀏覽器無法預知哪條規則影響第一個元素，所以必須把 CSS 全算完才敢畫；用 headless browser 找出首屏用到的規則。

micro frontends 優化的是團隊獨立部署與開發速度，不是執行效能（反而稍慢）。