编译错误 · error CS1513

} expected(缺少右花括号)

一个用 { 打开的块,到最后也没等到它的 }。报错里的行号是编译器弹尽粮绝的地方——通常是文件最后一行——不是缺失 } 真正属于的地方。

亲眼看它发生

int x = 5;
if (x > 2)
{
    Console.WriteLine("big");
    if (x > 4)
    {
        Console.WriteLine("huge");
}

两个块打开,只有一个关闭。编译器读到文件末尾,发现外层 if 的块还开着,于是在最后一行报 } expected——离案发现场十万八千里。

int x = 5;
if (x > 2)
{
    Console.WriteLine("big");
    if (x > 4)
    {
        Console.WriteLine("huge");
    }
}

花括号配平排查法(30 秒)

  1. 把光标放到出问题的函数或块的开头。
  2. 往下数:每个 { 记 +1,每个 } 记 −1。
  3. 结尾应该归零。哪里"该归零却没归零"——缺失的花括号就在那里(或它前面)。

Visual Studio / VS Code 里点任意花括号会高亮它的配对。如果某个 { 高亮不出东西——孤儿找到了。

三种常见成因

1. 删了一行,连花括号一起删了

你删掉了一个 if 或方法调用,却留下了它的花括号——现在某个别的块提前闭合,后面全错位。症状:你知道存在的变量冒出一堆奇怪的 CS0103,外加文件末尾一条 CS1513。

2. 粘贴代码,丢了尾巴

从教程复制的内容抓到了一切,唯独少了最后那个 }——或者多抓了一个,那就变成镜像错误 CS1022("类型或命名空间定义中有额外的 }")。

3. 从上往下写,忘了收口

最诚实的一种——长嵌套逻辑从头写到尾。能根治的写法:敲下头部的瞬间就把两个花括号都打出来,再往中间填:

if (x > 2)
{
    // 两朵括号都存在之后,再填中间
}

为什么编辑器会自动补花括号

你敲 { 时编辑器默默补上 }——那件略烦人的小事,存在的意义就是预防 CS1513。让它开着,再用自动格式化(VS 里 Ctrl+K, D)重排缩进——错位的缩进是缺失花括号的藏身处。每个块都对齐之后,孤儿花括号一眼可见。

常见问答

C# 里的 CS1513 是什么意思?

一个用 { 打开的块没有被关闭。行号是编译器无路可走的位置(常常是文件末尾),不是花括号该在的地方。从出问题区域的开头数 +1/−1,缺口自己现形。

怎么快速找到缺失的花括号?

点花括号看配对高亮;先跑自动格式化让缩进诚实——缩进不说谎之后,缺失的括号一眼可见。

排查清单