前阵子有个做嵌入式开发的朋友问我“项目想区分 debug 和 release 两套配置该怎么建”这个问题听起来基础但真要做扎实涉及的细节远比想象中多。我常年跟多套构建方案打交道从 Visual Studio 到 CMake从 Maven 到 Keil踩过的坑两只手数不过来。debug 配置负责让开发者在代码里“问东问西”打断点、看变量、追踪调用栈release 配置负责把程序打磨到适合交付的状态体积更小、跑得更快、不泄露内部调试信息。两者的差异往大了说能牵扯到编译优化级别、符号表剥离、日志开关往小了说连一个宏定义都不一样。这篇文章我就把整个设计思路和实操步骤掰开揉碎把我实际验证过的方法和踩过的坑一次性讲清楚。1. 先搞清楚debug 和 release 配置到底在配置什么1.1 三个本质差异符号表、优化级别、断言与日志debug 和 release 之间的差距核心是三件事符号表symbol table、编译优化级别、断言与日志行为。符号表就是编译器生成的、把“机器指令地址”和“源代码位置、变量名”对应起来的一张表。debug 配置需要保留完整的符号表调试器才能告诉你当前停在哪一行、某个局部变量值是多少。release 配置一般会把符号表剥离或单独打包否则一个几 MB 的程序能膨胀到几十上百 MB还等于把源码结构免费送给逆向分析的人。编译优化级别更好理解。GCC/Clang 有 -O0、-O1、-O2、-O3、-Os 等档位MSVC 有 /Od、/O1、/O2 等。debug 配置通常用 -O0 或 /Od意思是不做优化让每条语句和生成的机器码尽量一一对应方便断点和单步。release 配置则用 -O2 甚至更高优化让程序跑得更快。这里有个刚入行的朋友常常困惑的地方感觉 release“优化后代码更多”吗答案恰好相反优化后代码更少但执行顺序跟源代码不再是线性对应所以调试体验会比较差这也是为什么不能拿 release 配置来打断点下单步的原因。第三点是断言和日志。C/C 里的 assert() 宏在 release 构建下常常被定义成空操作因为断言只在开发阶段有意义。日志方面debug 配置通常输出到控制台或者调试器窗口release 配置则可能启用异步日志、写文件、上报远端。这个问题在 Java、Python、JavaScript 里也一样只是表现形式不同比如 Python 里用if __debug__:判断Java 里有if (BuildConfig.DEBUG)。只讲概念容易飘举个具体例子。假设你有一段 C 代码int compute(int x) { assert(x 0); return x * 2; }在 debug 配置下如果传入 x-1assert 会弹出断言失败提示你这里有非法输入。在 release 配置下assert整个被宏换成空操作x-1 会直接走到return -2程序继续跑后面接的 bug 就藏在别处了。这就是“release 行为跟 debug 不一致”的一个最典型来源。理解了这个你就能明白为什么配置分离不是随手点两下鼠标的事而是真真切切影响程序正确性的工程决策。1.2 配置的本质同一份源码多套参数组合理解了差异再看“配置”这个词。它本质上是构建工具或 IDE 里一份命名的参数集合。同一份项目文件同一份源码通过切换配置产出不同的构建结果。这就是配置分离的核心思想一份源码多套构建产物。这套思想贯穿了几乎所有工具链CMake 里叫 Build Type构建类型预置了 Debug、Release、RelWithDebInfo、MinSizeRel 四种Maven 里叫 Profile可以通过命令行参数或配置项激活Gradle 里叫 Build TypeAndroid 项目默认就有 debug 和 releaseVisual Studio 里叫 Solution Configuration解决方案配置Keil 里叫 Target目标通过 Options for Target 管理。名字各不相同思路完全一致。我见过不少项目尤其是小团队和刚入门的学习者常年只用一套配置要么一直是 debug要么永远是 release。开发阶段一直用 debug 没问题但如果交付时忘记切成 release后果就是程序性能明显下降因为没开优化、可执行文件巨大、调试信息暴露内部变量名和模块结构。反过来如果一直用 release 开发你会发现断点经常不触发、变量显示“optimized out”、代码行跳来跳去。所以从项目第一天就建好两套配置这个习惯越早养成越好。2. 主流 IDE 里的配置创建与切换一次摸清2.1 Visual Studio解决方案配置和项目配置的层级关系Visual Studio 是很多人接触“配置”概念的第一站。右键解决方案选择 Configuration Manager弹出的对话框里能看到当前解决方案的配置比如 Debug、Release、x86、x64。这里有个关键认知必须建立解决方案配置Solution Configuration和项目配置Project Configuration不是一回事。解决方案配置是一个“汇总表”它给解决方案里的每个项目单独指定用哪种项目配置。假设一个解决方案有 5 个项目其中 4 个是核心库、1 个是测试框架你完全可以建一个 MyLibsRelease 专门让 4 个核心库用 Release、测试框架用 Debug。这在大型项目里是非常实用的技巧。默认情况下新建解决方案时系统会自动生成 Debug 和 Release 两个解决方案配置每个项目也都自动生成对应的项目配置。创建自定义配置的步骤不复杂Configuration Manager → Active solution configuration 下拉框 → New → 填名字比如 Debug_NoLTO然后选择从 Debug 复制基础设置。“从已有配置复制”这个选项很实用它会把编译器选项、路径设置等一并复制过来省去大量手工填写。但注意复制只发生在创建那一刻之后你在 Debug 里改了任何设置不会自动同步到 Debug_NoLTO。还有一个我经常提醒自己的点切换配置后要检查项目依赖的库文件路径是不是也跟着切了。VS 的属性页里链接器 → 常规 → 附加库目录如果硬编码了x64\Debug那你切到 Release 时就会链接失败或链接到旧库。正确做法是用宏比如$(SolutionDir)lib\$(Configuration)\让配置名自动拼进路径。这个细节能帮你避免一大半 Release 构建报错的问题。2.2 IntelliJ IDEA / Android StudioRun Configuration 与 Build VariantIDEA 的体系跟 VS 不太一样。在 IDEA 里项目本身的构建配置由 Maven 或 Gradle 管理但“怎么运行这个工程”则由 Run Configuration 管理。顶部工具栏的绿色运行按钮旁有个下拉框点开 Edit Configurations你可以看到很多类型的运行配置Application、JUnit、Spring Boot、Remote JVM Debug 等。对于 Java 开发新建一个 Application 类型的 Run Configuration 时关键参数包括Main class入口类、VM optionsJVM 参数比如-Xmx2g、Program arguments命令行参数、Environment variables环境变量和 Working directory。你可以建两个 Run Configuration一个叫 App-Dev、一个叫 App-Prod后者带上-Dspring.profiles.activeprod这样一键就可以切换到生产环境参数。这个做法在微服务调试里几乎是标配每个服务至少两个 Run Configuration 起底。Android Studio 还需要单独提一下 Build Variant 概念。由于 Android 项目底层是 Gradledebug 和 release 对应不同的构建任务。在 View → Tool Windows → Build Variants 窗口里下拉框可以切换 debug/release。切换后Gradle 会执行对应的 assembleDebug 或 assembleRelease 任务连生成的 APK 路径都不一样分别在app/build/outputs/apk/debug/和app/build/outputs/apk/release/下面。IDE 的调试功能断点、CPU Profiler在 debug 类型下最完整release 类型如果没有额外配置debuggable true断点基本是不工作的。关于 IDEA 远程 debug我在这里多说一句。很多人在社区里搜“idea 远程 debug 配置”其实核心就一个 JVM 参数-agentlib:jdwptransportdt_socket,servery,suspendy,address*:5005。把这个参数加到远端进程的启动命令行里然后本地建一个 Remote JVM Debug 类型的 Run Configuration填上远端 IP 和端口就能连上去断点调试。实操中容易踩的坑集中在两点一是address*:5005这个写法在 JDK 9 之后才对所有网卡生效写成address5005可能只监听 localhost二是suspendy会让远端进程等人来连如果不调试就启动进程会一直挂着所以日常启动写suspendn更省心。2.3 Keil / STM32CubeIDE嵌入式世界的配置细节嵌入式开发里的 debug/release 区别比上层开发藏得更深。拿 Keil MDK 举例工程里可以创建多个 Target目标最朴素的做法就是建一个名为 Debug 的 Target 和一个名为 Release 的 Target。在 Options for Target → Target 页下不同 Target 可以指定不同的晶振频率、ROM/RAM 起始地址有的 Release 版本需要把启动代码放到特定地址。在 Output 页下Debug 的 Target 可以勾选 Browse Information方便 Source Browser 查定义Release 的 Target 通常不勾因为会增加编译时间和中间文件体积。在 Debug 页和 Utilities 页里debug Target 通常配置为使用 ST-Link 或 J-Link 的 SWD 接口下载速度设低一点比如 1MHz来增加稳定性Release Target 则可能使用 JTAG 加较高速度或者干脆不配置调试器只生成 Hex/Bin 文件用于工厂烧录。这个差异在量产阶段非常关键试想一下产线上的烧录工具如果跑着 1MHz 的 SWD一片板子多烧好几秒量大了就是不小的成本。STM32CubeIDE基于 Eclipse里逻辑类似通过 Run → Debug Configurations 管理调试配置通过 Project Properties → C/C Build → Settings 管理编译配置。很多人在 CubeIDE 里遇到过切换 Release 配置后代码里明明写了 printf 却没有输出原因往往是 Retarget_stdio 逻辑里没有处理 Release 下 USE_RTT 或 USE_SWO 宏被禁用的情况。排查思路很简单确认链接器是否包含了对应的重定向实现文件以及宏定义是否在两种配置下保持一致。嵌入式还有一个独特问题链接脚本.ld 文件或 .sct 文件。很多工程师只在 Release 配置里把堆栈大小调大Debug 配置忘了同步结果 Debug 下跑着跑着栈溢出程序飞了。我见过最离奇的一次同事调了两天最后发现是 Debug 配置的栈大小只有 1KB而代码里一个递归函数瞬间就把它吃完了。所以我的习惯是每次调整链接脚本Debug 和 Release 两份配置一定要同步更新或者直接用同一个链接脚本文件只在个别宏上做区分。3. 构建工具链里的配置实战CMake、Maven、Gradle3.1 CMakeCMAKE_BUILD_TYPE 和单配置/多配置生成器CMake 的 Build Type 通过CMAKE_BUILD_TYPE变量指定可以取 Debug、Release、RelWithDebInfo、MinSizeRel 之一。创建项目时通常的做法是在 CMakeLists.txt 里加一段逻辑判断if(NOT CMAKE_BUILD_TYPE) set(CMAKE_BUILD_TYPE Debug CACHE STRING Build type FORCE) endif()这样用户如果没有通过-DCMAKE_BUILD_TYPERelease指定构建类型默认就是 Debug。但这里有个很容易被绕晕的点这个逻辑只在“单配置生成器”里生效比如 Unix Makefiles、Ninja。对于 Visual Studio 这类“多配置生成器”构建类型并不写入 CMakeCache.txt而是在构建时通过--config参数传入cmake -S . -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release我见过不少人在 Windows 上使用 Visual Studio 生成器时执着地在命令行里输-DCMAKE_BUILD_TYPEDebug结果生成的工程里还是看不到调试符号原因就在这儿。多配置生成器下配置是在cmake --build时决定的不是 configure 时决定的。所以排查这类问题第一步先弄清楚当前用的是哪种生成器。在 CMakeLists.txt 里想针对不同配置设置不同编译选项标准做法是使用target_compile_options配合生成器表达式target_compile_options(my_app PRIVATE $$CONFIG:Debug:-O0;-g3;-Wall $$CONFIG:Release:-O2;-DNDEBUG )生成器表达式的含义是当且仅当当前配置是 Debug 时使用后面那组选项当且仅当是 Release 时使用 Release 那组。这个方法比直接操作CMAKE_CXX_FLAGS_DEBUG更清晰因为所有跟目标相关的选项都写在了一起别人读你的 CMakeLists 时不需要到处翻变量。还有一个关于 RelWithDebInfo 的建议。如果你的程序偶尔出现 release 下才能复现的崩溃不要直接上调试器硬刚先编一个 RelWithDebInfo 版本。它既开了优化又保留调试符号很多“release 才出现的 bug”在这个配置下能跑、能查、能定位。等找到根因再切回纯 Release 验证修复效果这是效率最高的一条路径。3.2 MavenProfile 的三种激活方式和最佳实践Maven 的 Profile 是 Java 世界里管理多环境配置的经典方案。Profile 可以在 pom.xml 里定义也可以放在 settings.xml 里。激活方式有三种显式激活mvn package -P profileId、隐式激活通过 activation 元素里的 JDK 版本、操作系统、系统属性、文件存在与否触发以及 settings.xml 里的 activeProfiles 直接默认激活。一个典型的按环境管理资源的做法是让不同 Profile 对应不同资源配置文件profiles profile iddev/id activation activeByDefaulttrue/activeByDefault /activation properties envdev/env /properties /profile profile idprod/id properties envprod/env /properties /profile /profiles然后在 build 的 resource 配置里用${env}占位符来选择具体资源目录build resources resource directorysrc/main/resources/${env}/directory /resource /resources /build这相当于把“运行环境”和“构建配置”解耦。对于 Java 里的spring.profiles.active那是 Spring 框架运行时环境的概念跟 Maven Profile 是两回事很多新手会把它们混在一起。Maven Profile 只管构建时选哪套资源、哪套依赖、哪套插件参数Spring Profile 只管程序运行时激活哪个 Bean、读哪份配置。两者可以联动比如 Maven 的 prod profile 把-Dspring.profiles.activeprod写进 MANIFEST 或启动脚本但逻辑上必须分开理解否则出了问题很难定位。Maven Profile 有个需要特别注意的坑activeByDefault只在没有任何其他 Profile 被显式激活时生效。如果 pom 里设置了 activeByDefault但命令行-P指定了另一个 Profile或者 settings.xml 里激活了某个 Profile那默认激活就失效了。多模块项目里更要小心子模块的 Profile 不会自动继承父模块的 Profile需要父模块通过 activeProfiles 显式指定或者子模块自己声明否则构建时容易出现“本地好好的CI 上行为不一致”的情况。3.3 GradleBuild Type、BuildConfig 和依赖变体Gradle 是目前配置体系最丰富、概念也最容易混淆的构建工具之一。在 Android 项目里android { buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile(proguard-android-optimize.txt), proguard-rules.pro signingConfig signingConfigs.release } debug { debuggable true applicationIdSuffix .debug versionNameSuffix -debug } } }每个 Build Type 自动对应一个布尔常量BuildConfig.DEBUG在 Java/Kotlin 代码里可以直接判断if (BuildConfig.DEBUG) { Log.d(TAG, debug log); }release 类型下BuildConfig.DEBUG是 false编译器会把这个分支判定为不可达代码最终不打包进 APK。这就是前面说的“日志开关”在 Android 里的落地实现。很多公司会在 release 里另外加一层逻辑把日志通过网络日志系统上报而不是直接删掉但那属于业务需求BuildConfig.DEBUG 仍然是判断开关的最基础手段。Gradle 的第二个概念是 Product Flavor产品风味用来区分免费版、付费版、不同渠道包等跟 Build Type 是正交的。两者组合构成 Build Variant比如 FreeDebug、PaidRelease。当需要依赖第三方库的不同版本时Gradle 允许按 Build Type 声明依赖dependencies { debugImplementation com.example:lib-debug:1.0.0 releaseImplementation com.example:lib-release:1.0.0 }这个机制在实际项目里极其重要。比如 debug 需要打详细日志release 需要跑性能监控你就可以分别在 debug 和 release 依赖里提供不同接口实现。但要注意如果两个变体提供的类名和方法签名不一致代码里引用的类在某个变体下编译不过——变体选择和编译路径没搞对很容易出现“本地 build 成功CI build 失败”这种经典问题。我在团队里要求所有用 Build Type 区分的依赖接口类必须放在公共源码集里只在实现类上做变体区分这样能显著降低出错概率。4. 常见问题与排查技巧实录4.1 release 编译通过但运行行为跟 debug 完全不一样这是最经典的问题社区里随手一搜就是一大片。程序在 debug 下跑得好好的release 一跑就崩溃、就乱输出。我见过的原因里排行前三的分别是未定义行为UB被优化触发。比如栈上变量未初始化在 -O0 下恰好就是 0看起来“正常”到 -O2 下编译器激进优化寄存器里残留垃圾值程序行为就变了。排查方法是开 UBSan/ASan把未定义行为暴露出来。断言代码被移除。assert 在 Release 下变成空操作原来靠断言兜底的逻辑走到了不该走的分支。具体例子我前面已经写过。浮点运算优化导致精度变化。-ffast-math 这类选项会改变浮点运算顺序结果和 debug 下不同有时就引发连锁错误。我的建议是遇到“release 行为跟 debug 不一致”时别急着怀疑工具链先编译一个 RelWithDebInfo 版本。它能保留断点和变量查看能力同时尽量复现 release 的优化行为一边开优化、一边调断点定位起来快得多。等找到问题再切回纯 Release 验证修复效果。4.2 配置切换后编译报错打不开预编译头文件社区里经常能看到类似“release 项目无法打开预编译头文件: x64\release\xxx.pch”的报错这是 Visual Studio 里非常常见的 PCH预编译头路径问题。原因通常是项目从 Debug 切换 Release 后中间文件目录Intermediate Directory变了但 PCH 的强制包含项或输出路径没有跟着变或者多个项目之间错误地共享了同一个 pch 文件。解决方法打开项目属性 → C/C → 预编译头确保“预编译头文件”和“预编译头输出文件”路径不是硬编码的 Debug/Release 目录而是使用$(IntDir)变量。同时确认所有相关项目在 Configuration Manager 里都选了正确的项目配置避免 A 项目 Release 引用了 B 项目 Debug 的 .lib。这个“配置混用”问题在大型解决方案里尤其隐蔽因为 VS 允许每个项目独立选择配置看起来都是 Release实际上某个项目还挂在 Debug 上。4.3 依赖版本在不同配置下不一致Maven/Gradle 项目构建工具的 Profile/Configuration 不仅影响编译选项还会影响依赖解析范围。比如 Maven 中某个依赖只在 prod profile 里声明那么mvn clean install默认 dev和mvn clean install -Pprod显式 prod得到的依赖树不同。很多人把“默认配置能编译”理解为“所有配置都能编译”这是错误推断。CI 流水线里构建环境跟本地不同就会出现“本地通过CI 失败”的诡异问题。我个人的建议是把 CI 里所有需要验证的 Profile 组合全部列出来逐个跑一遍构建脚本最好写成矩阵任务。像 GitHub Actions、Jenkins 都支持构建矩阵把 profile 名作为矩阵维度跑起来一目了然。Gradle 用户则要留意--build-cache开启后不同 Build Type 间缓存键冲突导致产物混用的可能排错时可以加--no-build-cache暂时关闭缓存来验证。这个细节比较冷门但一旦遇到就非常难受编译产物时对时错最后才发现是缓存键没有把 Build Type 纳入计算。4.4 IDE 里的 debug 功能不生效断点不触发断点不触发的原因很多我总结过一份速查表编译时没生成调试符号。GCC/Clang 检查是否加了-gMSVC 检查/DEBUGKeil 检查 “Debug information” 是否勾选。调试符号和正在运行的程序版本不匹配。代码改过没重新编译或者编译后没重新部署到目标设备。我在嵌入式上踩过最深的坑就是程序烧到芯片里了但 IDE 里的符号表还是上一个版本的断点位置全偏。代码被优化掉了。release 模式下某行代码可能被重排或合并断点自然不触发。切到 debug 或 RelWithDebInfo。远程调试时端口或地址配置错误。IDEA 远程 debug 需要确认启动参数-agentlib:jdwptransportdt_socket,servery,suspendn,address*:5005且防火墙放行对应端口。嵌入式环境下优化级别过高导致全速运行时无法命中硬件断点。可能只有少量硬件断点寄存器软件断点需要改内存指令如果 Flash 被写保护断点一样不生效。我遇到过一次特别隐蔽的情况Keil 里 debug 配置用的是 ST-Linkrelease 配置用的是 J-Link两个 Target 共用同一个工程文件但 Utilities 页设的下载算法不同导致在 release 配置下点调试程序烧进去了却跑不起来。最后把两个 Target 的 Flash Download 配置统一才解决。这提醒我切换配置后第一件事是检查 IDE 里跟“运行/调试硬件”相关的设置是否也同步切换了别只盯着编译选项。4.5 缓存引起的“改了配置却不生效”现在的主流工具链都有缓存CMake 的 CMakeCache.txt、Gradle 的 build 目录、Maven 的 target 目录、IDE 的索引缓存。遇到配置修改后行为不变通常就是缓存作祟。常规排错手段简单粗暴但有效删掉缓存目录重新配置。CMake 的标准操作是rm -rf build cmake -S . -B buildGradle 对应gradle clean如果还不行就清理~/.gradle/caches/下对应项目的缓存代价稍大慎用。Maven 是mvn clean加上-U强制刷新依赖快照。曾经有同事被 Gradle daemon 坑过改完构建脚本daemon 里还是旧的执行gradle --stop重启 daemon 就好了。所以遇到“改配置没反应”不要慌着改代码先质疑缓存这是成本最低的排查方向。4.6 几个热搜词里的专项问题速查借着写这篇博文的机会我把社区里高频问到的几个问题也一并整理成速查表方便对照排查。现象或需求解决方案Keil MDK 里 debug 设置闪退多数是旧工程兼容问题尝试迁移到新版 MDK或关闭存在冲突的插件/自定义脚本IDEA 提示 cannot find project files at检查项目的 .idea 目录和 .iml 文件是否存在损坏时用 File/Open 重新导入工程Android Studio 切换 Release 后无法断点确认 release 的 debuggable 没有关闭或临时切回 debug 变体验证npm 项目报 cannot find node_modules先执行 npm install再检查 .npmrc 的 registry 配置是否可访问需要 MySQL 的 release 驱动去 Maven Central 搜 com.mysql:mysql-connector-j选稳定版本注意区分驱动 API 版本日志只看 debug 级别一直刷屏检查日志框架级别配置release 模式下应把 level 调整到 INFO/WARN这个表格里每一行背后都有一串排查故事。比如“日志只看 debug”这个问题很多小伙伴在本地把 logback 配成 DEBUG交付时忘了切回 INFO线上日志一天几个 GB性能被 I/O 拖垮。我在团队里定的规矩是日志配置文件里禁止写死 LEVEL必须从环境变量或配置中心读取构建 release 时默认 INFO。这个习惯救了我好多次至少避免了两次线上事故级别的日志爆炸。5. 从零搭一套配置模板的思考说了这么多工具链的细节最后我分享一个自己在新项目里反复使用的配置模板规划思路。新项目初始化时我通常会在源码目录下建一个config或者build目录放所有跟构建配置相关的文件。拿 CMake 项目来说目录结构大概是这样project-root/ CMakeLists.txt cmake/ BuildConfig.cmake Toolchain-embedded.cmake config/ app-config.h.in logging.conf.in src/BuildConfig.cmake里集中定义各种构建选项比如默认编译标准、warning 级别、是否启用 LTO、是否生成调试符号等。CMakeLists.txt 里只需要 include 它然后基于它定义的变量去组合 Debug 和 Release 两套选项。这样做的核心好处是项目变大后构建逻辑不会散落在各个子目录的 CMakeLists 里改动一处就能全局生效。Java 后端项目的话我习惯用 Maven Profile 打底配合application-{profile}.yml。开发环境用 dev测试环境用 test生产环境用 prod。每个 Profile 里维护数据库连接、消息队列地址、日志级别等。这里有一个建议密码和密钥不要直接写进 porm 或 yml用环境变量占位符比如${DB_PASSWORD}由部署平台注入。这个习惯能避免很多配置泄露的事故。Gradle 项目则建议在build.gradle里用 extension 来管理版本号因为 Android 的 Build Type 和 Flavor 组合多了之后配置矩阵会变得很难维护。把版本号、依赖版本、插件版本提取成versionConfig扩展所有模块统一引用升级依赖时只改一个地方。这个模板化思路不需要一开始就做到多完美但方向一定要对配置要集中、要区分作用域、要能自动化验证。你可以从最简版本开始比如 CMake 项目只在根目录维护一个CMakePresets.json把 Debug 和 Release 的预设都写进去{ version: 3, configurePresets: [ { name: debug, generator: Ninja, binaryDir: ${sourceDir}/build/debug, cacheVariables: { CMAKE_BUILD_TYPE: Debug } }, { name: release, generator: Ninja, binaryDir: ${sourceDir}/build/release, cacheVariables: { CMAKE_BUILD_TYPE: Release } } ] }这样在命令行里执行cmake --preset debug和cmake --preset release就能切到两套独立的构建环境中间产物互不污染。这个方案我在本地和 CI 上同时使用效果非常好。做 CI 的时候加一条 job 分别跑 debug 和 release 的构建与测试保证两个配置始终处于可发布状态。长此以往你会在某一天发现许多朋友抱怨的“Release 下才出现的诡异问题”在你这边出现的频率低得多——不是你的代码和别人的有本质区别而是配置层面你已经把风险提前拆解了。