Hero Image
Postman

Postman 使用筆記 Postman 功能 登入1，撰寫測試 安裝 Postman Desktop 不要使用線上版，會有資料同步卡頓的問題 登入 Postman Workspaces 建立或選擇 Workspaces 測試命名 Controller/Action+ 如有其他必要說明 環境變數 可以自訂各種會因環境變化必須自訂的參數 環境變數抽換參數 比如新增環境變數 baseUrl，測試 api baseUrl 不要寫死在測試範例，使用環境變數已切換實際測試連線 Mock Server 前端開發超前後端進度時 想要模擬溝通後端 api 使用 2 新增測試資料 撰寫測試資料 查看 mock url 前端開發使用測試 Api https://64680c7d-60de-4ffe-abb7-462f3958d8df.mock.pstmn.io/Car/GetCar 開發相關 Nuxt API 開發 每開發一支 api 就要登入 Postman 新增一個測試資料 api 連線 mock : postman mock nitro: { devProxy: { '/mockStoreApi': { target: "https://64680c7d-60de-4ffe-abb7-462f3958d8df.mock.pstmn.io", changeOrigin: true, secure: false, }, api 連線 mock : postman mock 模擬資料建立

Sunday, January 25, 2026 | 1 minute Read
Hero Image
Store

Store 狀態管理 Store 全局狀態管理（state management） 核心職責： 管理記憶體 state (在單次 session 中統一管理記憶體中的資料結構) 可觀察/可修改的接口，供外部 get/set store porperties 相對應的技術工具 React 生態：Redux、Zustand、MobX、Recoil、Jotai、Effector Vue 生態：Vuex、Pinia Angular 生態：NgRx、Akita Persistence：可選功能，用於跨 reload / 瀏覽器存活，沒有 Persistence 也能跨 component / module 共用 state，如服務是靜態的 SPA，就不需要考慮 Persistence Store 用途 能力 說明 範例 全局單例管理 state 在多個 component 間共享同一份 state 多個 component 都能讀 store.count，更新一處其他地方立即反應 Action orchestration 集中定義行為（副作用） store.increment() 自動更新 state，而所有使用者都看到最新值 Computed / getters 派生 state store.doubleCount = store.count 2 Hooks / 監聽器 訂閱 state 變化 store.$subscribe((mutation, state) => { console.log(state.count) }) 組織邏輯 把相關 state 與操作放在一起 比較清楚的模組邏輯，避免散落 function Store Persistence state 只存在於瀏覽器的記憶體 ( RAM )，生命週期受限於頁面執行環境( 刷新頁面、關閉分頁或跨頁，記憶體會被清空 )。

Thursday, January 22, 2026 | 2 minutes Read
Hero Image
Design Reflection

需求設計與反省 最近面試遇到些需要我描述 SA 或是 SD 的工作經驗描述，發現我講得的零零落落的，不然就是根本忘了，故挑幾點印象比較深刻做文字整理，以便以後需要的時候可以回來這裡回想。 郵局信箱與招領 所有信箱都來自實際存在的地址，在第一次申請(141)建立可投遞的信箱維護所有基本資料(姓名、電話等等…)依賴信箱主檔與客戶基本檔。 實際投遞遇到問題或是租戶自行申請將影響信箱狀態變更(142 狀態如:續租或暫停使用等等…)，影響信箱生命存續終止(145、146 如退租、屆期未續、轉空戶)。 若通訊地址有更改請先執行維護信箱交易(154 調整為改投或i郵箱)再執行退租，此時的通訊地址才會正確。 由多個交易可以看出信箱的所有狀態與存續的的生命週期。 所有變更資料面依賴信箱主檔、變更歷程寫入 BoxChange_LG(變更歷程)且幾乎所有報表查詢都會依賴變更歷程的最新一筆。 大量的計算邏輯(報表 781、782…)有大量的 sql 重複查詢，其實就是不同的查詢條件，可以彙總成共用 lib 抽離不同件數計算邏輯，不需要每個欄位都一個複雜又重工的 sql 指令。 反省: 礙於專案時程壓力，只好先寫寫看在再回過頭看需求細節的真實用意，其實很危險，很多姑且先寫寫看的功能，都會在終於懂得哪一刻發現很多多此一舉的地方，甚至在 QA 深入各個交易互測階段發現一些明顯邏輯不通的錯誤。 如果可以先了解欄位/物件真義，再進行開發還是比較好，但就是會需要說服 SA 把其他相關的交易規格都拿到，即便是大致掃一眼也是好的。 個資軌跡 h 銀行 個資軌跡交易類別，依 dal 實際邏輯做 function 做預設值參考，服務可以傳入參數強制改為要或不要寫入個資軌跡。 trackType比如: 查詢(新增/修改/刪除交易的查詢、新增 、修改 、刪除 等等。 db Entity 新增 annotation 註記不同機敏程度的代號，透過共用的 Repositary 層偵測更新的 model 牽涉機敏欄位多寡來記錄個資軌跡，並抽離以方便維護是否紀錄的邏輯 if (A_TypeCount >= 2 || (A_TypeCount >= 1 && B_TypeCount >= 1)) return 則記錄個資軌跡; 反省: 資料面攔截所有系統的機敏軌跡，但忽略列的業務邏輯層建立的 dto 也有個資，dal 可以寫入的內容有限，只能記錄自定義的 trackType 且依賴回傳的 TEntity result，如果回傳結果有多層 entities 結構，無法紀錄深層機敏資料( 多層 Entity 結構 )且會顯示 Expression Tree (LINQ 原始表達式字串) 無法讀取內容物例如: c.IdNo == value(HuaNan.Service+<>c__DisplayClass3_0).input.IdNo)

Monday, January 12, 2026 | 1 minute Read
Hero Image
Distributed System

Distributed System 分散式系統設計，Net 8 服務，啟用 nginx upstream 從單機到多實例後，遇到的設計問題。 核心概念：Stateless Service 什麼是 Stateless？ 定義：服務的每個實例不保留任何與特定請求或使用者相關的狀態資訊。 為什麼需要 Stateless？ ┌─────────┐ ┌──────────────┐ ┌──────────┐ │ Client │────▶│ Load Balancer│────▶│Instance A│ └─────────┘ └──────────────┘ ├──────────┤ │ │Instance B│ │ ├──────────┤ └─────────────▶ │Instance C│ └──────────┘ 當你的系統從 1 台機器擴展到 N 台時： 請求分散：用戶的連續請求可能落在不同實例 實例隨時變動：Auto-scaling 會新增/移除實例 故障轉移：某個實例掛掉,流量會轉到其他實例 ❌ 禁止使用的狀態儲存方式 方式 為什麼不行 實際案例 IMemoryCache 只存在單一實例 User A 的資料在 Instance A,但下次請求到 Instance B static 變數 無法跨實例共享 計數器在每個實例都是獨立的 Singleton 內部狀態 每個實例有自己的 Singleton Session 資料只存在啟動該請求的實例 檔案系統 本地儲存 上傳的檔案只在一台機器上 ✅ 狀態必須外部化 所有狀態都必須存放在所有實例都能存取的外部系統：

Monday, January 5, 2026 | 8 minutes Read
Hero Image
NFS

NFS Local-like File Access 類本地讀寫 Network FileSystem 網路檔案系統，NFS 是一種讓多台電腦可以像操作本地硬碟一樣訪問遠端檔案的系統。 是一種 RPC Service（Remote Procedure Call），當你用 NFS 讀寫檔案時，客戶端其實是在透過 RPC 向伺服器發送「打開檔案」「讀檔案」「寫檔案」這些遠端操作的請求， Dynamic Port Allocation 動態端口 容器配置不需要額外維護 port export，rpcbind 會自動協調服務所使用的 TCP/UDP port，並且同一個 network 內的容器可以直接訪問這些 port；若存在防火牆或跨主機通信時，則需要額外開通對應 port，配置相對複雜。 Server/Client 伺服器/客戶端 因為是一種 RPC Service，所以會有兩種角色 Server、Client 就像 FileZilla 也是，你要遠端可以 FileZilla 連到，你需要在 target server 安裝 FileZilla server 或其他 ftp 類型 server on 著 listening ( 持續運行以監聽連線請求 ) 當 server 啟用時，可以讓服務跨 os、跨 server，同步讀取、寫入本地檔案。 ┌─────────────────┐ 網路 ┌─────────────────┐ │ NFS Server │ <─────────────────> │ NFS Client │ │ (141) │ │ (142) │ │ │ │ │ │ /nfs (實體目錄) │ ─────匯出(export)──> │ /nfs (掛載點) │ │ chmod 777 │ │ mount 後可存取 │ └─────────────────┘ └─────────────────┘ 安裝 Windows 啟用 server/client 開啟或關閉 Windows 功能

Friday, January 2, 2026 | 5 minutes Read
Hero Image
Test Tool

Test Tool Listed Tool StressTesting 壓力測試: JMeter、Nbomber End-to-End Test E2E 測試: Automa StressTesting JMeter //Todo Nbomber //Todo End-to-End Test Automa //Todo 補充 All Types of Test 文章提及工具: 壓力測試、E2E 測試 功能性測試 單元測試 (Unit Test) - 測試最小可測試單元 整合測試 (Integration Test) - 測試模組間的介面與互動 系統測試 (System Test) - 測試完整系統功能 驗收測試 (Acceptance Test) - 驗證系統是否符合需求 冒煙測試 (Smoke Test) - 快速驗證主要功能是否正常 回歸測試 (Regression Test) - 確保新改動不影響既有功能 非功能性測試 效能測試 (Performance Test) - 測試系統效能表現 負載測試 (Load Test) - 測試預期負載下的表現 🟢 壓力測試 (Stress Test) - 測試極限負載: JMeter、Nbomber 尖峰測試 (Spike Test) - 測試突發流量 耐久測試 (Endurance/Soak Test) - 測試長時間運行穩定性 安全測試 (Security Test) - 測試系統安全性與漏洞 相容性測試 (Compatibility Test) - 測試不同環境、瀏覽器、裝置的相容性 可用性測試 (Usability Test) - 測試使用者體驗 UI 相關測試 🟢 E2E 測試 (End-to-End Test) - 模擬使用者完整操作流程: Automa UI 測試 - 測試介面元件與互動 視覺回歸測試 (Visual Regression Test) - 比對畫面截圖差異 其他測試類型 探索性測試 (Exploratory Test) - 手動探索系統行為 混沌工程測試 (Chaos Engineering) - 主動注入故障測試韌性 A/B 測試 - 比較不同版本效果 災難復原測試 (Disaster Recovery Test) - 測試系統復原能力

Monday, December 22, 2025 | 1 minute Read
Hero Image
RAG

RAG Retrieval-Augmented Generation RAG（檢索增強生成）是一種架構模式。 在 LLM 生成答案前，先從外部知識庫檢索相關資料，再將檢索結果提供給模型作為上下文，提升回答的正確性、可控性與即時性。 LLM 的本質：條件機率模型（Conditional Probability Model） 定義 大型語言模型（LLM）的核心任務只有一個：在給定前文條件下，預測下一個 token 的機率分佈。 數學形式為： P(token_t | token_1 … token_{t-1}) 表示在給定前文 token 的情況下，模型預測下一個 token 的機率。 這個機率分佈是由模型內部的所有參數（weights）共同決定的。 這些參數並不儲存任何可直接查詢的知識內容，而是隱式地編碼了大量語言片段之間的統計關聯與結構模式。 LLM 並不具備「查詢」、「記憶文件」或「事實驗證」能力。 LLM「知識」從何而來 X LLM 沒有文件 X LLM 沒有資料表 X LLM 沒有條目式知識 O 參數空間中所編碼的統計關聯結構 壓縮後的語言世界模型 訓練階段：把世界「壓縮」成參數，訓練資料（書籍、文件、程式碼、維基百科）僅用於不斷調整模型參數，強化 token 與 token 之間的關聯機率 資料不會被儲存，僅留下統計痕跡。 小模型仍「看起來懂很多」 多數人類知識是低熵、可高度壓縮的 技術文件與教科書高度模板化 (token 關聯穩定) 常識與基礎知識在語料中反覆出現 因此：只需要很少參數就能學到這種穩定規律，LLM 並非記住內容，而是學會「怎樣說才像懂」。 Transformer 擅長「關聯建模」 世界不是隨機的，而是高度可壓縮： 長距離 token 關聯 抽象語義空間 結構對齊（Structure Alignment） Transformer 等於一個超強壓縮器，這讓它可以： 將問題對齊到「已見過的語言模式」 再生成對應回應 回答不是「查到」，而是「生成」，不是回憶，是重建 類比

Monday, December 22, 2025 | 2 minutes Read
Hero Image
Multi-Tenant JWT Authentication

LineCRM.CarCare 登入架構說明 Multi-Tenant JWT Authentication 多租戶（Multi-Tenant）JWT 雙 Token 認證機制（Access Token + Refresh Token），支援商店用戶（Store）與客戶用戶（Customer）兩種身份類型的獨立認證流程。透過泛型設計與介面抽象，實現了可擴展的多角色登入系統，並結合 Redis 快取機制管理 Refresh Token，提供安全且高效的身份驗證解決方案。 Key Features 雙 Token 機制：Access Token (短效) + Refresh Token (長效) 多角色支援：Store User 與 Customer User 獨立認證 自動 Token 更新：Middleware 自動偵測過期並刷新 分散式快取：Redis 管理 Refresh Token 狀態 安全性強化：HttpOnly Cookie + CSRF 防護 可擴展架構：新增用戶類型僅需實作兩個介面 1. Adapter Pattern (適配器模式) 位置： StoreInfo 、 CustomerInfo、 IClaimAdapter.cs public interface IClaimAdapter<CurrentUser> { IEnumerable<Claim> GetClaims(); static abstract CurrentUser? FromClaimsPrincipal(ClaimsPrincipal principal); } public class CustomerContext : AppDataContext<CustomerInfo> { public CustomerContext(IHttpContextAccessor httpContextAccessor, IBaseLogger log) : base(httpContextAccessor, log) { } public override CustomerInfo? CurrentUser { get { var user = _httpContextAccessor.HttpContext?.User; return CustomerInfo.FromClaimsPrincipal(user); } } } public class CustomerInfo : IClaimAdapter<CustomerInfo> { public IEnumerable<Claim> GetClaims(){} public static CustomerInfo? FromClaimsPrincipal(ClaimsPrincipal principal){} } 說明：

Thursday, December 11, 2025 | 2 minutes Read
Hero Image
Nuxt

Nuxt3 Nuxt 前端，整合 Net 後端全站開發筆記 專案準備 git clone 手動指令安裝 pnpm 安裝相依套件：pnpm install 建立正式編譯檔：pnpm run build 啟動開發伺服器：pnpm run dev pnpm啟動完畢 專案設定的 url 是 設定完畢後，pnpm run dev 開發伺服器完畢，可使用F5 啟動偵錯 測試帳號準備與登入 檔案結構目錄 共同開發說明>開發注意事項>前端開發>檔案結構目錄 撥空了解 Nuxt 結構目錄 https://clairechang.tw/2023/07/07/nuxt3/nuxt-v3-directory-structure/ 請深入閱讀必要了解項目 pages/、layouts/、components/ → 頁面結構與 UI 組合 composables/ → 邏輯封裝、狀態管理 plugins/、middleware/ → 應用啟動與權限控制 stores/ → 使用 Pinia 管理狀態 檔案結構目錄-components component/{pages Name} 作為子元件與父元件 ( pages.vue ) 溝通使用 抽離元件邏輯，避免 pages/{router}/{subRouter}.vue 理由: 行數過多不好閱讀: SOLID 的第一條，SRP ，一個模組不應處理過多事情 頁面可以精簡僅負責整合 api 回傳與 UI 顯示、pages/*.vue 行數控制在 300 行以內。

Thursday, November 27, 2025 | 6 minutes Read
Hero Image
JWT

JWT JWT 架構與實務筆記 概念整理 JWT 基礎概念 JWT 組成（Header、Payload、Signature） Header Header 描述 這顆 Token 用什麼演算法簽的，以及它是什麼型別。 常見 alg alg 說明 HS256 HMAC + SHA256（對稱金鑰） RS256 RSA + SHA256（非對稱） ES256 ECDSA + SHA256（非對稱） Payload Payload 是真正要傳遞的身分與權限資料，它是 JWT 的核心。 Payload 分三類 Claim： Registered Claims（標準欄位） Public Claims（公開欄位） Private Claims（自定義欄位）: 自由取名 標準欄位 欄位 意義 iss Token 發行者 sub 主體（通常是 userId） aud 接收者 exp 過期時間（必須） nbf 何時才有效 iat 簽發時間 jti Token ID（可用於黑名單） Public Claims（公開欄位） 必須避免與標準欄位衝突。 例如： { "email": "a@b.com", "company": "OpenAI" } Private Claims（自定義欄位）

Tuesday, November 11, 2025 | 3 minutes Read
Hero Image
Typora

Typora a nice .md file editor IDE 撰寫者：Amanda Chou 日期：2025/04/17 .md ? md 是什麼? Markdown 文件的副檔名 Markdown 又是什麼? Markdown ? **Markdown **是一種輕量級標記式語言，創始人為約翰·格魯伯。 使用易讀易寫的純文字格式編寫文件，然後轉換成有效的XHTML（或者HTML）文件。 這種語言吸收了很多在電子郵件中已有的純文字標記的特性。 輕量化、易讀易寫特性，並且對於圖片，圖表、數學式都有支援 Markdown 用途廣泛 目前許多網站都廣泛使用Markdown來撰寫說明文件或是用於論壇上發表訊息。如GitHub、Reddit、Discord、Diaspora、Stack Exchange、OpenStreetMap 、SourceForge、簡書等，甚至還能被用來撰寫電子書。 之前介紹的 Vue 文件 重新認識 Vue.js | Kuro Hsu git book 也是 深入淺出 GitBook 寫作與自助出版，電子書也能多人協作 HackMD 也是 小題大作的30個 HackMD 技巧 現在演示的這個投影片也是 md fille 怎麼變 slide? 後面針對匯出章節會提到 Why Markdown 輕量易用：Markdown 語法簡單直觀，幾乎無學習成本。(幾乎沒有，但還是有一點，語法還是需要熟悉一下) 高度可移植：Markdown 文件是純文字格式，可以在任何平台上查看或編輯，方便與版本控制工具，適合開發者和團隊協作。 多用途輸出：支援導出為 PDF、HTML、Word、Slides 等多種格式。特別適合技術文件、筆記、部落格文章等用途。 多輸出主要是依賴 Pandoc 工具支援，後面針對匯出章節會提到 強大的生態系統：可擴展性強，支持 LaTeX（數學公式）、圖表（如 mermaid.js）、代碼高亮等功能。 開放性標準：Markdown 是一種開放格式，無專屬軟體依賴，確保文件長期可讀。 參考: 寫作＆筆記神器 MarkDown 真希望我學生時期就懂 分享了 dillinger, Typora 還有影片介紹 Why Markdown 只要可以版控，就會好找很多 如果有要找，版控，就會好找很多

Thursday, April 17, 2025 | 5 minutes Read
Hero Image
Introduction

This is where I document my work experiences and technical reflections, with a focus on software development, system architecture, DevOps, and real-world problem solving. Every article comes from issues encountered in actual projects: the pitfalls I ran into and the solutions I found. I hope this helps my future self review things more efficiently, and also saves you some detours if you are facing similar problems. All articles are currently written in Chinese. If you are viewing this site in a multilingual interface, please switch the site language to “Chinese” to see the full list of posts and category index.

    Monday, June 8, 2020 | 1 minute Read