基于Flutter和OpenHarmony的真值表训练App：逆向思维与工程实践

这个项目的起点有点反常识：训练逆向思维，绕不开的却是那套看起来已经“过时”的真值表。

我之前带过几个刚入行的同事，写业务代码时经常被复杂的 if 条件绕晕。不是他们逻辑能力差，而是大部分人脑子里少了一张“全可能性枚举表”。排查问题的时候只盯着自己觉得“可能出问题”的那一两个分支，完全没想过要把所有输入组合铺开。后来我就想，与其靠嘴讲，不如直接做一个以真值表为训练核心的 App，让用户亲手填表、亲手排错、亲手把表达式还原成真值表。这才是逆向思维训练的本质。

项目栈最终定为 Flutter + OpenHarmony。之所以选这两个，一是 Flutter 的 Dart 语言写逻辑引擎很顺手，二是 OpenHarmony 生态现在太需要这种小而完整的实战项目来验证工具链。整个 App 的核心是一套完全用 Dart 写的真值表引擎：词法解析、AST 求值、穷举赋值、题目生成、答案判定，全部不依赖平台通道。先讲清楚这个东西到底在训练什么，再讲引擎的数学模型，然后是 Flutter for OpenHarmony 的工程落地、核心代码、交互设计和真机排错。文末会把我实际踩过的坑全部列出来，给想在这条路上复刻的人省点时间。

1. 先想清楚再动手：这个App到底在训练什么

1.1 市面逻辑训练App的盲区

市面上能搜到的逻辑训练 App 大概分两类：一类是公考行测的逻辑判断题库，一类是离散数学的刷题工具。这两类都有一个共同的问题：它们把逻辑训练做成了“选择题”和“判断题”，用户选对了就给个红勾，选错了就给个正确答案，完事。

但逻辑思维真正要训练的是“自己生成答案”的能力，不是“认出正确答案”的能力。打个比方，背别人写好的作文和亲自动笔写作文，训练的是两种完全不同的能力。填真值表就是这么个逻辑：它不给用户选项，而是让你根据一个表达式自己推导出每一行的真假，推导错了系统告诉你第几行错了，但不会直接把答案喂到你嘴边。这种“被迫穷举所有情况”的节奏，才是逆向思维训练真正需要的。

1.2 逆向思维训练的三个真实场景

我做需求分析的时候，没有直接开始写代码，而是先列了三类典型用户，以及他们各自的痛点。

这三种场景对应到产品上，就是三种不同的练习模式。第一种是“正向填表”，第二种是“表达式实验室”，第三种是“逆向还原”。真正写代码时，核心引擎只需要一套，三种模式只是把这套引擎的不同能力组合起来。这也是为什么项目虽小，但架构上必须有清晰的引擎层和 UI 层分离。

1.3 真值表为什么是训练核心

真值表的价值在于它强迫你把“思维里的暗线”变成“纸面上的明线”。一个逻辑表达式有 n 个变量，就有 2 的 n 次方种赋值组合。大多数人脑补逻辑时，只会脑补自己熟悉的几种组合，遗漏掉那些“看起来不可能”的边界组合。比如 p && q，大部分人能想到 p=true,q=true 时为真，但可能漏掉 p=false,q=true 这种在逻辑上同样重要的情况。

逆向思维训练的核心，恰恰就是建立这种“全可能性枚举”的意识。真值表把所有的组合全部铺在一个二维表里，每一行都是真实存在的逻辑状态，不给你偷懒的机会。这个观点贯穿了整个 App 的设计：题目的答案不是靠“认出”来的，是靠一行一行填出来的。

2. 真值表引擎的数学模型与实现选型

2.1 为什么选AST而不是边读边算

写真值表引擎之前，最先要决定的是表达式怎么求值。教科书里常见的做法是中缀转后缀（逆波兰表达式），再通过栈求值。这个方案简单，但有一个问题：它只适合“求值”这单一场景。

这个 App 除了求值，还要生成题目、判定两个表达式是否等价、定位用户出错的行。这些功能如果放在抽象语法树（AST）上做，会非常自然。比如判断两个表达式是否等价，只需要分别用穷举的方式算两个表达式在每一行的真值，逐行对比就行，这在 AST 上就是一次 evaluate。但如果用逆波兰，你要回溯表达式的结构就会很别扭。所以虽然 AST 写解析器的时候多一点代码，但后续所有功能都变得简单。

2.2 运算符设计与优先级表

逻辑表达式里常用的运算符就五个：非、与、或、蕴含、等价。部分教材里还有异或，但在这个 App 里异或可以放在后续扩展，第一版先不做，否则题目生成器和说明文档都会复杂不少。

这五个运算符在 Dart 层的表示和优先级如下：

这里有一个关键设计决策：普通用户看着 ¬、∧ 这类符号会觉得陌生，所以 UI 层我用了更接近键盘输入的 !、&&、\|\|、->、<->。训练时表达式可以像 (p && q) -> (r || !p) 这样直接输入。后续如果想支持 Unicode 符号，只需要在词法层做一层符号映射，不影响 AST 结构。

还有一个细节是变量名只允许小写字母 p、q、r 等，不允许 a、b、c 之外的真实英文单词，避免和保留字冲突。

2.3 穷举赋值与真值表生成

真值表生成的数学本质很简单：如果有 n 个变量，就把 n 位二进制数从 0 枚举到 2^n - 1。每个二进制数位表示一个变量在该行的真值，比如 1 表示 true，0 表示 false。

变量顺序固定以后，每种枚举对应一行赋值：

dart复制List<Map<String, bool>> generateAssignments(List<String> variables) {
  final count = variables.length;
  final rows = <Map<String, bool>>[];
  for (var i = 0; i < (1 << count); i++) {
    final assignment = <String, bool>{};
    for (var j = 0; j < count; j++) {
      assignment[variables[j]] = ((i >> (count - j - 1)) & 1) == 1;
    }
    rows.add(assignment);
  }
  return rows;
}

这段代码把整数 i 的二进制位从高位到低位依次分配给变量列表。为什么从高位取而不是从低位取？因为如果从低位取，变量顺序会反转，真值表的行顺序会和大多数人习惯的“从左到右依次翻转”不一致。这个细节在写 UI 表头时很容易踩坑，我在前期调试时就是因为这个顺序问题，导致用户填的答案和引擎生成的答案对不上。

3. Flutter for OpenHarmony 工程落地实录

3.1 环境版本与工具链

Flutter for OpenHarmony 不是一套新的 UI 框架，它本质上还是 Flutter，只是 SDK 编译到了 OpenHarmony 的底层图形栈之上。所以搭建环境时，核心工具是这些：

• DevEco Studio（OpenHarmony 应用的集成开发环境，内置 SDK）
• Flutter SDK 的 OpenHarmony 分支（从 OpenHarmony SIG 仓库获取）
• hdc 调试工具（OpenHarmony 的调试命令工具，类似 adb）
• 一台 OpenHarmony 设备，我使用的是 RK3568 开发板

版本匹配是这个环节最容易出问题的点。Flutter SDK 的 OpenHarmony 分支并不是和标准 Flutter 完全同步的，它有几个不同的 tag。建议直接切换到开源社区维护的相对稳定版本，不要追最新 master。我一开始图新，拉了一个中间态的 commit，结果编译出来的 hap 包在设备上闪退，后来切回稳定 tag 就正常了。

3.2 创建工程与目录结构

创建工程其实很简单，和标准 Flutter 一样：

bash复制flutter create --org com.example --project-name truth_table_trainer --platforms=ohos .

关键点是 --platforms=ohos。早期的 Flutter for OpenHarmony 还不支持这个参数，需要手动往工程里塞 ohos 目录。现在新版已经支持直接生成，生成的工程里除了标准的 lib、android、ios，还会多出一层 ohos 工程目录。

如果你已有老工程，也可以在根目录执行：

bash复制flutter create --platforms=ohos .

它会自动补齐 ohos 目录而不会覆盖你 lib 下的代码。工程目录大致如下：

code复制lib/
  main.dart
  engine/           // 纯 Dart 逻辑引擎
  ui/               // 页面组件
  state/            // Provider 状态管理
ohos/
  entry/            // OpenHarmony 工程入口
android/
ios/

这里最重要的一点是：engine/ 目录下的所有文件不得 import 任何 Flutter 或平台相关的库。只有这样才能做到 UI 随便换，引擎不动。后面的章节我会单独讲这个设计。

3.3 依赖管理：能少用就少用

OpenHarmony 生态的问题是很多 pub.dev 上的 Flutter 插件没有对应的 OpenHarmony 实现。特别是依赖 Android 原生 API 的包，比如某些文件选择器、某些定位组件，在 OpenHarmony 上基本是不可用的。

所以这个项目的依赖选择原则很简单：优先纯 Dart 包，尽量不引入平台通道。

那些依赖原生渲染或原生控件的包，我在做依赖评审时全部砍掉了。真值表训练的场景其实不需要太多高级 UI 能力，基础组件完全够用。少一个插件，后续真机适配时就少一个变数，这个取舍在 OpenHarmony 项目里非常重要。

4. 核心代码实现：表达式解析、真值表生成与题目判定

4.1 词法分析与表达式解析器

表达式引擎的第一步是词法分析。用户输入 (p && q) -> r，Lexer 需要把它拆成一个个 Token：左括号、变量 p、与操作符、变量 q、右括号、蕴含操作符、变量 r。

dart复制enum LogicTokenType {
  variable,
  not,
  and,
  or,
  implies,
  iff,
  leftParen,
  rightParen,
}

class LogicToken {
  final LogicTokenType type;
  final String value;
  LogicToken(this.type, this.value);
}

class Lexer {
  final String input;
  int _pos = 0;

  Lexer(this.input);

  List<LogicToken> tokenize() {
    final tokens = <LogicToken>[];
    while (_pos < input.length) {
      final ch = input[_pos];
      if (ch == ' ') { _pos++; continue; }
      if (ch == '(') { tokens.add(LogicToken(LogicTokenType.leftParen, '(')); _pos++; continue; }
      if (ch == ')') { tokens.add(LogicToken(LogicTokenType.rightParen, ')')); _pos++; continue; }
      if (ch == '!') { tokens.add(LogicToken(LogicTokenType.not, '!')); _pos++; continue; }
      if (ch == '&' && _peek(1) == '&') { tokens.add(LogicToken(LogicTokenType.and, '&&')); _pos += 2; continue; }
      if (ch == '|' && _peek(1) == '|') { tokens.add(LogicToken(LogicTokenType.or, '||')); _pos += 2; continue; }
      if (ch == '-' && _peek(1) == '>') { tokens.add(LogicToken(LogicTokenType.implies, '->')); _pos += 2; continue; }
      if (ch == '<' && _peek(1) == '-' && _peek(2) == '>') { tokens.add(LogicToken(LogicTokenType.iff, '<->')); _pos += 3; continue; }
      if (_isVariableChar(ch)) { tokens.add(LogicToken(LogicTokenType.variable, ch)); _pos++; continue; }
      throw FormatException('无法识别的字符: $ch');
    }
    return tokens;
  }
}

Lexer 的每个分支都必须推进 _pos，最容易漏掉的是双字符和三字符运算符。比如 -> 占用两个字符，如果你只推进一个，下一个字符就是 >，直接把它当成非法字符报错。这种 bug 在单元测试里很容易暴露，但如果你不做单元测试，调试起来会非常费劲。

Parser 用的是递归下降法。先处理最低优先级的等价，再处理蕴含、或、与、非，最后处理括号和变量：

dart复制class Parser {
  final List<LogicToken> _tokens;
  int _pos = 0;

  Parser(this._tokens);

  AstNode parse() {
    final node = parseIff();
    if (_pos != _tokens.length) {
      throw FormatException('表达式存在多余的字符');
    }
    return node;
  }

  AstNode parseIff() {
    var left = parseImplies();
    while (_match(LogicTokenType.iff)) {
      final right = parseImplies();
      left = AstIff(left, right);
    }
    return left;
  }

  AstNode parseImplies() {
    var left = parseOr();
    while (_match(LogicTokenType.implies)) {
      final right = parseOr();
      left = AstImplies(left, right);
    }
    return left;
  }

  AstNode parseOr() {
    var left = parseAnd();
    while (_match(LogicTokenType.or)) {
      final right = parseAnd();
      left = AstOr(left, right);
    }
    return left;
  }

  AstNode parseAnd() {
    var left = parseNot();
    while (_match(LogicTokenType.and)) {
      final right = parseNot();
      left = AstAnd(left, right);
    }
    return left;
  }

  AstNode parseNot() {
    if (_match(LogicTokenType.not)) {
      return AstNot(parseNot());
    }
    return parsePrimary();
  }

  AstNode parsePrimary() {
    final token = _tokens[_pos];
    if (token.type == LogicTokenType.variable) {
      _pos++;
      return AstVariable(token.value);
    }
    if (token.type == LogicTokenType.leftParen) {
      _pos++;
      final node = parseIff();
      if (!_match(LogicTokenType.rightParen)) {
        throw FormatException('缺少右括号');
      }
      return node;
    }
    throw FormatException('期望变量或左括号');
  }
}

递归下降的层级顺序和优先级表一致：优先级越低的运算符，解析时越靠外层。这意味着 p || q && r 会被解析成 p || (q && r)，而不是 (p || q) && r，符合数学惯例。用户如果想改变顺序，必须加括号。

求值函数也很直白：

dart复制bool evaluate(AstNode node, Map<String, bool> assignment) {
  if (node is AstVariable) {
    return assignment[node.name]!;
  }
  if (node is AstNot) {
    return !evaluate(node.child, assignment);
  }
  if (node is AstAnd) {
    return evaluate(node.left, assignment) && evaluate(node.right, assignment);
  }
  if (node is AstOr) {
    return evaluate(node.left, assignment) || evaluate(node.right, assignment);
  }
  if (node is AstImplies) {
    return !evaluate(node.left, assignment) || evaluate(node.right, assignment);
  }
  if (node is AstIff) {
    return evaluate(node.left, assignment) == evaluate(node.right, assignment);
  }
  throw UnsupportedError('不支持的节点类型');
}

蕴含运算的实现用 !left || right，这是逻辑学里“蕴含只在前提为真而结论为假时才为假”的等价变形。理解这一点对于后续生成错因解释非常关键。

4.2 随机题目生成器

训练类 App 必须能持续出题，所以需要随机表达式生成器。我的做法是反着用 Parser：先随机生成一棵 AST，再把 AST 转成字符串。

dart复制class ExpressionGenerator {
  final Random _random;
  final List<String> variablePool = ['p', 'q', 'r'];

  ExpressionGenerator({Random? random}) : _random = random ?? Random();

  String nextExpression(int depth) {
    final ast = _generateNode(depth);
    return _astToString(ast);
  }

  AstNode _generateNode(int depth) {
    if (depth == 0 || variablePool.length < 2) {
      return AstVariable(variablePool[_random.nextInt(variablePool.length)]);
    }
    final op = _random.nextInt(5);
    switch (op) {
      case 0:
        return AstNot(_generateNode(depth - 1));
      case 1:
        return AstAnd(_generateNode(depth - 1), _generateNode(depth - 1));
      case 2:
        return AstOr(_generateNode(depth - 1), _generateNode(depth - 1));
      case 3:
        return AstImplies(_generateNode(depth - 1), _generateNode(depth - 1));
      case 4:
        return AstIff(_generateNode(depth - 1), _generateNode(depth - 1));
      default:
        return AstVariable(variablePool[_random.nextInt(variablePool.length)]);
    }
  }
}

随机生成 AST 需要注意变量数量。如果 depth 太大，随机生成的表达式会有 3 个以上变量，真值表行数就是 8 行、16 行，这对手机屏幕很不友好。所以我限制 depth 在 2 到 3 之间，并且确保生成后 AST 里的变量数量是 1 到 3 个，超过 3 个就重新生成。另一个细节是避免生成 !p && !p 这种两个子树完全相同的表达式，因为变量重复会导致题目的答案列出现大量重复，观感不好。最简单的方式是生成后检查变量集合，少则重新生成，多则接受。

4.3 用户答案判定与错因提示

用户填完整个真值表后，判定逻辑就是把用户输入的每一行和引擎计算出的正确结果逐行比对：

dart复制class AnswerChecker {
  final AstNode expression;
  final List<String> variables;

  AnswerChecker(this.expression, this.variables);

  List<int> check(List<List<bool?>> userAnswers) {
    final wrongRows = <int>[];
    final rows = generateAssignments(variables);
    for (var i = 0; i < rows.length; i++) {
      final correct = evaluate(expression, rows[i]);
      final user = userAnswers[i].last;
      if (user != correct) {
        wrongRows.add(i);
      }
    }
    return wrongRows;
  }
}

这里有一个重要的产品设计：用户填写时，每一行的结果列只有“真”“假”“未填”三个状态。提交时，null 会被当成错误处理，但错因提示会和普通错误区分开。比如第 2 行没填，就提示“你漏掉了第 2 行的判断”；如果填错了，就提示“第 3 行的判断有误，请检查这行变量的赋值”。这样用户能明确知道自己是在“漏”还是“错”。

错因解释是一步步扩展出来的。第一版只给出了“哪一行错误”的提示，后来发现用户卡住时还是不知道为什么错。于是我在引擎里加了一个函数，专门生成“为什么这一行的答案是 true/false”的解释文本：递归遍历 AST，根据运算符的语义拼出人话。比如对 p -> q 这一行，引擎会生成“因为 p 为 false，所以蕴含表达式为 true”。这颗解释器本质上就是 Evaluator 的一个变体，把返回类型从 bool 换成了字符串。

5. 练习页的交互设计：填表、判定与错因提示

5.1 真值表表格组件

练习页最核心的部分是一张动态生成的真值表。表头由变量列表加结果列组成，行数由变量数量决定。我用一个 TruthTableView 组件来渲染，每行的变量列是可点击的按钮，结果列是另一个按钮。

点击变量的按钮会在 true、false 之间循环切换，结果列则在“未填”“true”“false”之间循环切换。为什么不把结果列也做成普通开关而是三态按钮？因为“未填”这个状态非常关键，它让用户在提交前能一眼看到自己还有哪些行没有判断，比“全填了但可能错”更容易自我检查。

dart复制class TruthTableView extends StatelessWidget {
  final List<String> variables;
  final List<AnswerRowData> rows;
  final ValueChanged<int> onToggleVariable;
  final ValueChanged<int> onToggleResult;

  // build 方法：用 Table 组件渲染表头和各行
}

这段代码在真机上跑起来初期有个小问题：当变量超过 3 个时，Table 的列数变多，在窄屏上文字会换行。后来我把每个单元格的宽度改成固定值，表头使用自动收缩策略，并在变量数量大于 3 时禁用题目生成，才算解决。

5.2 Provider 管理练习状态

练习页的状态用 Provider 管理，核心类是这样设计的：

dart复制class ExerciseState extends ChangeNotifier {
  AstNode? expression;
  List<String> variables = [];
  List<AnswerRowData> answerRows = [];
  String? feedbackMessage;
  bool submitted = false;

  void startNewExercise(ExpressionGenerator generator) {
    // 重新生成题目，初始化 answerRows
  }

  void toggleVariable(int row, int variableIndex) {
    answerRows[row].values[variableIndex] = !answerRows[row].values[variableIndex];
    if (submitted) submitted = false;
    notifyListeners();
  }

  void submit() {
    final result = AnswerChecker(expression!, variables).check(answerRows);
    if (result.isEmpty) {
      feedbackMessage = '全部填写正确';
    } else {
      feedbackMessage = '有以下行判断有误：${result.join(", ")}';
    }
    submitted = true;
    notifyListeners();
  }
}

这里有个很容易忽略的交互细节：用户提交后如果又改了任何一行的值，submitted 状态要立刻置为 false。否则用户改了答案后，界面还停留在“已提交”的反馈状态，非常误导。反过来，如果用户没做任何修改，重复点击提交，应当保留上一次的判定结果，而不是重新计算。这个逻辑在第一版没处理好，反复提交时按钮状态出现了闪烁。

5.3 答题反馈与复习策略

每次练习结束后，App 会把本次做题的统计写入本地存储：总题数、正确率、出现错误最多的运算符类型。下次进入首页时，系统会优先推荐对应运算符的题目。

这个复习策略很简单：在题目生成器里加入了一个权重参数。比如 -> 运算符的错误率最高，那么生成题目时 -> 被选中的概率就提高。原理就是根据用户最近 20 次做题的错误分布动态调整运算符的采样权重。虽然实现很粗糙，但用户反馈比完全随机出题有明显的进步感。

6. OpenHarmony 真机适配与排错

6.1 在RK3568上运行的基本流程

工程代码写完后，最终要在真机上跑起来，这一步才是 Flutter for OpenHarmony 的试金石。我的设备是 RK3568 开发板，系统镜像为 OpenHarmony 官方 nightly 版本。

先用 hdc 工具确认设备连接：

bash复制hdc list targets

然后查看设备系统版本：

bash复制hdc shell param get const.product.name
hdc shell param get const.product.version

构建 hap 包的命令是：

bash复制flutter build hap --release

如果是调试阶段，用 --debug 构建会快很多，但生成的包比较大。安装到设备：

bash复制hdc install build/ohos/xxx.hap

或者直接用 DevEco Studio 打开工程里的 ohos 目录，用 IDE 的 Run 按钮一键部署。但命令行方式在自动化脚本里更实用。

6.2 编译与插件报错：那些绕不开的 Gradle 坑

真机调试阶段我遇到的最经典报错有两个，热词里搜这些报错信息能找到大量相同遭遇的开发者在讨论。

第一个报错是：

text复制You are applying Flutter's main Gradle plugin imperatively using the apply script method, which is not supported anymore.

这个报错本质上是 Flutter for OpenHarmony 的 Gradle 插件版本和工程模板不匹配。标准 Flutter 从某个版本开始不再推荐用 apply script 的方式加载 Gradle 插件，而 OpenHarmony 分支的某些构建脚本还停留在旧模式。解决办法不是去改 build.gradle，而是直接切换到和工程模板匹配的指定 tag 版本。

第二个报错是：

text复制Flutter error resolving plugin [id: 'dev.flutter.flutter-plugin-loader', version: 'xxx']

这个一般是因为 pubspec.yaml 里某个依赖包调用了 flutter plugin loader，但这个插件在 OpenHarmony 侧没有对应的实现。我排查时逐个注释依赖，锁定到其中一个社区包只提供了 Android 和 iOS 实现。最后把那个包换成了纯 Dart 方案，问题消失。所以前面说“依赖能少用就少用”不是保守，是真机适配时最省时间的策略。

6.3 渲染与体验调优

Flutter for OpenHarmony 目前的渲染性能在 RK3568 上比我预想的要稳，但还是有几个明显的性能短板。首先是阴影和模糊效果，部分组件加了 BoxShadow 和 ImageFilter.blur 后，滑动列表能明显感觉到掉帧。我在练习页把所有阴影全部去掉，改用卡片边框，流畅度立刻提升。其次是页面切换动画，默认的 Material 页面切换动画在真机上有点拖沓，我改成了无动画跳转，交互反馈更干脆。

字体方面，OpenHarmony 系统的默认字体不存在某些字体族，如果代码里指定了 fontFamily: 'PingFang SC'，在真机上会显示不出中文。解决办法是去掉强制字体族，让系统自己回退。这个问题只在真机能复现，在 Android 模拟器上完全正常，排查时花了一些时间。

7. 关于“引擎与UI解耦”的一点总结建议

整个项目做下来，最值得保留的设计就是开头提的那条硬规矩：引擎目录下所有 Dart 文件禁止 import 任何 Flutter 相关的库。

早期我曾动过念头，想在引擎里直接调 debugPrint 打印日志，被自己拦住了。后来这个规矩救了我很多次。比如把引擎纯逻辑迁移到单元测试时，不需要起 Flutter 引擎；把引擎移植回 Android 原生项目或者用命令行脚本验证算式时，直接复用同一份代码。甚至将来如果想把引擎重写成 Rust 或 C++，老的 Dart 实现也能作为参考基准，因为它的纯逻辑部分完全没有被 UI 层污染。

如果让我重做一次，我会在第一天就把以下三件事列入计划：

• 给随机数生成器提供固定的随机种子，方便复现特定题目和 bug。这一点在真机调试时非常有用，否则同一个 bug 可能隔几次运行才出现一次。
• 把题目生成逻辑设计成可插拔模式，便于后续加入“卡诺图化简”“自然演绎推理”等进阶题型。
• 提前整理一份 OpenHarmony 适配的插件白名单，把所有依赖第三方原生插件的功能都挡在需求之外。

这个项目的核心价值从来不是“做出了一个 App”，而是验证了一条完整链路：用 Flutter 写纯 Dart 逻辑引擎，绑定 OpenHarmony 平台层，通过 hdc 部署到真实设备，整个过程中所有问题都能通过源码排查和版本锁定解决。想在这条路上入手的开发者，我建议你先把最小用例跑通，再开始写业务逻辑。工具链的坑解决得越早，后面写代码就越顺。