Flutter AOT 算错但 JIT 正常，怎么排查？

先固定输入，再比较计算边界：在同一设备、同一输入下分别运行 Debug/JIT 和 Release/AOT，分别记录计算函数返回前的原始值、格式化前的值和最终展示值。只有原始计算结果不同，才继续排查数值类型、运算顺序、依赖和 SDK；如果原始值一致，问题就在格式化、截断或 UI 展示链路。

JIT 正常而 AOT 异常，只能说明两种构建暴露了不同的代码路径，不能直接判定为编译器 Bug。掘金热帖记录了这种现象，但没有给出足以确认根因的完整代码和最小用例，因此适合作为复现线索，不能代替实际验证。开发模式使用 JIT 支持热重载，发布模式使用 AOT，两者可以作为排查对照，但并不是完全相同的执行路径。

先把差异缩到计算边界

排查时先保持同一份源码、同一份依赖锁文件和同一个目标设备。远程接口、当前时间、随机数、配置服务、功能开关等变量，都应替换成固定的本地输入，或者保存两份构建收到的数据快照再逐字段比较。

先记录环境和构建信息，再分别运行：

flutter --version
flutter pub deps
flutter run --debug
flutter run --release

如果有可单独测试的计算函数，再补一项功能测试：

flutter test test/calculation_test.dart

不要只比较两个页面截图。截图最多能说明展示结果不同，不能说明错误发生在计算内部还是格式化阶段。应在计算函数返回处记录原始值，在格式化函数入口记录同一个值，在 UI 展示前再记录一次。原始值已经不同，就继续查计算；原始值相同，就转查 toString、精度设置、取整、截断和组件状态。

换设备、换系统，或从原生 Release 切换到 Flutter Web，会额外引入架构和运行时差异。Flutter 既可以输出 ARM 或 Intel 机器码，也可以编译为 JavaScript，因此不能用 Web 结果直接推断原生 AOT 的行为。

重点核对数值和累加顺序

对数据进入计算函数、进入累加器和离开计算函数这几个边界，逐一核对 int、double 和 num 的每次边界转换。不要只看最终变量的声明类型，中间值里的隐式转换、精度丢失或量纲变化也可能改变结果。

除法、取整和整数转换要单独检查。确认代码里使用的除法、截断取整和四舍五入方法是否与业务预期一致，并检查固定范围整数、浮点转整数以及中间累计值是否发生截断或溢出。不要把这些行为留给类型推断决定，因为最终类型正确，不代表中间每一步都正确。

如果计算结果是多个数值的累计，还要比较运算顺序。浮点数连续累计时，不同分组可能得到不同末位；a + b + c 与 a + (b + c) 也不能假定完全等价。先固定顺序记录中间值，再判断偏差来自具体哪一次运算。

结果由 Map 或 Set 聚合得到时，先输出参与计算的键和值，再按稳定键排序后重新计算。业务结果不应依赖未由代码明确约定的遍历顺序，尤其是在浮点累计、求最值位置或先取模后聚合的场景中。

排除代码路径和展示干扰

如果 Debug 和 Release 读取了不同的配置、远程数据或功能开关，应先固定这些输入。还要检查必要逻辑是否放在仅 Debug 生效的 assert 或调试分支中，并确认两次构建使用同一份 pubspec.lock，且依赖解析结果一致。若异步任务或 isolate 可能返回旧结果，应给请求附加标识和序号，在接收端拒绝过期结果。

如果原始计算值一致而页面值不同，就不再追查数值类型和累加顺序，改查格式化精度、截断方式、区域设置以及 UI 是否拿到了旧状态，避免把展示问题误报成 AOT 编译问题。

最小复现后再判断 SDK

flutter test 可以验证纯函数在测试环境中的行为，但不能代替原生 Release/AOT 的最终验证。测试通过而 Release 仍稳定出错时，保留最小输入，同时核对 Flutter 版本、目标平台和依赖锁文件，并对照其他受支持目标上的表现。Flutter 官方安装文档提供了 stable 渠道更新、安装与开发环境排障路径，可用于建立干净环境进行对照验证。

如果失败发生在构建阶段，而非 Release 安装后的运行阶段，应停止追踪计算结果，转查 AOT 编译异常。泛型或反射兼容、第三方库集成、元数据生成失败等问题，与本文讨论的“构建成功但结果错误”不是同一类故障。

整理最小复现时，应记录固定输入、预期结果、Debug 与 Release 的原始计算值、格式化后的值、运行命令、Flutter 版本、pubspec.lock 和目标平台。具备这些信息后，才能准确区分问题出在业务实现、依赖版本还是 Flutter/Dart 编译器，而不是继续凭现象猜测。