C# 这套学习心得写到第3篇了。前面聊过开发环境怎么搭、第一个控制台程序怎么写这篇想专门把 C# 的基本语法、标识符和关键字这三个最基础的东西理清楚。学 .NET 到现在我最大的感受是很多人栽跟头不是栽在 LINQ、异步这些高级特性上反而是连分号写不写、标识符能不能用关键字命名、哪些词编译器早就占了都含糊。这篇就按我自己的学习顺序来从语法骨架、命名规则再到保留字最后用一个能跑的小程序把知识点串起来中间穿插一些我在 IDE 里真实遇到的报错和处理习惯。1. 先把 C# 的语法骨架搭起来语句、花括号与注释1.1 分号每条语句的“结束符”在 C# 里分号是语句的结束标记。写int a 1;后面的分号不能省略。刚开始我还会拿 JavaScript 的换行自动补分号来类比结果写了一段少分号的代码编辑器直接报CS1002: 应输入 ;。这个错误在初学阶段特别常见几乎每节课都会看到一次。为什么 C# 要强制分号因为它不依赖换行来区分语句。一条语句可以分成多行写比如int total 1 2 3;在后面换行完全合法因为没有分号就表示这个表达式还没结束。反过来一条语句放在同一行也可以int x 1; int y 2;换行是给人类看的编译器只认分号。这里有一个很小的细节;单独写也算一条语句叫空语句。虽然平时很少用但在某些循环结构里能派上用场。另一个容易踩的点是类型定义后面不需要分号。比如class MyClass {}写完花括号就行了不需要在后面补分号但很多从 C/C 转过来的开发者习惯性加上。加不加都不报错我自己的建议是保持一种风格别今天写分号明天不写。分号问题其实反映了一个学习习惯看到编译报错不要急着“猜”先看错误前面的代码是不是少了分号、多了一个花括号、或者字符串引号没闭合。我在排查CS1002的时候十有八九是分号问题剩下两成是中文标点混进去了。是的中文分号和英文分号;在编译器眼里完全是两码事初学者写注释没问题一旦把代码里的分号换成中文编译立刻挂掉。1.2 花括号与作用域代码是怎么“分组”的在 C# 中花括号{}用来把一组语句聚合成一个语句块也是定义类、方法、循环、条件分支结构的基本单位。比如if (score 60) { Console.WriteLine(通过); }这里if后面只能带一条语句。如果不写花括号就只有紧跟if的那行会受条件影响if (score 60) Console.WriteLine(通过); Console.WriteLine(这条代码不受 if 控制);很多新手在这里被缩进误导以为第二行也在if里实际上没有花括号就只包含第一行。所以我在学习时给自己的硬性要求是只要用if、for、while不管后面是几行一律写花括号。这不是语法要求是为了避免后面加代码时搞错逻辑。花括号还决定了变量的可见范围也就是作用域。在某个花括号里声明的变量出了这个块就访问不到。比如if (count 0) { string message 剩余 count 件; } Console.WriteLine(message); // 这里会报错message 不在作用域内反过来外层声明的变量在内部可以访问。作用域规则在后续学习“字段”“局部变量”“生命周期”时会反复碰到一开始就要养成就近声明、随手看花括号的习惯。我一般写完一个方法会顺手触发一次代码格式化让编辑器帮忙把花括号对齐这样哪个块在哪个范围一眼就能看清比自己手动敲缩进可靠得多。1.3 注释给你的代码加“旁白”注释不会被执行是写给维护者看的。C# 支持三种常见写法单行注释// 说明文字多行注释/* 说明文字 */XML 文档注释/// 说明文字单行注释用途最广。多行注释适合临时注释掉一块代码但要记住多行注释不能嵌套。也就是/* /* */ */这种写法会在遇到第一个*/时就结束后面内容可能被迫变成有效代码造成奇怪的报错。这个坑我踩过一次当时想临时注释一个内部还带着注释的方法结果直接注释到文件末尾一大段代码全部变成灰色看起来倒是“注释”了其实是把后面正常代码也吞进去了。XML 注释是 C# 的一大特点。在类、方法、属性上面写///IDE 可以自动生成文档框架里面的summary、param、returns标签在调用处悬停时能看到提示。比如/// summary /// 计算若干数字的平均值 /// /summary /// param namenumbers数字集合/param /// returns平均结果/returns public static double ComputeAverage(IEnumerabledouble numbers) { // 实现省略 }我的体会是注释写“为什么”而不是“做了什么”。一行代码在干什么看代码本身就知道但为什么这里要判断为空、为什么用这种方式而不是那种方式光看代码猜不出来这才是注释的价值。刚开始为了展示认真我给每一行都写了注释后来发现整片代码既吵又难维护——变量改名了注释不一定跟着改最后注释反而变成噪音。2. 标识符给变量、方法、类型起名的规则2.1 硬性规则什么样名字才合法标识符就是程序里各种名字比如变量名、类名、方法名、命名空间名。C# 的合法标识符规则其实不复杂只能以字母、下划线_或开头后面可以跟字母、数字、下划线。不能和 C# 保留关键字完全相同除非加了前缀。标识符区分大小写name和Name是两个不同的东西。允许包含 Unicode 字符比如中文也在允许范围。有点意外的是第四条。C# 是支持中文变量名的int 总数 100; string 客户名称 某用户;这在语法层面完全没问题编译能过。但我基本不用原因很简单团队协作时代码里英文标识符是大家默认的共同语言中文标识符在键盘输入、字体显示、跨平台协作上都有可能带来额外麻烦。不是说它非法而是没有必要。同样的道理适用于前缀虽然它能救急但不是常规用法。下划线开头的标识符也有讲究。很多 .NET 项目喜欢用_name表示私有字段private int _count;这是社区约定不是语言要求。我看到有些项目用m_count、mCount也有用count_的都能跑但团队内必须统一。我建议新手一开始就按当前主流 .NET 风格来也就是私有字段用_camelCase局部变量用camelCase公开成员用PascalCase后面换项目会省事很多。2.2 命名约定合法之外更要“像样”合法只是底线可读性才是命名真正考验人的地方。面向 .NET 的命名规范可以浓缩成这么几句话类型名、公开方法、公开属性、事件、常量用PascalCaseGetUserById、OrderStatus、MaxRetryCount局部变量、方法参数用camelCaseuserList、itemCount私有字段通常用_camelCase接口名以I开头IUserService类型参数名以T开头常用T、TEntity举一段对比代码// 命名混乱读完还不知道要干嘛 double a 0; for (int i 0; i 5; i) { string s Console.ReadLine(); a double.Parse(s); } double b a / 5; // 一眼看懂的结构 double total 0; const int InputCount 5; for (int i 0; i InputCount; i) { string rawInput Console.ReadLine(); total double.Parse(rawInput); } double average total / InputCount;第一段和第二段的逻辑一模一样但可读性天差地别。变量命名这件事付出成本极低收益却极其长期。一个total变量的背后有上下文比a强太多。实际项目里我会先想清楚“这个值在业务里是什么”再起名字。比如从表单拿到的用户输入我倾向写成rawInput而不是x表示平均成绩就写averageScore而不是avg除非团队已经约定avg代表平均值。2.3 起名时容易踩的坑第一个坑是只有大小写不同的命名。既然Name和name是两个标识符就可能出现两个东西长得很像、意思也接近复制粘贴时稍不留神就混了。我见过某项目里同时存在customerId和CustomerId一个是字段一个是属性调试时特别难受。命名规范统一之后这种问题基本能杜绝。第二个坑是使用关键字或看起来像关键字的词做名字。比如string string 123;、int new 0;都会直接编译报错。新手可能想给string加个引号不就能当字符串用了吗但它属于保留关键字不管怎么赋值都不行只能换名。上下文关键字相对宽松比如var在某些位置还能当变量名用但没有任何理由主动招惹编译器。第三个坑是标识符过长或过短。过短的问题上面说了过长的名字会让代码变得臃肿。比如明明在OrderContext类里还写orderContextOrderId这种名字就完全没有必要写成OrderId结合上下文就够了。我给自己定过一个粗略标准一个标识符超过 40 个字符就去想能不能借助类名、方法名把含义收窄一点。3. 关键字编译器提前“霸占”的专用词3.1 保留关键字与上下文关键字关键字是 C# 预留给语言结构的词分两类。一类是保留关键字比如class、if、int、void在任何位置都不能直接用作标识符写了就报“此处应为标识符”的错误。另一类叫上下文关键字比如var、async、await、where、yield只在特定语法结构中才有特殊含义在这个位置之外可以用来命名。举几个真实场景帮助记忆。nameof是 C# 6 引入的上下文关键字它可以把某个标识符的名称以字符串形式取出来string methodName nameof(ComputeAverage); // methodName 的值是 ComputeAverage在方法名重构后这个字符串会自动跟着变比写死字面量安全得多。而var这个上下文关键字很多人误以为它是“万能类型”实际上它只是告诉编译器“类型由右侧表达式推断”。所以var x 1;推断成intvar s a;推断成string本质类型并没有被削弱。3.2 常见关键字家族速览学习关键字不必死背列表按功能分组更容易记住。我整理一下实际开发中最常用的几组分组常用关键字学习侧重类型bool, int, long, float, double, decimal, string, object, void知道每种类型的取值范围和默认值修饰符public, private, protected, internal, static, readonly, const, sealed, abstract, virtual, override访问级别与继承关系流程控制if, else, switch, case, for, foreach, while, do, break, continue, return循环边界、跳出时机异常处理try, catch, finally, throw资源释放与错误传播其他class, interface, struct, enum, namespace, using, new, this, base, is, as, typeof类型系统的底座这里特别提醒两个常被混淆的const和readonly。const是编译期常量声明时必须赋值类型只能是指定的基元类型readonly是运行时只读字段可以在构造函数里赋值。写配置类时很多人习惯用const但换到数据库连接字符串这种依赖运行环境的场景const就不合适应该用readonly或静态只读属性。is和as也是一组容易混的关键字。is用来判断类型是否匹配返回布尔值as用于引用类型转换转换失败返回null不会抛异常。比如object data hello; if (data is string text) { Console.WriteLine(text.Length); } string? result data as string;第一段是 C# 7 的模式匹配写法在判断的同时把data转换为text变量第二段用as得到可能为null的结果。这两种写法的区别要亲手敲一遍才有手感背是背不下来的。3.3 关键字冲突与 前缀转义大多数时候关键字不能直接做标识符但如果真的需要可以用前缀转义。class、if、string都能作为合法的标识符使用。这个能力最早是为了和其他语言互操作设计的比如某个语言把class当普通词用传来的字段名就叫classC# 又恰好要接收这时候class就有用了。我在实际项目里几乎没见过正常的业务代码用class、event这种命名除非是映射外部系统接口的字段。给新手的建议是了解这个机制但不要在业务代码里主动用。过度依赖转义代码里到处是if、do阅读成本会急剧上升而且完全可以通过改名绕过去。还有一点记录下来是给自己提个醒C# 的关键字并不是一成不变的。每出一个新版本可能会新增上下文关键字比如 C# 9 引入了record这种引用类型声明关键字后续版本还引入了required、file等写法。学习时先掌握主流的保留关键字再关注新版本引入的上下文关键字不用焦虑自己记不全。编译器就是最好的“关键字判断器”写错名字报错看两次自然就记住了。4. 一个把语法、标识符、关键字串起来的小程序4.1 程序效果与整体结构理论讲完我写了一个只有十几行的控制台程序。它让用户输入 5 个数字计算平均值并输出。这个例子麻雀虽小但基本语法、标识符、关键字全都能在里面找到对应关系特别适合拿来复盘。using System; namespace DemoApp { internal class Program { private static void Main(string[] args) { const int InputCount 5; double total 0; for (int i 1; i InputCount; i) { Console.Write($请输入第 {i} 个数字); string rawInput Console.ReadLine(); total double.Parse(rawInput); } double average total / InputCount; Console.WriteLine($平均值是{average}); } } }这个程序不需要额外引入第三方库新建一个控制台应用项目把Main方法内容替换进去就能运行。第一次跑可能没什么感觉跑完之后把变量名改成a、b、c再看就会明白有意义的标识符带来的阅读体验差异。4.2 逐段拆解每个词都在干什么第一行using System;里的using和后面的namespace需要分开看。using System;的作用是引入命名空间这样Console这个类型可以直接使用不需要写全名System.Console。namespace DemoApp则是给当前代码声明一个命名空间相当于给这段代码一个归属的“文件夹”。这两个词都在代码的开头但功能完全不同。第二块internal class Program声明了一个类。internal是访问修饰符表示这个类只能在当前程序集内部被访问class是类型关键字表示声明的是一个类Program是标识符也是类型名。类里面的private static void Main(string[] args)是程序入口。private表示方法私有static表示不依赖具体实例void表示无返回值Main是入口方法名args是命令行参数数组。再看方法体。const int InputCount 5;里const表示编译期常量int是 32 位整数类型InputCount是常量标识符按命名规范用 PascalCase。double total 0;声明了一个浮点变量total用 camelCase。for (int i 1; i InputCount; i)是标准计数循环i是循环变量这里短命名完全合理因为它只在循环内部非常局部地使用。Console.ReadLine()读取键盘输入返回一个字符串。double.Parse把字符串解析成双精度浮点数。total ...是累加。最后average除以InputCount得到平均值输出时用字符串插值$...把变量嵌入到文本里。这个程序故意没有做输入校验如果用double.Parse输入一个非数字文本程序会抛FormatException——这点后面问题排查再展开。4.3 如果让我把这个程序写得更“工程化”跑通上面的代码只是第一步。如果这个程序要放进真实项目我至少会做三处调整。第一把计算平均值的逻辑单独抽出来放一个方法而不是全部堆在Main里。入口方法负责输入输出计算逻辑负责纯计算这样后续加单测也方便。第二解析数字不能用double.Parse这样脆弱的写法至少换成double.TryParse它不会抛异常而是返回布尔值。第三如果输入数量常变就不要写死InputCount可以设计成参数传入。改造后大概是这种感觉using System; namespace DemoApp { internal class Program { private static void Main(string[] args) { Console.WriteLine(请输入 5 个数字); double[] numbers new double[5]; for (int i 0; i numbers.Length; i) { Console.Write($第 {i 1} 个数字); string? rawInput Console.ReadLine(); if (double.TryParse(rawInput, out double value)) { numbers[i] value; } else { Console.WriteLine(输入无效请重新输入。); i--; } } double average ComputeAverage(numbers); Console.WriteLine($平均值是{average}); } private static double ComputeAverage(double[] numbers) { double total 0; foreach (double number in numbers) { total number; } return total / numbers.Length; } } }这里面的改动并不复杂但每一处都对应前面聊过的概念方法声明用了修饰符、标识符和参数列表if分支结构里用了花括号foreach遍历数组TryParse里的out关键字把解析结果传出来。代码结构清楚之后语法知识才真正变成能力。5. 常见报错、排查习惯与避坑记录5.1 高频错误分号丢失、括号不匹配、中文标点初学 C# 的编译错误其实就那几类。我按出现频率把它们排了个序。报错提示原因处理方式CS1002: 应输入 ;语句结尾缺分号或者不小心写了中文分号在报错行附近找缺分号的位置检查字符是否为英文半角CS1513: 应输入 }花括号数量不对用 IDE 的自动格式化重新对齐或跳转到匹配括号CS1026: 应输入 )方法调用或表达式的小括号不完整检查参数列表是否全部闭合CS0103: 当前上下文中不存在名称标识符拼写错误、大小写不匹配、变量不在作用域内核对变量名查看作用域花括号关键字被用作标识符用了class、if等保留字当名字改用其他名称或加前缀不推荐长期使用举个例子很多人学判断条件时会把if (count 0)里的括号漏掉或者写成if count 0IDE 会在count下面画波浪线。这种错误不算复杂但要意识到代码编辑器给出的智能提示有时会把错误标在“看起来没问题”的位置真正缺的就是前一行开头的括号或后一行的分号所以排查时目光要在报错行上下各看两行。中文标点是最容易让人尴尬的问题。输入法在中文状态下敲出的分号、括号、冒号和英文符号长得几乎一样编译器却无法识别。我的习惯是代码文件里只保留英文输入状态需要写中文注释时再用快捷键切换打完立即切回。很多人写注释时顺手打出中文标点把后面的代码也污染了盯着看了半天才发现是标点问题。5.2 大小写与作用域引发的“隐蔽 Bug”C# 是大小写敏感语言。userName、Username、USERNAME是三个不同的标识符。编译期拼错了还好编译器会报错可怕的是自己代码里定义了一个变量在另一个文件里写错了大小写编译器却把另一个合法标识符解析出来导致结果和预期不一致。有一次我在项目里遇到一个“平均值算出来是 0”的问题排查到最后发现变量写成了大写字母开头的Total和小写total是不同变量赋值结果全写到了另一个身上。这类问题最有效的解法有两个一是严格遵循命名约定私有字段、局部变量统一 camelCase这样大小写变化本身就值得警惕二是借助 IDE 重构功能批量重命名不要手动一个文件一个文件地改。作用域引发的“变量不存在”错误也常见。看下面这段for (int i 0; i 10; i) { int result i * 2; } Console.WriteLine(result); // 编译错误result 不存在result在循环块里声明出了循环就不可见。想拿到循环累计结果得把变量声明在循环外面。这个规则的直观理解是花括号边界就是变量的可见边界。5.3 关键字与命名冲突的现场记录我再分享一个真实的现场。某个项目里有人把一个方法参数叫event写代码时 IDE 立刻标红因为event是保留关键字。当时的解决办法是把参数名改成eventInput。其实参数名只是一个内部代号改掉对功能毫无影响但如果不改后面每次引用都要写event代码很快就会被污染。还有一种少见的冲突是var名前缀的坑。某基架代码里曾经出现一个字段叫_var这完全合法但因为和var长得太像阅读时总被误认为是类型推断语法视觉上也非常容易产生歧义。这种问题不算错误却是代码评审里会被打回修改的对象。我的原则始终是命名要让 6 个月后的自己和同事一眼看明白而不是让编译器勉强通过。5.4 我的排查顺序和工具习惯遇到编译错误我不建议一上来就搜索整个报错文本。我的顺序是先看 IDE 错误列表里定位的文件和行号再用自动格式化处理括号对齐问题然后重点排查分号、括号、大小写这三类基础问题。如果还不行就把报错信息里的错误码单独拿出来搜索比如“CS1002”会比复制整段中文描述更精准。写代码时我也会刻意给自己制造“检查点”写完一段逻辑就对变量命名、作用域、花括号配对做一次自检。这个习惯在桌面端、服务端项目里都适用。越早培养越不会在后期被各种莫名其妙的编译错误消耗耐心。6. 一点学习上的体会现在回头看C# 的语法骨架其实相当“端庄”——该写的分号必须写该记住的关键字绕不开标识符规则既有边界又留了转义出口。这套规则学起来不难难的是在真实代码里保持耐心。刚开始我总想一口气学完泛型、异步后来发现连foreach里的循环变量什么时候销毁都没完全清楚代码越写越毛躁。我个人最受用的方法是“讲给别人听”。把基本语法、标识符规则、关键字分类整理成笔记再用一个简单小程序把知识点串起来复盘这比自己默默读文档记得牢得多。下一篇我打算接着写数据类型、变量类型转换和运算符把这些文法层面的东西继续磨扎实。如果你也在学 C#建议现在打开 IDE把本文里的示例亲手敲一遍然后尝试改改变量名、删一个分号、把一个参数改成关键字看看编辑器分别怎么提示你。报错不可怕它反而是最好的语法老师。
