很遗憾，C#的预处理器指令（比如#if、#elif这类）不支持直接引用类中定义的常量。原因很简单：预处理器是编译流程的极早期环节，这时候编译器还没开始解析类的结构和常量值，它只能识别自己专属的预处理器符号（通过#define代码指令或项目属性配置的符号）。

不过针对你提到的“多构建模式组合维护麻烦、希望未使用代码不被编译”的痛点，有几个替代方案可以满足需求：

1. 用MSBuild条件属性管理预处理器符号（推荐） #

你不需要手动维护9种预处理器定义和多个csproj，可以通过MSBuild的条件属性来动态生成预处理器符号，把配置集中在一个csproj里：

在项目的.csproj文件中添加以下配置：

<PropertyGroup>
  <!-- 默认模式，可选 -->
  <BuildMode Condition=" '$(BuildMode)' == '' ">One</BuildMode>
</PropertyGroup>

<PropertyGroup Condition="'$(BuildMode)' == 'One'">
  <DefineConstants>BUILD_MODE_ONE</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition="'$(BuildMode)' == 'Two'">
  <DefineConstants>BUILD_MODE_TWO</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition="'$(BuildMode)' == 'Three'">
  <DefineConstants>BUILD_MODE_THREE</DefineConstants>
</PropertyGroup>

之后编译时，只需要通过命令行参数指定构建模式即可：

# 编译Mode=One的版本
dotnet build -p:BuildMode=One
# 编译Mode=Two的版本
dotnet build -p:BuildMode=Two

这样做的好处：

• 完全保留条件编译的优势，未使用的代码会被彻底排除在编译产物之外
• 不需要维护多个csproj，所有配置集中在一个文件里，扩展新模式只需要加新的<PropertyGroup>分支
• 新人上手成本低，只需要记住指定BuildMode参数即可，不用手动修改预处理器定义

2. 利用源代码生成器动态生成代码 #

如果你想彻底摆脱预处理器符号，可以用C#的源代码生成器（Source Generator）。它能在编译时读取类的常量值，然后动态生成对应的方法/类实现，未使用的代码根本不会被生成：

大致实现思路：

1. 定义一个标记属性，用来标识需要根据构建模式生成的方法：

   [AttributeUsage(AttributeTargets.Method)]
   public class GenerateByBuildModeAttribute : Attribute { }
   

2. 编写一个源代码生成器，在编译时读取BuildConfig.Mode的常量值，然后为标记了GenerateByBuildMode的方法生成对应的实现
3. 生成器会在编译阶段把正确的实现注入到项目中，替代你原来的占位方法

这种方案的优势是完全基于类常量做判断，利用编译器的类型检查避免出错，同时能彻底移除未使用的代码。缺点是需要编写源代码生成器的代码，有一定学习成本，但适合复杂的多模式场景。

3. 常量分支的编译优化（简单场景适用） #

如果你的方法签名不需要变化，只是实现不同，可以利用C#编译器对常量分支的优化特性：

public class SomeClass { 
    public void SomeMethod() {
        if (BuildConfig.Mode == BuildMode.One) {
            // Implementation one
        }
        else if (BuildConfig.Mode == BuildMode.Two) {
            // Implementation two
        }
        else if (BuildConfig.Mode == BuildMode.Three) {
            // Implementation three
        }
    }
}

因为BuildConfig.Mode是const常量，编译器会在编译时判断哪个分支为true，直接把其他分支的代码从IL中移除。虽然方法本身还是会被编译，但无关的实现代码会被彻底删掉。

不过这个方案的局限性是：无法移除整个方法或类，只能优化方法内部的代码。如果需要完全删除未使用的方法/类，还是得用前两种方案。

内容的提问来源于stack exchange，提问作者Leff Ivanov