模块技术选择目的输出模型Pydantic BaseModel + index 字段保证结果对齐LLM 框架结构化 prompts 管理输出格式手动 JSON 提示 + 3 层解析兼容无 response_format 的 API错误处理3 次重试 + 错误回传自愈性提高至接近 100%分批策略每批 50 条平衡准确率与 API 调用成本不假设 LLM 的行为是完美的。

组件变更内容工厂 + 两套 SQL 查询6 个收入相关新字段测试新增 3 笔收入账单（工资/还款/劳务）Dart 反序列化对齐新字段双折线趋势图 + 绿色收入饼图一个维度的数据不足以做判断。只有支出没有收入，用户看到的是一串"花多少钱"的数字，但无法感知这些钱在自己收入中的占比。当收入饼图出现"工资收入"占比 90% 时，用户意识到自己对单一收入来源的依赖——这是数据驱动的理财意识的第一步。

组件角色关键设计跨层接口约定Android 事件发射器object 单例，全局可访问事件源生命周期钩子中嵌入通知生成的*.g.dart自动代码Pigeon 编译时生成 Stream 包装事件消费者StreamSubscription + dispose 清理把"状态查询"转变为"状态订阅"。传统的做法会让 UI 层反复轮询，不仅浪费电量，还有延迟窗口。事件流的模式让通知延迟为零，且资源开销与事件频

方面旧方案（UUID 映射）新方案（retryTimes）代码行数176 行69 行（-61%）状态管理外部映射表内嵌重试逻辑遍历映射表批量重试单个请求直接重试辅助类型数据类无需额外类型可调试性UUID 无意义retryTimes直接可读这个重构的收益远不止代码量的减少——消除了全局状态的复杂度是最大的胜利。旧的映射表方案在并发场景下容易出现竞态条件（如刷新完成前就有新请求加入映射表），而新方案中

解析代码有点多，我们这里仅口述一下解析逻辑：首先找到 describeContent 为“支付成功”的 ViewGroup 节点，然后获取该节点父节点的父节点 parent，然后通过递归算法，以 parent 为根，把所有找到的节点中的文本都加入一个中，通过解析这个 List 来实现支付具体信息的识别（收款对象、收款金额、支付场景等等）

可以看到，在上述图片中，当一个标题下有多个设置项时，我们会把它们“贴合在一起”，每个设置项的接触处是没有圆角的，仅在整体的四个角有圆角，要实现这一点，就需要一个父组件来统一设置、管理圆角，不仅如此，整个设置项组外围的阴影、每个设置项之间的分割线等等也需要一个统一的父组件来管理，这就是编写设置项组的必要性。我们根据当前是否具有对应的权限来展示不同的设置项 tail，如果有权限就展示一个被禁用的按钮，

overrideappBar: AppBar(title: Text("记账")),});},),// 省略...),),),),],index,},),由于具体的页面还未实现，所以在_page 列表中，我们创建了四个 Placeholder 来占位，将_pages 列表和_pageController 传入PageView 中，并传入一个回调函数，当页码有更新时，同步更新我们维护的_curren

可以看到，在上述图片中，当一个标题下有多个设置项时，我们会把它们“贴合在一起”，每个设置项的接触处是没有圆角的，仅在整体的四个角有圆角，要实现这一点，就需要一个父组件来统一设置、管理圆角，不仅如此，整个设置项组外围的阴影、每个设置项之间的分割线等等也需要一个统一的父组件来管理，这就是编写设置项组的必要性。我们根据当前是否具有对应的权限来展示不同的设置项 tail，如果有权限就展示一个被禁用的按钮，

overrideappBar: AppBar(title: Text("记账")),});},),// 省略...),),),),],index,},),由于具体的页面还未实现，所以在_page 列表中，我们创建了四个 Placeholder 来占位，将_pages 列表和_pageController 传入PageView 中，并传入一个回调函数，当页码有更新时，同步更新我们维护的_curren

只是还有一个地方需要注意，在requestOverlayPermission中，我们在调用setOverlayPermissionCallback时，需要在传入的回调函数最后再次调用setOverlayPermissionCallback并将回调函数设为 null，这是因为与 Flutter 层通信的 callback 必须调用且仅调用一次，如果不取消回调，那么可能会多次调用或者使 MainAct