夜雨聆风五层根因分析法（L1-L5 分层归因法）
这是一种从现象出发，层层下钻直至系统性根因的结构化归因模型。其核心目的是防止分析止步于技术修复，强制将问题追溯到可落地的流程与机制缺陷。
---
模型核心架构
该方法将一次完整的问题分析，强制分解为五个逐层递进的归因层次。每一层均有明确的核心追问、探查对象与概念边界，且前一层的输出构成后一层的输入。
---
L1 现象层 — 界定异常
以可观测、可复现的视角，对所发生的异常事件进行纯粹的事实性描述，剥离一切推断、猜测与归因。
· 判定标准：该描述可由不同观察者在相同条件下独立确认，具备主体间一致性。异常是软件产品在运行或使用过程中表现出的、偏离需求规约或用户合理预期的任何状况。
· 输出：一个或多个可复现的异常，构成分析的客观起点。
---
L2 路径层 — 判定执行断点
以综合了操作序列、调用链、控制流三个层面的预期执行流作为基线，逐项比对系统实际记录的执行轨迹，从中识别并标定出首个不一致的位置，即执行断点。
· 判定标准：执行断点的标定，必须基于对正常路径的完整理解。不一致的含义指执行流在该位置发生了结构性中断、跳转或终止，而非参数值或返回结果的细微偏差。
· 输出：一个精确的执行断点位置，为下一层的状态检查划定范围。
---
L3 状态层 — 识别错误状态
在L2所标定的执行断点处，对相关运行时实体逐一核验，从中识别出实际值与设计规约所定义的预期值不符的那个承载者，即错误状态。
· 判定标准：错误状态的承载者是变量、配置项、数据字段、内存结构、资源句柄等可被检测的运行时实体。识别依据是该实体的实际取值或存在形式，偏离了设计规约所定义的正常范围或期望，导致系统功能无法继续按预期执行。
· 输出：一个或多个被精确指认的错误状态，构成逻辑层分析的直接对象。
---
L4 逻辑层 — 揭示逻辑缺陷
以L3所识别的错误状态为输入，对产生该状态或对该状态进行处理的控制代码、算法或设计规则进行分析，从中揭示导致错误状态产生或使其未被正确应对的逻辑缺陷。
· 判定标准：逻辑缺陷的形态包括但不限于：分支条件遗漏、边界情况未处理、并发竞争保护缺失、参数合法性校验不足、错误处理路径不完备、设计约束未被满足。分析必须定位到具体的代码语句、逻辑结构或设计决策。
· 输出：一个或多个被精确指认的逻辑缺陷，构成元因层追溯的直接对象。
---
L5 元因层 — 追溯过程缺口
以L4所揭示的逻辑缺陷为线索，从组织的过程体系出发，追溯允许该逻辑缺陷被引入、通过各层验证环节并最终逃逸至生产环境的过程缺失，即过程缺口。
· 判定标准：过程缺口存在于过程定义、过程实施、过程验证、过程管理等环节。其形态包括三类：
· 预防性缺口：本应在缺陷引入之前或引入时即阻止其发生的活动缺失或失效，对应 FMEA 中的预防控制，如设计评审未覆盖特定约束、编码规范未定义相关规则；
· 检测性缺口：本应在缺陷引入后将其发现的活动缺失或失效，对应 FMEA 中的探测控制，如自动化测试用例未覆盖对应场景、静态分析规则未配置；
· 阻断性缺口：已发现的不符合项或风险项，其拦截与放行机制缺失或未强制执行，导致缺陷仍被合入或发布。
追问的核心是“是什么允许了这个缺陷发生、存续并最终逃逸”，而非缺陷本身。
· 输出：一个或多个被精确指认的过程缺口，是组织层面可改进、可度量的过程改进项。
---
核心价值
· 阻断过早归因：强制分析不能停在表象或直接原因（L1-L3），必须触达逻辑与机制根因（L4-L5）。
· 区分原因性质：明确哪些是直接触发原因，哪个是允许其发生的系统性根因。
· 产出系统性改进：修复不再只是“改代码”，而是“补充自动化用例”“更新评审检查清单”等可复用、可预防的行动。
---
适用场景
· 多组件、跨模块的复杂系统故障复盘。
· 需要跨团队协作归因的疑难问题。
· 旨在推动流程与质量体系改进的线上事故定级。
---
应用步骤
1. 还原现场：收集客观事实，清晰定义 L1。
2. 追踪链路：绘制正常流程，对比异常日志，定位 L2 中断点。
3. 校验状态：检查中断点处的变量与配置，锁定 L3 错误状态。
4. 审视逻辑：深入代码或设计，追问“为何在此状态下出错”，得出 L4。
5. 追问流程：用“5 Whys”等方法追问“为何未被发现”，提炼出 L5 元因。
---
案例演示
问题定义：多屏/分屏场景下，软键盘无法弹出的系统级缺陷
L1 现象
· 在多屏或分屏设备上，点击输入框后，输入法键盘没有弹出。
L2 路径
· App 调用 showSoftInput() → InputMethodManager → InputMethodManagerService（IMMS）。调用链在 IMMS 内部中断，后续显示逻辑未执行。
L3 状态
· 存在两个关键状态异常：
1. focusedWindowToken（当前焦点窗口令牌）为 null。
2. 请求携带的 displayId（屏幕ID）与输入法服务实例绑定的屏幕ID不匹配。
L4 逻辑
· InputMethodManagerService.java 中的 getEnabledInputMethodListLocked 方法，在选择或匹配输入法时，未对分屏下的 displayId 做区分处理。导致多屏场景下，输入法服务实例无法正确关联到请求的屏幕和窗口。
L5 元因
· 多屏/分屏交互的自动化测试用例缺失；代码评审（Code Review）检查项未覆盖多屏幕适配场景。
---
诊断结论与修复方案
· 直接原因（L2-L4）：AOSP（Android 开源项目）的输入法管理服务，在多窗口、多屏幕的状态管理和逻辑分支上存在适配缺陷。
· 根本原因（L5）：研发与测试流程未针对多屏硬件特性建立对应的质量保障机制。
修复措施：
· 治标（修逻辑）：在 getEnabledInputMethodListLocked 等方法中，增加基于 displayId 的区分与匹配逻辑。
· 治本（建机制）：补充多屏/分屏交互的自动化测试用例；在代码评审规范中，将“多屏幕/多窗口适配”设为强制检查项。
---
这本质上是一个AOSP层级的系统适配缺陷，暴露了多屏生态下输入法框架在多窗口焦点管理和屏幕关联上的设计不足。
