在前後端分離、Web API、App Backend 或系統對系統 API 中,JWT(JSON Web Token) 是非常常見的驗證方式。
ASP.NET Core 8 JWT 驗證完整教學
- 15
- C#
在前後端分離、Web API、App Backend 或系統對系統 API 中,JWT(JSON Web Token) 是非常常見的驗證方式。
最近常常要幫客戶改後台裡面的 HTML,不過實際上大部分客戶根本不會自己去碰 Code
但如果直接把後台換成純 HTML Editor 也不太實際,客戶看到一堆 HTML 應該只會更不想改,而且像貼文字、改段落、上傳圖片這些操作,Summernote 這種 WYSIWYG 還是比較符合直覺 所以 Summernote 我還是想留著
OpenAI、Google 與 Anthropic 接連推出 GPT-6 Astra、Gemini 3.8 Flash、Claude Fable 5.1。本文依官方文件與 Artificial Analysis 的同一套評測,解析三款模型在能力、上下文、工具、多模態、速度、價格、安全與可用性上的差異,並提出個人、開發者與企業的實際選用建議。
從SQL Error Log查看SQL service重啟的原因
OpenClaw 2.0(正式版本號 v2026.8.1)是專案史上最大更新。本文交叉整理官方公告、完整發布說明、科技媒體與 YouTube 實測,深入比較新舊版在安裝、Web UI、會話、記憶、跨裝置運算、多人協作、憑證、外掛與自動化權限上的差異,並分析優缺點與安全升級方式。
本文探討現代敏捷團隊如何利用 Visual Paradigm 的 VPasCode 平台及其內嵌 AI 功能,解決傳統靜態架構圖難以維護與協作的痛點。透過介紹創新的「通過 AI 從圖像導入 C4 模型」功能,文章展示瞭如何將 PNG 或 JPEG 等靜態圖片瞬間轉換為可編輯、可版本控制的 PlantUML 代碼,從而打破供應商鎖定並提升開發靈活性。結合實戰步驟與最佳實踐,本文闡述了 VPasCode 如何協助團隊實現「圖表即代碼」的工作流,確保系統架構文檔能隨敏捷迭代同步演進,大幅提升技術溝通效率與文檔維護品質。
在 ASP.NET Core 接收或回傳約 1MB 以上的大型 JSON 陣列時,若直接用 List<T> 接收,底層陣列只要超過 85,000 bytes 就會直接丟進大型物件堆積(Large Object Heap, LOH)。在高並發下,這會引發頻繁的 Gen2 垃圾回收(Garbage Collection, GC)、記憶體碎片化甚至直接導致 OOM。這裡透過實測排查,示範如何用 ArrayPool<T> 池化與 IAsyncEnumerable<T> 串流解析徹底避開 LOH 與 OOM 壓力。

本文推薦這款擁有超過 20 年歷史、獲全球數百萬用戶信賴的 UML 建模工具,特別強調其社區版提供完整且免費的 UML 功能。文章詳解了類別圖的核心概念與關係語義,並展示其結合 AI 輔助與 VPasCode 雙向工程(代碼與圖形實時同步)的強大優勢,證明其不僅是文檔工具,更是提升團隊溝通效率與軟件設計質量的關鍵利器。
之前有寫過一篇:使用 C# 做一個假裝自己是 RDP Server
那時候主要就是用 C# 做一個假的 RDP Server,讓外面的 Scanner 連過來時,會認為這台機器真的有開 RDP
傳統 Agent 靠 grep 讀檔做跨檔案重構,面對大型專案常面臨 Context 塞爆、Token 暴增、推理迷路三大痛點。
程式碼知識圖譜,結合語法分析(AST)與向量,將呼叫關係預建為圖,直接提供精準子圖切片。本文以數十萬行的 aspnetcore 等大型 .NET 專案為標的,實測 7 款工具:
• code-review-graph
• gitnexus
• graphify
• Understand-Anything
• CodeGraph
• codebase-memory-mcp
• semble

面對每日一億筆(尖峰每秒破萬筆)的海量時序日誌 (Time Series Logs),傳統依賴關聯式資料庫 (SQL) 或手動按日建立索引(Time-based Index)的做法,往往會面臨寫入吞吐瓶頸、過度分片 (Over-sharding) 以及維運刪除繁瑣等問題。本文將從 SQL 與 Elasticsearch 的概念差異出發,透過 Docker 快速建立測試環境,並深入介紹如何利用 Data Stream 搭配索引生命週期管理 (ILM) 解決每日 Log 的寫入與自動輪轉問題,最後透過 ASP.NET Core 10 Web API 搭配基於 System.Threading.Channels 封裝的記憶體佇列類別 LogQueue 與背景消費者 LogBatchProcessor 實現高效能的非阻塞批次寫入與自動化測試。

在這次評測中,我們證實了 AI 生成的 C4 圖表並非簡化的玩具,而是承載了真實架構決策(企業邊界、非同步解耦、閘道模式)的專業產物。最重要的是,它將架構圖從「靜態交付物」轉變為「活的文件」。 下一步行動: 打開 Visual Paradigm,啟動 AI Chatbot,試著用一句話描述您的系統。從 Level 1 開始,讓 AI 生成 PlantUML,渲染圖表,然後逐層縮放。地圖將在對話中浮現,而程式碼將使其永存。
技術文件與系統建模的領域正經歷一場前所未有的典範轉移。過去,「Diagram-as-Code」(圖表即程式碼)工具雖然為版本控制和可重現性帶來了優勢,但繁瑣的語法記憶往往成為團隊推廣的阻礙。Visual Paradigm 旗下的 VPasCode 平台透過最新的重大更新,徹底改變了這一現狀。透過導入原生 AI 圖表生成 與 互動式 AI 程式碼修改 功能,VPasCode 已從單純的文字編輯器進化為自動化的對話式設計環境。
在 Github Action 要使用 Github Action 內建的 Bot 的一些小技巧
Flutter 專案的 Android compile toolchain 在 Gradle、AGP、Kotlin、JDK 這四個東西之間抓交集
整理 UOF WKF 外掛欄位整合 ERP 多筆明細資料至 Grid 列表的完整實作流程與開發規範,適用於 C# 5.0 (.NET Framework 4.5 包含) 開發環境
階層式資料流程圖(Hierarchical DFDs) 並非傳統瀑布模型的遺物,而是現代敏捷團隊釐清複雜系統的利器。它直觀、專注於數據流動,且完美契合迭代思維。更重要的是,結合 Visual Paradigm、AI Chatbot 與 VPasCode 這套現代化工具鏈,DFD 的繪製與維護已從「繁瑣的文書作業」轉變為「高效的需求工程」。
在現代系統分析中,極少有工件像資料流程圖 (Data Flow Diagram, DFD) 這樣經常被誤解。它常被與流程圖混淆,或被錯誤地套用物件導向術語。真正的 DFD 既不是控制流的描繪,也不是類別模型——它是對資料如何在系統邊界內移動與轉換的嚴謹功能規格說明。儘管敏捷方法論與微服務架構興起,DFD 仍然是定義範疇、與非技術利害關係人驗證需求,以及在撰寫任何程式碼之前確保架構一致性的黃金標準。
在複雜的系統分析領域中,清晰的溝通至關重要。所謂「一張圖勝過千言萬語」,這在系統建模中體現得尤為真切。資料流程圖(Data Flow Diagram, DFD) 至今仍是視覺化系統資訊流最有效率的傳統方法之一。無論是手動、自動化還是混合模式,精心設計的 DFD 都能以圖形方式描繪系統需求,展示資料如何進入、離開、轉換及儲存。
然而,建立 DFD 的方法論已隨時代演進。雖然理解基本符號與手動繪製技術對任何分析師而言仍是必備基礎,但現代工作流程已开始利用人工智慧(AI)來加速由上而下的分解(Top-Down Decomposition),並確保邏輯一致性。本綜合指南旨在彌合經典 DFD 理論與使用 Visual Paradigm 進行前沿 AI 輔助建模之間的差距,為您提供有效系統設計所需的基礎知識與先進工具。
寫 C# 久了之後,會發現效能改善不一定都要做到很複雜
很多時候不是要換架構,也不是一定要上什麼很進階的技巧, 反而只是一些平常寫 Code 時的小習慣
例如少查一次 Dictionary、少產生一個 String、少配置一個 Array,單看一次幾乎沒有差
但如果這段程式每天跑幾十萬、幾百萬次,這些小地方累積起來其實就有差了..
最近在 OpenCode IDE 上面接第三方中轉商的 API 中轉。
基本上只要對方有做 OpenAI Compatible API,要接進 OpenCode 都不難
Provider、baseURL、Model 設好,API Key 補上,大部分就可以直接跑
但我後來發現,自接模型雖然可以正常用,OpenCode 不一定知道這顆模型真正的規格
前言:拜 Vibe coding 之賜,市場上出現了一大堆的SaaS,每個都聲稱自己所開發的符合你的需求,當然也有些會打著—別人也 Vibe coding 過,但最後還是回來用我們的—這種聲稱,但是你真的確定你的資料放在別人那裡是安全的嗎?尤其是資料中包含個資 (特種個資更是重要) 時,當對方的 SaaS 發生資安事件導致資料外洩時,要怎麼處理及維護自己的權益?這些會遠比那些聲稱自己 Vibe coding 出來的 SaaS 有多好用要來得重要太多了—不怕一萬,只怕萬一。
前一篇測試了 Scriban,主要目的就是希望在 .NET 10 裡面
可以讓前端頁面在執行期直接修改,不用每次都重新 Build、Publish、Deploy..
前一篇測試了 RazorEngineCore,主要目的就是希望在 .NET 10 裡面
可以做到像以前 ASPX 一樣,前端頁面可以直接修改,不用每次都重新 Build、Publish、Deploy..
未參數化的直接查詢無法重用同一個執行計劃