预处理指令是编译前文本替换，非运行时逻辑；#define等在编译解析阶段完成条件剔除，未满足条件的代码块彻底不存在，不进入语法分析和il生成。
预处理指令不是运行时逻辑，而是编译前文本替换
预处理指令（如 #define、#if、#else）在 C# 中不参与运行时执行，而是在编译器解析源码阶段就完成条件剔除或符号定义。这意味着：未满足条件的代码块（如被 #if DEBUG 包裹但当前未定义 DEBUG）根本不会进入语法分析和 IL 生成流程——它被彻底忽略，不是“跳过执行”，而是“不存在”。这点常被误认为类似 if (DEBUG)，但后者仍需编译、占用 IL、可能触发 JIT 编译开销。
-
#define必须出现在文件最顶部（在using之前），且不能带分号；它只对当前文件生效，无法跨文件传播 - 全局条件符号（如
DEBUG）通常由项目属性（Build → Conditional compilation symbols）或 MSBuild 的DefineConstants控制，而非靠#define手动铺满每个文件 - 不要用
#define定义值（如#define VERSION 2.1），C# 不支持带参数或数值的宏；要用常量字段或const变量替代
避免嵌套过深和逻辑反转带来的可读性灾难
多层 #if/#elif/#else 嵌套极易导致维护困难，尤其当不同平台（NET5_0、NET6_0）、配置（TESTING、PRODUCTION）和功能开关（ENABLE_LOGGING）交织时。编译器不会报错，但人眼很难追踪哪段实际存活。
- 优先用单层
#if+ 清晰命名的符号，例如#if USE_NEW_NETWORK_STACK，而不是#if !OLD_IMPLEMENTATION && NET6_0 - 避免否定式条件，如
#if !DISABLE_CACHE；改用正向定义#if ENABLE_CACHE，否则后续添加新分支时容易漏掉取反逻辑 - 大段被预处理剔除的代码建议加注释说明剔除原因，例如：
// #if DEBUG: only for local diagnostics, excluded in release
与 ConditionalAttribute 混用时注意作用域差异
ConditionalAttribute 是运行时机制，用于标记方法是否参与调用（仅当指定符号定义时才编译进调用点），而预处理指令是源码级剔除。两者目标相似（控制代码是否“存在”），但粒度和时机完全不同。
-
[Conditional("DEBUG")]修饰的方法体仍会被编译，只是所有对该方法的调用语句被移除；而#if DEBUG ... #endif内的整个代码块连方法定义都不会出现 - 不要试图用
#if包裹[Conditional]属性本身（如#if DEBUG [Conditional("DEBUG")] #endif void Log() {...}），这会导致语法错误——属性必须紧贴成员，且预处理不能拆解语法结构 - 调试辅助方法（如日志、断言）推荐用
[Conditional]，因为它保留方法签名一致性，且调用点剔除更安全；而整块功能模块（如旧版 API 兼容层）适合用#if
发布构建中符号未生效的典型排查路径
最常见问题是：本地调试正常，但 CI 构建或 dotnet publish -c Release 后，本该启用的 #if MY_FEATURE 分支完全没编译进去。这不是 bug，而是符号未被传入编译器。
- 检查项目文件中是否遗漏
<defineconstants>MY_FEATURE</defineconstants>，尤其注意 Release 配置下是否覆盖了 Debug 的设置（Condition="'$(Configuration)' == 'Release'"） - 命令行构建时，显式传入：
dotnet build -c Release -p:DefineConstants="MY_FEATURE"；注意等号两侧**不能有空格**，否则 MSBuild 解析失败 - 若用
#define在源码中声明，确认它在文件最上方、无空行/注释阻隔，并且该文件确实被编译（比如没被<compile remove="..."></compile>排除） - 在 IDE 中，可通过“转到定义”尝试跳转到某个条件符号——如果跳不到，说明它未被识别；此时打开“输出”窗口切换到“生成”视图，搜索 “DefineConstants” 查看实际传递值
预处理指令的威力在于彻底剥离代码，代价是失去运行时灵活性和调试可见性。一旦符号控制链变长（比如通过 props 文件间接定义），就很容易出现“以为启用了，其实没传进去”的静默失效。盯住 MSBuild 日志里的 DefineConstants 输出，比反复猜逻辑更可靠。
