平屋慢生活

商品頁防禦一 靜態化 / CDN防禦二 拆分資料層級防禦三 單 IP / Session 節流（Rate Limit）防禦四 行為觀察註冊登入API Key + Client IDsummary 商品頁的 GET，本來就是「給全世界看的」，不能靠「有沒有權限」來擋，只能靠「你打得像不像正常逛商品的人」來擋 GET /products/12345 不需要登入 不需要 token 不需要 cookie 瀏覽器、爬蟲、搜尋引擎都合法 你不能直接說「你沒資格看」! GET 天然就適合「狂打」，他無副作用、可被 cache、可被大量併發、可被簡單 script / curl / bot net 發送 不可能直接擋 GET，因為擋太嚴造成真實使用者 + SEO 都死光，而擋太鬆會被刷爆 商品頁 GET 一定要「設計成被打也不痛」 商品頁應該要有這些東西 CDN cache HTML / JSON 都可快取 Cache Key 控制好（shopId / productId） 所以機器人打的是 CDN，不是你後端 假如每個商品頁都 GET 商品頁 → 查商品 → 查庫存 ...

搶購後端 API 流量也透過 CloudFront 分流個人化資料限流判斷是否登入分流功能斷路（Feature Circuit Breaker）summary在一次搶購活動中，凌晨 00:00 一到，數十萬使用者同時按下「立即購買」。那一刻，不只是商品在被搶，你的伺服器資源也在被搶。CPU 飆滿、DB Connection Pool 撐爆、API Timeout、Error Rate 升高——這些都是典型的「高併發瞬間爆炸」現象。 如果把系統比喻成一條「城市水管」，平時水流穩定沒事，但一旦所有人同時打開水龍頭，就算是最大水管也會瞬間乾涸。這就是搶購系統      關鍵在於，系統能不能在高壓下「不垮」 「可控」與「分流」，我們希望把瞬間湧入的流量像導水渠一樣分散出去，讓「靜態內容走 CDN」、「個人化內容走限流」、「非關鍵功能可暫時關閉」。每個機制看似只是多加一層，但其實是為了在流量暴潮時，給系統一個喘息的空間 使用者打 API → 不是直接進 WebAPI 主機 → 而是先進 CloudFront，再由 CloudFront ...

AsNoTracking()關於使用 DbContext Update 效能最好笛卡兒爆炸非同步IQueryable / IEnumerable / IListSummary🔹 EF Core 為什麼需要 Tracking？在預設情況下，EF Core 查詢出來的物件會被放進 Change Tracker，它會記錄 哪些屬性被讀進來 哪些屬性值被修改 哪些 Entity 跟其他 Entity 有關聯 這樣 EF Core 才能在 SaveChanges() 的時候，自動知道要 Update/Insert/Delete 哪些資料。 🔹 Tracking 帶來的效能負擔Tracking 雖方便，但會多做很多事情 建立快照 (Snapshot)：每個 Entity 要存一份原始值，方便比對 變更偵測 (Change Detection)：每次存取或更新，EF 都要比對目前值與快照值 關聯維護 (Relationship Fixup)：要維護 Navigation Properties (例如 Order → Customer) 如果只是單純查詢 (Read-O ...

🔹 DbContext Pool直接執行 SQLTable-Valued Function (TVF)查詢快取和參數化foreach + SaveChanges() 很慢Summary建立一個 DbContext → 用完 → Dispose 掉，一般效能影響不大。但是如果你在一個高併發服務（例如 Web API，每個 Request 都要建一個 DbContext），那麼 每次都要 new 一個 DbContext EF Core 需要做初始化動作 CPU 與 GC 負擔增加 👉 在大量 Request 下就會有「明顯效能影響」。 🔹 DbContext Pooling (快取池)EF Core 提供 DbContext Pooling 功能，可以「重複利用」DbContext 實例，而不是每次都重新 new，當你 Dispose() 一個 DbContext 時，它並不會真的銷毀，而是放回 Pool (池子)，下次需要時，直接拿出來重用 → 減少建立成本，AddDbContextPool() 確實會 重複使用同一個 DbContext 實例，但 EF Core 在把它丟 ...

太陽拉麵B Tree Index經常變動的欄位上建立索引，有什麼風險？Clustered Index 與 Non-Clustered IndexIndex ScanClustered Index ScanSeek vs Scan 的「取捨邏輯」典型 Index Seek（少量、可定位）什麼狀況特別容易 Scan（而不是 Seek）summary一天，阿冠帶著夥伴腦袋與毛吉，到 LaLaport 尋找夢寐以求的「太陽拉麵」 到了商場門口，三人抬頭一看 哇哩！這地方足足有六層樓，還超級大！ 腦袋皺著眉說：「我們從一樓開始，一層一層慢慢找吧！」 毛吉在旁邊激動地汪汪叫：「阿烏旺旺旺旺！」看起來沒有甚麼幫助 阿冠搖搖頭，露出無奈的表情，仿佛已經習慣這一切 「Follow me」 三人走到一樓的樓層導覽地圖前，阿冠熟練地滑動著手指，找到了那行關鍵字：「🍜 太陽拉麵 → 3樓中區 C312」 「走吧！直奔三樓中區！」沒花幾分鐘，他們就聞到濃濃的豚骨香 腦袋驚呼：太神了吧！我們沒繞半圈就找到了！」 阿冠微微一笑，扶著眼鏡：「這是 Index 的力量!」在多數資料庫中（例 ...

啟動點流程 IIS 啟動網站應用程式池 (Application Pool) 當有請求進來時，IIS 會把 Request 交給 ASP.NET Runtime (w3wp.exe)。 w3wp.exe 是什麼？w3wp.exe = IIS 的 Worker Process（工作進程） IIS 6/7/8/10 都會用 Windows Process Activation Service (WAS) 啟動 w3wp.exe 每個 Application Pool 會有自己的 w3wp.exe 網站的程式碼、ASP.NET Runtime、Http Pipeline 都是在 w3wp.exe 裡面運作 👉 w3wp.exe 是容器（Container）──不是 Runtime 本身。 ASP.NET Runtime 是什麼ASP.NET Runtime 指的是： Page Handler Factory (System.Web)HTTP Pipeline（Modules + Handlers）Request Processing Pipeli ...

UseCorsUseAuthentication()UseAuthorization()UseStaticFilesUseRateLimiterUseResponseCachingUseHttpsRedirectionUseHsts結語CORS 的本質是瀏覽器端的安全機制（Same-Origin Policy 的例外白名單）。伺服器只透過回應標頭「宣告」哪些 Origin、方法、標頭被允許；最後放不放行是瀏覽器決定，他的角色是偵測跨域請求，依 Policy 加上允許的回應標頭。並且透過預檢且允許的方式，直接回 204/200 給瀏覽器，省去進一步處理。當不允許時，伺服器通常不加標頭、也不主動丟 403；接著的行為取決於你的管線/其他中介 🎀 Simple Request（簡單請求）瀏覽器送出真正的請求 例如 GET https://api.contoso.com/orders，同時自動帶上 Origin: https://app.example.com 標頭。 CORS Middleware（UseCors）判斷 如果政策允許這個 Origin，就在回應上加 A ...

GuardsCorrelationIdMiddleware一次性攔截所有請求，回傳 503 Service UnavailableApiKeyMiddleware結語想像你走進一片森林，每個訪問都是一個 HTTP 請求 🌳。森林裡的每個樹屋（Service / Middleware）都會依序經過，有的樹屋會幫你掛上名牌（CorrelationId），有的會在入口拉下柵欄（Maintenance Mode），還有的會檢查你有沒有森林通行證（API Key）。這些小樹屋站點就是 Middleware，它們靜靜地守護著這片森林，讓森林安全、有序 當系統有很多請求同時進來時，Log 會變得很亂。如果我們能幫每一條請求配一個 唯一編號 (Correlation Id)，那麼不論請求經過多少 Service，都能用這個編號把 Log 串起來。就好比 📦 快遞公司給每個包裹一個「物流追蹤碼」，你就能隨時查到它走過的所有路徑 嘗試從 Request Header 讀取 X-Correlation-ID（若前端傳進來就沿用） 若沒有，就自己產生一個 Guid 存到 HttpConte ...

關於順序ExceptionHandler（最外層）HSTS（嚴格要求瀏覽器以後都用 HTTPSHttpsRedirection（把 HTTP 導去 HTTPS）Static Files（靜態檔案：js/css/images）Routing（建立 Endpoint 資訊）CORS（跨網域規則）Authentication（驗證你是誰）Authorization（你能不能做這件事）Custom middlewares（你自己插的）實境演練Short-circuit（短路）會讓「後面永遠不執行」關於 Middleware 的順序，要把「會影響後面所有處理的規則」放前面、把「需要前面資訊才做得了的事」放後面，這樣每個 middleware 才拿得到它該拿的上下文，而且不會做白工或做錯事，順序決定了「誰先看到 Request」、「誰能先改/短路 Response」、「誰能拿到路由/使用者/權限資訊」 他把後面任何地方炸掉的例外「接住」，統一回應格式/錯誤頁，放最前是因為它要能包住整條管線，才能攔到所有後面丟出的 exception，假如放在後面，前面炸了它 ...

Middleware 的運作原理pipeline為什麼 Middleware 裡要寫 async？直接呼叫 next() 不行嗎？🌿 Map 分支🌿 RequestDelegate🌿 結語 想像一個 HTTP 請求進到伺服器，就像一場 接力賽跑 接力棒 就是 HttpContext，裡面裝著這次請求與回應的所有資訊 選手 就是一個 Middleware 接棒的手勢 就是 RequestDelegate 比賽終點 就是 Controller 或 Razor Page，產生最後的回應 ASP.NET Core 的 Middleware 機制，就是靠這樣一場「人人都要接棒」的比賽，把請求一路傳遞下去，直到完成回應 在 ASP.NET Core 中，整個 HTTP 請求(Request) 和 回應(Response) 的處理，就像一條 管線 (Pipeline)。這條管線是由一個個的小元件（我們叫它 Middleware）組合起來的。決定要不要把請求交給下一個中介軟體。在下一個中介軟體之前做事（例如：紀錄 log、驗證身分）。在下一個中介軟體之後做事（例如：修改回應、壓縮資料）。如果 ...