ArkTS “is not initialized” 崩溃排查指南：从深夜报警到5分钟定位 - InfoQ

ArkTS 应用线上因“is not initialized”崩溃，根因是模块循环依赖导致静态初始化块访问未完成初始化的变量。该问题在开发环境不易复现，但线上混淆后变量名不可读，加剧定位难度。
模块循环依赖触发ECMA规范下未完成模块的提前返回；静态块执行时机早于依赖模块初始化完成；混淆掩盖真实变量名，干扰日志分析。
适合ArkTS前端开发者、鸿蒙应用架构师、客户端稳定性工程师阅读。
本原创文章帖发布在华为开发者联盟社区，欢迎开发者前往访问评论交流，更多与该内容相关讨论，请点击原帖查看：ArkTS “is not initialized” 崩溃排查指南：从深夜报警到5分钟定位
变量名 z822 经过混淆，栈顶指向一个 .ets 文件的静态初始化块。你搜遍代码，找不到任何地方声明过 z822。明明在开发环境跑得好好的，为什么线上就崩了？
这不是代码逻辑错了，而是模块初始化顺序错了。
“XXX is not initialized” 的根本原因是模块间循环依赖，导致变量在被访问时尚未完成初始化。
ArkTS/ECMA 规范采用深度优先顺序加载模块。假设存在循环依赖 A → B → A，加载器会先标记 A 为 “加载中”，然后去加载 B；B 依赖 A 时发现 A 仍在加载中，直接返回未完成的 A 模块。此时若 B 中的全局代码或静态块立即使用了 A 的导出变量，该变量尚未赋值，就会触发 ReferenceError。
加载顺序为 B → A。B 的静态块执行时，A 的 a 还未赋值，崩溃发生。
本质问题：模块 / 类的职责边界不清、耦合度过高，导致初始化顺序冲突。静态块和顶层代码中的立即求值，是这条崩溃链上最常见的 “引信”。
复现问题后，日志中会额外输出模块加载链路信息。关闭开关的命令：
如果日志只显示 is not initialized，还看不到具体是哪条依赖链，可以进一步开启模块加载链路调试工具，崩溃日志中会新增 ModuleImportStack 字段，完整记录模块的调用路线。
栈顶是 B 模块，B 试图访问 A 模块的变量，链路清晰指向 A → B → A 的循环依赖。
DevEco Studio 内置了 @security/no-cycle 规则，专门用于禁止循环依赖。在工程根目录的 code-linter.json5 中配置：
然后在工程管理窗口中，右键工程根目录，选择 Code Linter > Full Linter 执行全量检查，直接定位所有循环依赖链路。
把共享的常量、类型、枚举抽到独立、无依赖的底层模块，让依赖关系形成 DAG（有向无环图）而非环。
ArkTS 支持在 import 语句中添加 lazy 关键字，模块在首次被使用时才加载。对于 “只在特定运行时场景才会触发” 的循环依赖，这是改动最小的方案。
这是案例中最直接的修复方式：把静态块中的依赖移到实例属性或构造函数中，实例化时依赖早已初始化完毕。
仅类型引用不产生运行时依赖，可以精确切断编译期的循环链路：
架构层面：底层模块（常量 / 类型 / 枚举）绝不依赖上层业务；工具类、单例模块禁止在顶层调用其他模块的实例方法。
CI 卡口：在流水线中强制执行 @security/no-cycle 检查，循环依赖直接失败。
开发设备验证：在开发设备上保持循环依赖检测开关常开，复现路径先于线上暴露问题。定位完成后及时关闭，避免持续影响运行时性能。
代码评审关注点：新增 import 时确认依赖方向；任何出现在顶层或静态块中的导入变量使用，都需要额外 scrutiny。
is not initialized 看起来是一个 “变量未赋值” 的问题，本质却是模块初始化顺序不可控。
真正的修复不是找到那个报错的变量然后给它一个默认值 —— 而是打开模块加载链路，看清哪条依赖形成了环，然后从设计层面把环拆掉。
设计层面：消除循环依赖，提取公共模块或使用依赖注入。
编码层面：延迟初始化，避免静态块 / 顶层立即使用导入变量。
工具层面：ESLint 卡口 + 运行时开关，开发态提前暴露。
🔗 官网开发者学堂视频：https://developer.huawei.com/consumer/cn/training/result?type2List=201783644516849879&orderBy=1&courseType=5
🔗 社区 DFX 专题文章： https://developer.huawei.com/consumer/cn/forum/subject/2101218731402391001