HarmonyOS 应用开发中，Native 层崩溃（CppCrash）是常见且排查成本较高的问题。一段崩溃日志通常包含信号、寄存器、数十层调用栈、内存映射、线程快照等内容，信息量大但有效线索提取困难：
信号描述的是故障机制，不等于代码根因：SIGSEGV 可能是空指针、UAF、越界写、栈溢出中的任意一种。
调用栈含大量运行时帧：libc、Ark Runtime、N-API 桥接层交织在业务代码中，根因帧不易辨识。
踩内存场景中崩溃点非第一现场：GC 线程、allocator、容器访问可能只是内存破坏后的延迟触发点。
同类崩溃分散出现：同一根因的问题可能以不同堆栈形态反复出现，逐条排查效率低。
APMS 智能分析界面已预置 AI 分析能力，将崩溃日志中堆栈、寄存器、内存映射等原始信息与问题聚类、变化趋势相结合，辅助开发者完成从问题发现到根因定位的完整排查流程。
APMS 智能分析界面提供问题聚类能力，将相同根因的崩溃自动聚合为同一问题组。散落在不同时间、不同设备上的崩溃记录被归纳为若干问题簇，便于判断哪些崩溃属于同一问题。
面对大量崩溃记录时，聚类视图帮助开发者优先处理影响面最广的问题组，而非逐条排查。
一、变化趋势：判断问题的时间特征
每个聚类问题配有变化趋势视图，按时间轴展示发生频次与影响设备数变化。通过趋势曲线可以判断：
问题是突发增长还是长期存量
是新版本引入还是历史遗留
修复后是否真正收敛
二、堆栈日志：提供分析所需的原始材料
在聚类和趋势视图定位到目标问题后，智能分析界面展示了每条崩溃记录的堆栈日志、寄存器信息、内存映射等原始数据。这些数据是根因分析的基础材料，但原始日志信息量大，人工从中提取有效线索需要较多经验。
界面中预置的AI 分析入口正是解决这一环节——将这些原始数据自动转化为结构化的根因分析报告。
三、AI 分析入口：从原始日志到根因报告
在智能分析界面中，选择目标崩溃记录后点击 AI 分析，系统自动加载该崩溃的堆栈日志、寄存器信息、内存映射等原始数据，启动 CppCrash 智能分析流程。
AI 分析采用"自动化提取 + 领域知识库 + 大模型推理"三层架构，完成从原始日志到根因报告的转化。
第一层：自动提取关键日志
内置 Python 脚本（仅依赖标准库）将原始日志转换为结构化数据：
脚本同时内置 16 条特征匹配规则，自动识别高频崩溃模式，包括：JS 堆 OOM、跨线程使用 JS 对象、N-API 野指针、libuv 异步任务生命周期、uv_close 异步语义误用、fd double close、GC 延迟崩溃、sqlite 文件页异常、C++未捕获异常等。
第二层：13 个领域知识库，按需加载
根据日志特征动态匹配，只加载相关的知识库内容：
第三层：证据链驱动的根因推理
基于提取的结构化数据和匹配的知识库，按流程建立证据链：
1. 调用栈三层分层：
2. 证据等级体系，避免单一线索误导：
检测器明确报告 > 指令/寄存器联合证据 > 多项栈特征 > 单一模块特征
四、典型场景：APMS 界面与 AI 分析的协同
以下是 APMS 界面功能与 AI 分析协同工作的一个典型流程：
第一步——趋势发现问题：APMS 变化趋势面板显示某应用在版本升级后某类崩溃量增长。
第二步——聚类归并问题：聚类分析将这批崩溃归为同一问题组，故障线程均为OS_GC_Thread，栈顶只有 GC 标记阶段帧。
第三步——AI 分析定位根因：在智能分析界面中选择该问题组的崩溃记录，点击 AI 分析。特征匹配规则识别出这是 GC 延迟崩溃模式——对象在更早时刻已被破坏，GC 在标记阶段访问到非法对象才触发崩溃。报告提示：
GC 并发标记阶段访问异常：故障线程只有 GC/Runtime 帧，通常是更早发生的对象内存破坏在 GC 阶段延迟爆炸；不应默认归因于 GC 自身，优先排查跨线程 env，并用线程检测或代码路径确认第一现场。
第四步——趋势验证修复：结合趋势面板中该问题与版本发布时间的相关性，开发者将排查方向聚焦到新版本中的跨线程 N-API 调用路径。修复后通过趋势曲线观察该聚类问题是否收敛。
整个过程从趋势发现问题、聚类归并问题、AI 分析定位根因，再到趋势验证修复，APMS 界面的全局视图与 AI 分析的单条深入分析形成配合。
五、AI 分析报告样例
六、分析报告输出
AI 分析输出两种报告模板，根据场景自动选择：
模板 A（常规场景）：包含故障基本信息、三级根因定位（CPP_CRASH → 信号 → si_code）、完整证据链、直接原因与深层原因、根因模块定界、修复建议。
模板 B（踩内存场景）：标注为“踩内存第 2 现场”，不强行归因，给出 GWP-ASan 和 HWASan 的下一步检测建议，引导获取第一现场证据。
七、核心设计原则
1. 先提取事实，再匹配模式——不得用单个栈帧直接推导深层根因；
2. 区分崩溃点与根因点——系统运行时帧不等于业务根因；
3. 区分第一现场与延迟崩溃——GC、allocator 栈可能只是触发点；
4. .so 路径辅助但不单独证明责任——/data/路径表示产物位置，责任仍需结合入参和生命周期确认。
八、使用方式
在 APMS 智能分析界面中，通过问题聚类定位目标问题组，借助变化趋势判断问题时间特征，选择具体崩溃记录后点击 AI 分析入口，即可获得结构化的根因分析报告。修复后通过趋势曲线观察问题是否收敛，形成从发现到修复的闭环。
