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);
// 使用 stream

3. 在性能敏感路径中滥用 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# 写到最后，拼的从来不是“会不会用”，而是“知不知道什么时候不该用”。