这是个非常有意思的问题，咱们一步步拆解来看：

关于递归结构体的编译器特殊处理 #

你观察得很准：Int32结构体里的private readonly int m_value看起来是典型的递归定义——毕竟int就是System.Int32的别名，按照C#常规规则，这完全是不合法的。但CLR和C#编译器对**原生值类型（primitive value types）**做了底层豁免：

• 这些类型被标记为特殊的原生类型，编译器在解析时会直接跳过常规的结构体字段类型验证，把这个字段直接映射到底层的内存表示（比如Int32对应的就是32位整数的直接存储），根本不会把它当成普通的结构体字段去处理依赖关系。
• 简单说，这个m_value更像是一个“标记”，告诉编译器和CLR这个类型的内存布局，而非真正的结构体成员。

为什么内置类型不是存根，而是有具体实现？ #

你看到的那些接口实现代码，可不是摆设，它们在运行时承担了关键作用，主要原因有这几点：

1. 保持类型系统的一致性 #

C#的设计目标之一是让所有类型（包括原生值类型）都遵循统一的规则。把IComparable、IConvertible等接口的实现显式写在结构体里，能让开发者像调用普通自定义结构体的方法一样，调用int的CompareTo()、ToString()等方法，不需要为原生类型单独搞一套特殊的调用逻辑。

2. 支持装箱后的接口调用 #

虽然Int32是值类型，但当它被装箱成object时，会变成一个符合.NET对象模型的实例。这个实例需要正确实现所有声明的接口，而这些显式写出来的方法就是装箱对象方法表的一部分。如果只是存根，装箱后的对象就无法正确响应接口调用了——比如你把int装箱后传给一个接受IComparable参数的方法，就会因为找不到实现而报错。

3. 处理复杂的业务逻辑 #

像IFormattable、ISpanFormattable这些接口的实现，负责处理数值到字符串的格式化（比如带千分位、自定义格式字符串的场景），这些逻辑非常复杂，不可能靠底层机器指令直接完成，必须有具体的代码来处理文化信息、格式规则等细节。

4. 跨语言兼容性 #

.NET是多语言平台，F#、VB.NET等语言都需要和原生值类型交互。显式的实现能保证不同语言在调用这些类型的方法时行为完全一致，不需要每种语言都单独实现一套适配逻辑。

另外补充一点：这些实现里的简单方法（比如CompareTo的核心逻辑）会被JIT编译器优化成直接的机器指令，性能和底层操作几乎没有区别；而复杂逻辑（比如格式化）则会执行你看到的具体代码，兼顾了性能和功能的完整性。

内容的提问来源于stack exchange，提问作者Alex Zhukovskiy