Quartz.NET 入門指南 - 打造可靠的.NET排程系統
前言排程任務在後端開發裡幾乎無所不在：定期備份資料、產生報表、發送郵件、執行系統維護。Quartz.NET 是 .NET 生態裡最成熟的開源排程框架，提供豐富的功能，也有足夠的彈性應對各種場景。 Scheduler Job Store Thread Pool Jobs Triggers Listeners Plugins Quartz.NET 是什麼?Quartz.NET 是 Java Quartz 排程框架的 .NET 移植版，提供企業級的排程功能： 支援複雜的排程模式（Cron 表達式） 具備叢集功能，可確保高可用性 提供任務持久化 彈性的錯誤處理機制 豐富的監控與管理功能 基本概念Quartz.NET 有三個核心元件： J...
API 介面限流完整技術指南
目錄 為什麼需要限流 常見限流策略 .NET Core 實作方案 分散式限流方案 最佳實踐建議 環境配置建議 效能測試方法 為什麼需要限流API 限流（Rate Limiting）的核心需求只有一個：保護服務本身不被流量壓垮，同時讓合法使用者繼續正常運作。這件事比聽起來更微妙——設太緊會誤殺正常請求，設太鬆則保護不到位。 幾個實際場景： 單一 IP 在 10 秒內打了 5,000 次請求，幾乎可以確定是爬蟲或攻擊 雲端服務按 API 呼叫次數計費，沒有限流的話一個 bug 就能讓帳單爆表 資料庫連線有上限，突發高併發會讓所有請求一起逾時，而非只讓超額的那些失敗 常見限流策略 限流策略 實作複雜度 記憶體消耗 精確度 突發流量處理 分散式實作 固定窗口 低 低 低 差 易 滑動窗口 中 中 高 中 ...
從零開始的 Docker 容器化指南: Vue3 + .NET Core + SQL Server
目錄 Docker 基礎概念 環境準備 SQL Server 容器設定 .NET Core API 容器化 Vue3 前端容器化 使用 Docker Compose 整合服務 資源管理與監控 開發環境設定 網路配置 部署與維護 常見問題與解決方案 Docker 基礎概念Docker 是一個開放原始碼的容器化平台，把應用程式和它的依賴項打包成獨立容器，讓同一份設定在本機開發、測試機、正式環境都能跑出相同結果。 這套技術組合讓你少踩的坑：「我本機跑得起來但 CI 就壞了」基本上絕跡、新人 onboarding 不再花一天裝環境、版本升級可以先切新容器測試再切流量。代價是要花時間學 Dockerfile 和 Compose 的寫法——這篇就是從這裡開始。 環境準備 安裝 Docker Desktop 12345678# Windows/Mac 下載並安裝 Docker Desktophttps://www.docker.com/products/docker-desktop/# Linux (Ubuntu) 安裝 Docker Enginesudo apt updatesudo ap...
從Newtonsoft.Json遷移到System.Text.Json的經驗分享
為什麼要換.NET Core 之後，Microsoft 把 System.Text.Json 直接內建進框架，不用另外裝 NuGet 套件，少一個外部相依。效能上，官方 benchmark 顯示序列化速度比 Newtonsoft.Json 快約 2 倍，記憶體分配也更省。對大多數 Web API 專案來說，日常夠用。 真正讓人猶豫的是行為差異。兩套函式庫有幾個預設值不一樣，遷移時踩到的坑大多出在這裡。我前後把幾個中型 API 專案換過來，下面這幾個點是實際撞到、查到根因才搞定的。 坑一：JSON 輸出變成小駝峰問題現象把序列化從 Newtonsoft.Json 換成 System.Text.Json 之後，原本 "UserName" 這類 Pascal Case 輸出，跑到 ASP.NET Core Web API 回傳時突然變成 "userName"，前端開始炸。 真正的原因這個問題有個很容易踩的誤區：System.Text.Json 函式庫本身的預設 PropertyNamingPolicy 是 null，也就是保持原始屬性名稱不變。...
.NET Core 中的中間件（Middleware）
.NET Core 中的中間件（Middleware）詳解什麼是中間件？在 .NET Core 應用程式中，中間件是一系列組件，它們形成了一個請求處理管道。每個中間件都可以: 處理傳入的 HTTP 請求 處理傳出的 HTTP 回應 呼叫管道中的下一個中間件 在管道中的下一個中間件完成處理後執行某些操作 中間件的概念類似於一條組裝線，每個工人（中間件）都對產品（請求/回應）進行某些操作。 中間件的工作原理中間件在 .NET Core 應用程式中按照特定的順序執行。這個順序很重要，因為它決定了哪個中間件先處理請求，以及回應如何被處理。 工作流程如下： 當應用程式接收到 HTTP 請求時，請求進入中間件管道。 每個中間件組件可以: 執行一些操作 將請求傳遞給下一個中間件 或者短路請求（不再傳遞給後續中間件） 一旦請求到達管道的末端，它會開始返回。 回應會再次通過所有中間件，讓每個中間件有機會處理或修改回應。 這個過程可以用下面的示意圖來表示： 12Request → Middleware 1 → Middleware 2 → Middleware 3 → Applicati...
.NET Core 中的依賴注入和控制反轉
IoC（控制反轉）和 DI（依賴注入）常被混用，但兩者的層次不同：IoC 是設計原則，DI 是實現手段之一。搞清楚這個關係，才不會看到「容器」兩字就覺得是 IoC 的全部。 控制反轉 (IoC) 是什麼傳統寫法裡，程式碼自己決定何時建立依賴、用哪個實作——控制權在你的類別手上。IoC 把這個控制權交出去：由外部（框架、容器、或呼叫方）決定要注入什麼。 IoC 並不等於 DI 容器。Martin Fowler 最早定義 IoC 時，涵蓋了 Service Locator、Template Method、以及依賴注入等多種形式。DI 容器只是實現 IoC 最常見的一種工具。 IoC 帶來的實際好處： 解耦：類別依賴介面而非具體實作，替換實作時不需動到使用方。 可測試性：測試時可把真實依賴換成 mock，不需啟動整個應用程式。 可擴展性：新增實作、切換策略，不需修改現有程式碼。 這三點都源自同一個機制——類別不再自己 new 依賴，而是被動接受注入。 依賴注入 (DI) 的注入方式DI 的核心想法：不在類別內部建立依賴物件，改由外部傳入。 注入方式有三種，但在 .NET 內建 DI...
為甚麼應該從.Net Framework跳到.Net Core?
從 .NET Framework 到 .NET Core：一個必要的轉變.NET Framework 和 .NET Core（現稱 .NET）不是競爭的替代品——它們代表不同世代的設計決策。.NET Framework 誕生於 2002 年，綁死在 Windows 上；.NET Core 從 2016 年起重新設計，跨平台、開源、模組化。微軟已明確宣告 .NET Framework 4.8.1 是最後一個主要版本，不再加入新功能，只做安全性修補。這個時間點對正在評估是否遷移的團隊來說是最實際的理由。 以下從四個面向說明差異。 跨平台.NET Core 從設計之初就以跨平台為目標，同一份程式碼可以在 Windows、Linux 和 macOS 上建置與執行。這對想把工作負載搬上 Linux 容器或雲端的團隊影響最直接：容器基底映像可以選更精簡的 Linux 版本，不必帶著 Windows Server 授權費。 .NET Framework 本身只支援 Windows。Mono 是另一個獨立的開源 .NET 實作（最初由 Novell/Xamarin 開發，2016 年 Micr...
