Flutter 中 kDebugMode 能像 assert() 一样从 release 构建中移除代码吗？

在标准 Flutter release 构建中，使用 if (kDebugMode) { ... } 可以可靠地移除条件块中不可达的 Dart 调试代码。对于问题中的日志示例，它可以替代 assert 闭包写法。两者的实现机制不同，但都适合隔离只在 debug 模式执行的代码。

这里被移除的是条件块中的 Dart 代码。如果要求某个依赖、原生库或资源文件也完全不进入 APK/IPA，还需要检查对应的构建和打包配置。

为什么 kDebugMode 可以移除代码？

kDebugMode 是编译期常量，定义为：

const bool kDebugMode = !kReleaseMode && !kProfileMode;

因此，在 release 编译时，下面的条件确定为 false：

if (kDebugMode) {
  print('Debug-only code here');
}

编译器可以消除这个不可达分支，运行时无需反复判断当前模式。Flutter 的 kDebugMode API 文档明确说明了常量条件支持代码移除，也将 assert 列为另一种写法。

如果一个函数只在该分支中被调用，且没有其他可达引用，它也可以被 tree shaking 移除；如果其他代码仍然调用它，该函数就需要保留。

assert 的原始示例需要补上返回值

assert 的条件必须求值为 bool。问题中的示例在闭包内调用了 print，但没有返回布尔值，需要在调试代码执行完成后返回 true：

assert(() {
  print('Debug-only code here');
  return true;
}());

断言关闭后，整个断言表达式都不会求值，闭包也不会执行，见 Dart 的 assert 文档。标准 Flutter release 构建会关闭断言，见 Flutter 构建模式说明。

两者的控制依据不同：assert 取决于断言是否启用，kDebugMode 取决于编译时的构建模式。在标准 Flutter 构建流程中，它们都能实现这里需要的效果，但生成的二进制文件不一定逐字节相同。

实际应该怎么写？

普通调试日志或诊断操作，使用 kDebugMode 即可：

import 'package:flutter/foundation.dart';

void logDebugDetails() {
  if (kDebugMode) {
    print('Debug-only code here');
  }
}

如果日志内容需要昂贵的计算，也应把计算放在条件内部：

if (kDebugMode) {
  final details = buildDebugDetails();
  print(details);
}

如果先在条件外执行 buildDebugDetails()，只把 print 放在条件内，前面的计算就不会被这个条件排除。

用于检查程序内部条件时，保留 assert 更直接，例如：

assert(items.isNotEmpty);

不要把 release 运行所必需的初始化、数据更新或错误处理放入这两类调试代码块。

kReleaseMode 的反向判断有何不同？

使用 !kReleaseMode 保护调试代码时，它与 kDebugMode 在 profile 模式下的行为不同：

因此，if (!kReleaseMode) 中的诊断代码也会在 profile 模式执行，可能影响性能测量。Flutter 的 kReleaseMode API 文档也因此建议优先使用 kDebugMode 或 assert 来隔离调试代码。

“完全不进入 APK/IPA”的范围是什么？

对于示例中的 Dart 分支，标准 release 优化可以将它移除。但仅凭这个条件，不能推断所有相关文件也已从安装包中消失：

• 其他可达代码使用的函数、类型或常量仍可能保留。
• 原生插件、原生库和打包资源需要按各自的构建规则判断，不能只依据 Dart 分支是否可达。
• 被条件包裹的代码仍需满足 Dart 的语法和类型要求，这种写法不能代替预处理器来隐藏无效代码。

如果交付要求某个库或文件不得存在，应使用实际发布配置构建并检查最终产物。日志没有输出只能说明那次运行没有执行日志，不能证明安装包已排除所有相关内容。

备注：内容仅供参考。