Simple Is Not Easy

字串插補是 C# 中常用的特性，但由於其多變的用法，導致在一般專案開發中沒能充分活用。這篇文章將統整各種使用情境並加以說明。

因為字串插補編譯後的結果多樣，根據不同版本的 C# 可能有不同結果，這篇提到的編譯後結果只適用於該情境。

Nullable<T> 是一個很方便的結構，但看似簡單的特性背後卻隱藏一些小陷阱，這些陷阱平時難以發現，但一旦遇到卻很容易讓人感到困惑，這篇文章將解析我遇過的相關情境。

C# 提供許多編譯期的語法糖，但有些特性並不能完全歸類為語法糖，例如 Init Only Setters。本篇將快速介紹這個特性，並深入探討其運作原理。

C# 各版本新特性摘要，包含自己的想法與實務上的偏好。

C# 各版本新特性摘要，包含自己的想法與實務上的偏好。

C# 各版本新特性摘要，包含自己的想法與實務上的偏好。

C# 各版本新特性摘要，包含自己的想法與實務上的偏好。

在之前的專案中，我們遇到了一個情境，在需要處理多個非同步操作，例如多個網絡請求或文件處理時，需要設定一個總和的超時時間，當超過這個時間時，只回傳成功執行的非同步操作結果，並放棄還沒做完的部分。這篇文章會說明如何應對這種特殊需求。

在處理非同步操作時，當多個非同步任務同時操作共享資源時，可能會導致資料不一致。這篇文章將聚焦於如何在非同步情境下使用 ConcurrentDictionary 取代 Dictionary 來解決這些問題。

在實際專案中，資料查詢緩慢是一個常見的問題，如何找出具體原因成了一個很重要的主題。但在工作中，很多人往往過於注重單一面向而沒有精確的找出真正的瓶頸。例如，因為 ORM 使用不當而導致效能低落，卻將問題歸咎於 ORM 本身進而禁用 ORM。直接撰寫 SQL 查詢雖然可能較快，但失去了 ORM 的優勢。如果能先意識到 ORM 使用不當的問題並加以改善，或許能同時達到效能需求並保有 ORM 的優勢。

找到問題後的解決方案又是另一個複雜的過程，本文將簡單記錄幾個排查資料查詢緩慢的常見方向及應對方式。