Casting
Stone StoryImplicit CastingExplicit CastingUpcastingDowncastingBoxing (裝箱) 與 Unboxing (拆箱) - 比較舊的快取系統Boxing (裝箱) 與 Unboxing (拆箱) - 快取或屬性容器結語有一塊碎石，曾在河岸邊靜靜沉睡百年。它堅硬、粗糙、不懂流動。直到有一天，一條溪水與它擦身而過。
「你怎麼總是不動？」水問
「我就是這樣被造的，不像你，總能輕盈地轉彎、改道。」碎石低聲說
「但你知道嗎？」水輕聲笑道，「我之所以能走那麼遠，是因為我願意轉。」
碎石覺得，那句話如同一道光，悄悄劃過它堅硬的內裡。它開始想：如果有一天，我也能在某個時刻學會轉型 —— 也許，我也能成為某種形式的流動看看這個世界更多的樣貌。
在程式的語法中，我們見證數字從一種型態變成另一種形態、物件從一個面貌蛻變為更適配的角色。這些「轉型」，看似只是語法上的操作，實則承載著如何讓資料 順勢而生、應需而變 的深意。
而我們，是否也能從中學會，如何在對的時機，捨去執念、跨越邊界？如何在堅固與柔軟之間，找到最合宜的模樣？
一個電子商務網站的購物車 ...
EF Core - NotSupportedException
NotSupportedException:
描述: 當試圖使用資料庫不支援的功能時引發，或者當特定操作不適用於當前操作的提供者時引發。
例子: 嘗試使用某些特定於 SQL Server 或 SQLite 的功能，但資料庫供應者不支援這些功能。
https://hackmd.io/@CloudyWing/ryWlBCwcA
EF Core - TimeoutException
TimeoutException:
描述: 當嘗試與資料庫進行交互時，操作超時未能完成時引發。
例子: 執行一個複雜的查詢或更新操作，但是在預定的時間內未能完成。
EF Core - InvalidOperationException
程式世界裡最令人頭痛的，從來不是錯誤訊息，而是「有時錯，有時對」的那種模糊不明。你是不是也曾遇過：明明昨天的程式還好好的，今天一跑卻爆了 InvalidOperationException？
這不是你寫錯，而是你不小心跨越了 DbContext 的界線。就像在海上行船，一不小心就漂出了領海，進入無人知曉的風暴。
這篇文章將帶你從根源理解 InvalidOperationException 的幾個常見場景，並透過範例與圖解，一次性釐清觀念，避免未來再被神祕的錯誤訊息追殺。
💥 DbContext 實例重複使用｜一艘船不能載兩個船長問題來源當你在多個請求或執行緒間重複使用同一個 DbContext 實例，就可能觸發 InvalidOperationException。為什麼？因為…
❗ DbContext 不是 Thread-Safe 的物件。
它內部維護著實體狀態（Added, Modified, Deleted…），而這些狀態並不是為多執行緒設計的。你讓多個線程同時操控 DbContext，就像讓兩個船長同時掌舵 —— 翻船。
12345678910public class ...
EF Core - DbUpdateConcurrencyException
Google 文件Concurrency（並行）DbUpdateConcurrencyExceptionRowVersion：守門的指紋那發生例外時該怎麼辦？summary想像你和同事一起編輯一份 Google 文件，你正專心致志地輸入「我們應該大力加薪」，正當你按下儲存，結果——對方也在同一秒按下儲存，而他打的是：「大家應該自願減薪來展現團隊精神。」
🙃 到底誰的才算？你打的血汗心聲，還是對方的職場邪教宣言？１這，就是所謂的 並行更新（Concurrency）問題。而 EF Core 的 DbUpdateConcurrencyException 就是在提醒你：「欸欸欸，有人先改過這筆資料囉！」
Concurrency 指的是「多個流程同時存取並可能修改同一筆資料」的情況，這在多人協作系統中非常常見，例如：
多位使用者同時編輯同一筆訂單或資料。
他們都按下儲存。
如果系統沒有檢查誰先誰後，那麼後儲存的人將會直接覆蓋掉前面的變更。
這會帶來許多潛在問題：
✅ 使用者的更新被悄悄蓋掉，卻毫無察覺
✅ 系統記錄出現矛盾，無法追蹤真實修改者
✅ 使用者困惑：「剛剛不是明明有改成 ...
EF Core - 資料是否存在
ExistSQL 寫法：COUNT vs EXISTS會員有沒有下過單SQL 寫法：COUNT vs EXISTSEF Core Count vs Any複雜查詢whisper
「當我們只想確認某人是否出現過，沒必要翻遍整本通訊錄。」
在資料庫的世界裡，我們經常會遇到一個簡單卻重要的問題：資料是否存在？
不論是確認某個用戶是否曾下單、某篇文章是否已發佈，這些判斷存在與否的查詢看似簡單，卻往往決定了系統的效能與延遲。尤其當資料表龐大、條件複雜時，使用錯誤的寫法可能導致嚴重的效能問題。
今天，我們就從 SQL 與 EF Core 的角度，來聊聊「資料是否存在」
如果只是想知道「是否有訂單」
COUNT1234IF (SELECT COUNT(*) FROM Orders WHERE CustomerID = 'ALFKI') > 0BEGIN PRINT '有訂單'END
但其實效能更佳的寫法是使用 EXISTS
1234IF EXISTS (SELECT 1 FROM Orders WHERE CustomerID = ' ...
EF Core - DbUpdateException
hidden reef主鍵（Primary Key）衝突，一碼歸一人外鍵（Foreign Key）違反，找不到對應人必填欄位（NOT NULL）為 null : 不該留白的愛欄位長度限制超過（MaxLength/Size） : 你話太多了資料類型不相符 : 能飛不代表能跑違反唯一約束（Unique Constraint） : 這世界只容一個你summary你是否曾在 SaveChanges() 時迎來晴天霹靂，一行紅字 DbUpdateException 打斷了你的程式？這就像在大海航行時，突然撞上一座看不見的暗礁──平時無聲無息，一出事卻攪得你天翻地覆。這篇文章，我們就來一起潛入這片資料海域，探查六種常見導致 DbUpdateException 的暗礁地形。每一種都有它的風險與成因，但只要理解清楚，就能順利避開，繼續駛向資料的彼岸。
主鍵（Primary Key）是資料的身份證號。若你試圖插入一筆資料，但主鍵與資料庫中已存在的資料相同，那就如同系統收到兩張一模一樣的身分證，無法分辨誰是誰，只能報錯。
12context.Users.Add(new User { Id = ...
EF Core - TimeoutException PART 2
Pre為什麼資料庫會「卡住」？—— 談 Lock方向一. 從交易層級（Transaction Isolation Level）開始說起方向二. 設計 Retry 機制方向三. 避免長時間交易連線池用盡 / 資料庫連不穩沒用 AsNoTracking()大量更新或刪除資料Summary本篇 ~ 繼續 ~ TimeoutException 可能發生的原因及改善方式，從 Lock、Isolation Level、Retry、連線池，到 Change Tracker 與批次處理
🔒 資料庫為什麼會 Lock？當兩個交易（Transaction）同時存取資料時，為了確保資料一致性，資料庫會自動幫我們上鎖。像是：
其他交易正在修改這筆資料（而還沒提交 Commit）
你要修改的資料已經被排他鎖定
這時候，後來的交易就只能等別人釋放鎖，不然就只能拋錯。等待超過 Command Timeout，就會拋出 TimeoutException 或 SqlException。
關鍵例外訊息可能會有哪些？1234567System.TimeoutExceptionMicrosoft.Data.Sql ...
EF Core - TimeoutException (Part 1)
監控查詢資料太多，撐爆記憶體命中索引卻還是慢？複合索引中，查詢條件順序會影響是否命中索引嗎？複雜 JOIN / 多表格查詢Summary某天早上，監控系統跳出好幾個 TimeoutException，我們小組群組裡只聽到一句：「啊，應該是網路問題吧，再跑一次就好了。」
這句話讓我背脊一涼。
TimeoutException 並不是資料庫在耍脾氣，它是壓力太大在吶喊。這篇文章，要來好好梳理這些 “吶喊” 背後的真正原因有時候你只是開個後台報表，卻默默查了幾十萬筆資料。久而久之，伺服器就跟泡麵一樣——泡過頭，膨脹爛掉
1️⃣ 真的需要全部資料嗎？
商業情境：報表開發初期為求簡便，可能會習慣「全撈」資料來呈現，但實際使用者只會看最近的記錄。
1234var threeMonthsAgo = DateTime.UtcNow.AddMonths(-3);var recentOrders = await dbContext.Orders .Where(o => o.CreatedDate >= threeMonthsAgo) .ToListAsync();
2️ ...
EF Core - Logging
whisper為什麼要紀錄 EF Core 自動產生的 SQL 命令?調整 `appsettings.json` 的 LogLevel在程式中啟用敏感資料紀錄（選配）設定 LogTo：印出日誌到 Console 或其他地方輸出到檔案中：永久保存你的 SQL 日誌閱讀：從官方與社群學更多summary在平穩無波的資料操作背後，EF Core 為我們自動生成了大量 SQL 語法。這些語法就像資料的悄悄話，大部分時間默默運作，沒出錯就好。但一旦效能下滑、查詢遲緩，這些悄悄話就需要被「聽見」。
因此，我們需要打開 EF Core 的日誌紀錄機制，看看背後究竟在跑什麼樣的 SQL
EF Core 是一套功能強大的 ORM 框架，幫助我們用物件導向的方式操作資料。但 ORM 所產生的 SQL 並非總是最有效率的選擇。
透過 Logging，我們可以：
檢查 EF Core 實際送出的 SQL 語法
發現不必要的 JOIN 或 WHERE 條件
優化查詢速度（例如加上索引、改用 View 或 Stored Procedure）
這對效能調教與除錯都非常有幫助
12345678910&# ...
