即使.NET大牛也常犯的10个C#错误
C# 是一门成熟而强大的语言，语法友好、工具链完善，按理说“很难写出垃圾的代码”。但现实恰恰相反：越是熟练的开发者，越容易在惯性和时间压力下踩坑。
这些错误往往不会立刻导致程序崩溃，而是以更隐蔽的方式出现：性能缓慢下降、代码越来越难维护、线上问题难以定位，最终在某个关键时刻集中爆发。下面这 10 个错误，很多人都“写过、用过、踩过”。
1. 滥用 async/await，却忽视它的真实成本
在没有任何异步操作的方法中使用async/await，是一个非常常见的误区：
public async Task<int> GetCountAsync() { return 10; // 没有任何 await }这种写法会让编译器生成状态机，带来额外的内存分配和调用开销，更重要的是，它会误导后续维护者，让人以为这里存在 I/O 或异步行为。
正确做法是：只有在方法内部真的存在异步操作时，才使用 async/await。对于纯同步逻辑，直接返回一个已完成的任务即可：
public Task<int> GetCountAsync() { return Task.FromResult(10); }2. 忽视 IDisposable，错误相信“GC 会帮我处理”
文件流、数据库连接、Socket 等资源，如果不及时释放，问题往往不会立刻显现，但迟早会出事：文件被锁死、连接池耗尽、内存压力异常。
var stream = new FileStream(path, FileMode.Open); // 使用完未释放“垃圾回收器会处理”的想法非常危险。GC 只负责托管内存，并不保证非托管资源能被及时释放。
正确做法很简单，也很重要：
using var stream = new FileStream(path, FileMode.Open); // 使用 stream3. 在性能敏感路径中滥用 LINQ
LINQ 让代码非常优雅，但在高频调用或大数据量场景下，它并不总是免费的：
var emails = users .Where(u => u.IsActive) .Select(u => u.Email) .ToList();链式 LINQ 会创建多个枚举器和闭包对象，在热点路径中，这些“看不见的分配”会持续侵蚀性能。
在性能敏感位置，使用显式循环反而更清晰、也更可控：
var emails = new List<string>(); foreach (var user in users) { if (user.IsActive) emails.Add(user.Email); }LINQ 不是不能用，而是要用在合适的地方。
4. 过早抽象，陷入过度工程
很多项目一开始就把简单问题设计得极其复杂：
IUserService → IUserRepository → IUserDataProvider → IUserStorage结果是每次调试都要跨好几层，修改一个逻辑要改三四个接口，开发效率直线下降。
判断是否需要抽象，可以问自己三个问题： 这个组件未来真的可能被替换吗？ 当前是否已经存在多个实现？ 抽象是否解决了真实问题？
如果答案是否定的，保持简单往往才是最优解。
5. 忽略 DateTime 的时区与夏令时陷阱
随手一个DateTime.Now，在分布式系统中可能埋下巨雷：
var expiresAt = DateTime.Now.AddDays(1);不同服务器的本地时间、时区配置、夏令时切换，都可能导致逻辑不一致。
更安全的选择是统一使用 UTC，或者直接使用DateTimeOffset：
var expiresAt = DateTimeOffset.UtcNow.AddDays(1);时间相关的 Bug，往往最难复现，也最难排查。
6. 过度宽泛地捕获 Exception
下面这种代码，看起来“很稳”，实际上风险极高：
try { DoSomething(); } catch (Exception) { // 什么都不做 }它会吞掉所有异常，包括你根本处理不了的异常类型，系统可能在错误状态下继续运行，造成更严重的后果。
正确做法是：只捕获你能处理的异常，并在必要时重新抛出：
try { DoSomething(); } catch (IOException ex) { _logger.LogError(ex, "文件处理失败"); throw; }一句话原则：如果你不知道怎么处理这个异常，那就不要捕获它。
7. 混淆值类型与引用类型的语义
很多人对struct和class的差异理解不够深入：
public struct Counter { public int Value; } var c1 = new Counter(); var c2 = c1; c2.Value = 10; // c1.Value 仍然是 0结构体是值类型，赋值时会完整复制。这种行为在复杂场景中非常容易引发隐蔽 Bug。
一般建议是：默认使用 class，只有在明确需要性能优化、并且数据结构足够简单时，才考虑 struct。
8. 日志没有上下文，等于没打日志
下面这样的日志，在真实排查问题时几乎毫无价值：
_logger.LogError("出错了");你不知道是谁出的错，也不知道出在哪一步。真正有用的日志，必须包含上下文信息：
_logger.LogError(ex, "订单处理失败，OrderId={OrderId}", orderId);请记住一句话：日志不是给现在的你看的，而是给未来凌晨三点值班的你看的。
9. 在 ASP.NET Core 中错误使用 Task.Run
不少人会在控制器里写出这样的代码：
await Task.Run(() => SaveToDatabase());这通常是一个设计错误。Web 应用的主要瓶颈是 I/O，而不是 CPU。数据库、HTTP、文件操作，本身就有异步 API，用Task.Run只会白白浪费线程。
如果你确实有 CPU 密集型任务，应该考虑后台服务或独立计算服务，而不是塞进请求管道。
10. 忽视 CancellationToken，让任务“无法被取消”
很多异步方法签名中都有CancellationToken，但实际却被完全忽略：
public async Task ProcessAsync() { await Task.Delay(5000); }当请求已被客户端取消，服务器仍然继续执行这些任务，纯属资源浪费。
更合理的做法是：
public async Task ProcessAsync(CancellationToken token) { await Task.Delay(5000, token); }能取消的任务，才是对系统友好的任务。
结语
这些错误之所以常见，并不是因为它们“太低级”，而是因为它们大多能正常运行，问题却在系统演进中被不断放大。
写 C# 写到最后，拼的从来不是“会不会用”，而是“知不知道什么时候不该用”。大家遇到过什么错误，欢迎留言讨论!