checked和unchecked关键字用于控制C#中整数运算溢出行为：checked在溢出时抛出OverflowException，确保数据安全；unchecked则允许静默截断，适用于性能敏感或需环绕行为的场景。两者可作用于表达式或代码块，且能覆盖项目级别的/checked编译设置，实现精细控制。常量表达式默认启用溢出检查，而非常量表达式的默认行为受编译选项影响。关键业务逻辑推荐使用checked保障正确性，位运算、哈希计算等场景可使用unchecked追求性能或特定效果。
C#中的
checked和
unchecked关键字，其实就是提供了一种非常精细的机制，让我们能手动控制整数运算（包括加、减、乘、除、位移等）在发生溢出时的行为。简单来说，它们决定了当一个运算结果超出了其数据类型所能表示的最大或最小值时，系统是应该抛出一个异常来警告你，还是默默地截断结果。这玩意儿啊，就像是给数字运算加了一层“保险”或“免责条款”。
解决方案
checked和
unchecked关键字可以应用于表达式或语句块。
当一个运算被放置在
checked上下文中时，如果运算结果超出了目标数据类型（如
int,
long,
short,
byte等）的范围，系统会立即抛出一个
System.OverflowException。这就像是给你的计算设了一个严格的边界，一旦越界，程序就会立刻“报警”。
// checked 表达式示例
int maxInt = int.MaxValue;
try
{
int result = checked(maxInt + 1); // 这里会抛出 OverflowException
Console.WriteLine($"Checked result: {result}");
}
catch (OverflowException ex)
{
Console.WriteLine($"Checked expression error: {ex.Message}");
}
// checked 语句块示例
int a = 2000000000; // 20亿
int b = 2000000000; // 20亿
try
{
checked
{
int sum = a + b; // 理论上会溢出int的最大值 (约21.47亿)
Console.WriteLine($"Checked sum: {sum}");
}
}
catch (OverflowException ex)
{
Console.WriteLine($"Checked block error: {ex.Message}");
}相反，当运算处于
unchecked上下文中时，即使结果溢出，系统也不会抛出异常。它会简单地截断高位，只保留适合目标数据类型的部分。这通常意味着结果会“环绕”到数据类型的另一端（例如，
int.MaxValue + 1会变成
int.MinValue）。这种行为在某些特定场景下是有意为之的，比如哈希算法或位操作。
// unchecked 表达式示例
int maxInt = int.MaxValue;
int resultUnchecked = unchecked(maxInt + 1); // 不会抛异常，结果会是 int.MinValue
Console.WriteLine($"Unchecked expression result: {resultUnchecked}");
// unchecked 语句块示例
int c = 2000000000;
int d = 2000000000;
unchecked
{
int sumUnchecked = c + d; // 不会抛异常，结果会是 -294967296
Console.WriteLine($"Unchecked block sum: {sumUnchecked}");
}需要注意的是，对于常量表达式（在编译时就能确定值的表达式），即使没有显式使用
checked关键字，C#编译器默认也会进行溢出检查。如果常量表达式溢出，编译时就会报错。而对于非常量表达式（运行时才能确定值的表达式），默认行为则取决于项目的编译设置。
为什么C#需要对溢出进行检查，它解决了什么实际问题？
我个人觉得，C#提供这种溢出检查机制，核心是为了保障数据完整性和程序行为的可预测性。你想啊，在很多业务场景下，比如财务计算、库存管理、安全相关的计数器，哪怕是微小的数字溢出，都可能导致灾难性的后果。想象一下，如果你的银行账户余额因为一个整数溢出，突然从正数变成了负数，那简直是无法接受的。
如果没有
checked，或者说，如果没有一种强制溢出检查的手段，那么当运算结果超出数据类型范围时，程序会静默地截断，产生一个“错误”但看起来“合法”的结果。这种“静默失败”是最可怕的，因为它不会报错，不会中断程序，而是悄悄地给出一个错误的数据，然后基于这个错误数据继续进行后续计算，最终导致整个系统的数据链条都变得不可信。这种问题往往很难通过常规测试发现，因为溢出可能只在特定输入组合下发生。
所以，
checked关键字解决的实际问题就是：它提供了一个“安全网”，在关键计算中，一旦发生溢出，立即抛出异常，强制开发者去面对并解决这个问题，而不是让错误悄无声息地蔓延。这对于提升软件的健壮性和可靠性至关重要。
在哪些场景下应该优先使用checked或unchecked？
理解了背后的哲学，我们再来聊聊实际操作中，到底什么时候该用“严谨”的
checked，什么时候又可以“放飞自我”地
unchecked。
优先使用checked
的场景：
- 财务或高精度计算： 任何涉及金钱、数量、库存等对精度要求极高的场景，都应该强制进行溢出检查。你绝不希望因为一个数字溢出，导致账目不平或者库存混乱。
-
循环计数器或数组索引： 如果你的循环次数或者数组索引可能非常大，并且溢出意味着逻辑错误（比如索引越界），那么使用
checked
可以提前发现问题。 - 安全敏感的上下文： 在一些加密算法、身份验证、权限管理等场景中，即使是微小的数字错误也可能引发安全漏洞。
-
API参数验证： 当你编写公共API时，如果输入参数经过计算可能导致溢出，使用
checked
可以确保输入的有效性，避免外部调用者传入导致内部错误的数据。 -
默认或通用业务逻辑： 如果没有明确的理由需要
unchecked
行为，那么为了稳妥起见，让编译器默认或显式地进行溢出检查是个好习惯。这能减少潜在的bug。
优先使用unchecked
的场景：
- 位操作和哈希函数： 在这些低级别的操作中，溢出往往是设计的一部分，甚至是期望的行为。例如，计算哈希值时，通常会利用整数的环绕特性。
-
性能敏感的代码： 溢出检查会带来轻微的性能开销。在那些对极致性能有要求，并且你确信溢出不会导致逻辑错误，或者你已经通过其他方式处理了溢出的情况下，可以使用
unchecked
。 - 数据截断是预期行为： 有些时候，你就是希望数字在溢出时能自动截断，例如将一个大整数转换为较小整数类型，并期望它“环绕”或只保留低位。
-
图形或信号处理： 在某些图形渲染、音频处理等领域，数据可能会有意地进行饱和或环绕操作，此时
unchecked
就非常适用。
选择哪一个，更多的是一种权衡：是选择安全性、可预测性优先，还是选择性能或特定算法需求优先。我个人倾向于在不确定或关键业务逻辑中，默认偏向
checked，除非有非常明确的理由和测试来支持
unchecked。
checked/unchecked关键字与编译选项/项目属性有何关联？
这部分就有点深入到C#编译器的“脾气”了。
checked和
unchecked关键字不仅仅是代码层面的控制，它们还与项目的编译设置有着紧密的联系，而且这种关系还挺有意思的。
首先，C#编译器提供了一个
/checked选项。当你编译项目时，可以使用
/checked+或
/checked-来控制整个项目默认的溢出检查行为：
-
/checked+
： 这表示编译器会对所有整数运算（除了常量表达式）默认启用溢出检查。如果发生溢出，运行时会抛出OverflowException
。这就像给整个项目设置了一个“全局严格模式”。 -
/checked-
： 这是C#编译器的默认行为（通常情况下）。它表示编译器不对运行时整数运算进行溢出检查。如果发生溢出，结果会静默截断。这可以看作是“全局宽松模式”。
在Visual Studio中，你可以在项目属性的“生成”选项卡下找到“高级”按钮，里面有一个“检查算术溢出/下溢”的复选框，这其实就是控制
/checked编译选项的。
那么，
checked和
unchecked关键字与这个全局设置有什么关系呢？简单来说，关键字会覆盖编译器的默认设置。
- 无论你的项目是
/checked+
还是/checked-
编译的，如果你在代码中显式使用了checked
关键字，那么该checked
块或表达式内的运算，一定会进行溢出检查，并抛出异常。它强制了检查行为。 - 同理，无论你的项目是
/checked+
还是/checked-
编译的，如果你在代码中显式使用了unchecked
关键字，那么该unchecked
块或表达式内的运算，一定不会进行溢出检查，而是静默截断。它强制了不检查行为。
所以，这提供了一个非常灵活的控制粒度。你可以让整个项目在某种默认模式下运行（通过编译选项），但对于那些特别关键或特别需要特定行为的代码片段，你可以用
checked或
unchecked关键字来“微调”它们的溢出检查行为，从而实现更精细的控制。这种层级化的控制方式，在我看来，是C#语言设计中非常实用且深思熟虑的一个点。它既给了你全局的便捷，也给了你局部的精确。
