Flutter K线系统拆解（一）：架构分层与领域模型

K 线在 demo 阶段通常不难，难的是进入真实交易场景之后的长期维护。
一旦业务进入高频迭代，常见问题很快会暴露出来：主题体系耦合、模式分支散落、改动范围不可控、扩展成本越来越高。

这一篇只讲架构层面的核心问题：
如何把 K 线从“能画出来的组件”做成“可长期演进的系统”。

一、推荐的系统分层

一套可维护的 K 线实现，通常至少要有这几层：

入口与装配层：图表 widget 生命周期与运行时状态
SDK 抽象层：主题、国际化、事件、屏幕适配等外部能力
数据与指标层：行情实体、指标结果、计算引擎
渲染核心层：坐标、可视区、渲染器管理
渲染阶段层：背景/网格/主图/十字线/叠加层等阶段化执行
策略扩展层：现货、合约等模式差异封装
工具叠加层：订单标记、绘图工具、信息浮层

分层的价值不在“看起来规范”，而在于改动隔离：
新增一个能力时，只需要改对应层，不会把整个系统拖下水。

二、外部依赖必须 SDK 化

K 线内核不要直接依赖宿主 App 的具体实现。
主题、国际化、事件总线、屏幕适配都应该通过接口注入。

推荐模式：

• 内核只依赖抽象接口
• 适配层负责把宿主能力映射为接口实现
• 页面层只负责装配，不写业务细节

这样做的直接收益是：

• 内核可复用，迁移成本低
• 单元测试可替换依赖
• 多项目接入时不会复制粘贴一堆 if/else

三、运行时状态要聚焦在“图表本身”

入口层状态建议只保留图表运行必需信息：

• 缩放与滚动
• 当前选中点
• 手势状态（拖拽/缩放/长按）
• 可见区边界与回弹信息

经验上最容易失控的是“把业务状态也塞进图表状态”。
一旦这样做，重建范围和排查复杂度都会快速上升。

四、领域模型要服务渲染链路

交易图表的实体模型不应只保存原始行情。
更实用的做法是把指标结果一并回填到数据实体，渲染阶段直接消费。

核心原则：

• 计算层写结果，渲染层只读结果
• 新数据优先增量更新，不做全量重算
• 展示格式化与数值计算分离

五、模式差异必须集中管理

现货和合约的差异通常会出现在：

• 是否显示成交量/副图
• 折线与蜡烛模式规则
• 时间对齐策略
• 日期与轴标签参数

这些差异应集中在策略层统一处理，不应该散落在渲染阶段和手势分支里。
一旦差异点分散，后续新增模式会持续放大维护成本。

总结

K 线架构的本质不是“把代码拆成多个目录”，而是控制复杂度传播。
只要把依赖注入、状态边界、领域模型、模式策略这四个点做稳，后面无论加功能还是做性能优化，都会顺很多。