最近在做一款基于Flutter的移动数据使用监管助手App目标平台是OpenHarmony。说实话这个组合放到一年前还有点冷门Flutter官方并没有直接支持OpenHarmony需要借助社区适配工具链才能跑起来。真正动手之后发现工作量比想象中大但也没那么神秘。尤其是套餐历史这个模块——它涉及系统流量数据采集、周期重算、本地缓存、图表展示牵扯到的技术点很杂踩坑也最多。这篇文章就把套餐历史从需求拆解到落地实现的全过程复盘一遍给打算在OpenHarmony上用Flutter做工具类应用的朋友一个可参考的实例。文章会按这个思路展开先讲清楚为什么选Flutter来开发OpenHarmony应用再分析套餐历史模块怎么做业务拆解和数据建模然后落到实际的UI实现、状态管理、数据持久化与图表方案最后是实操中遇到的典型问题与排查过程。内容偏工程向所有代码写法都是基于我在真机调试中验证过的方案尽量做到拿来就能用。1. 项目背景与整体架构1.1 为什么用Flutter开发OpenHarmony应用先说一个很多人都会问的问题OpenHarmony明明有自己的ArkUI框架为什么还要折腾Flutter核心原因只有一个业务复用。我之前已经有完整的Flutter应用代码库App内的流量监管逻辑、UI组件、状态管理方案都是现成的。如果改用ArkUI重新写一遍成本至少翻一倍。用Flutter跑在OpenHarmony上等于把已有的开发效率和生态红利直接带过来。从技术角度看OpenHarmony社区维护了一整套Flutter适配分支包括flutter_flutterframework、flutter_engine引擎、flutter_packages插件仓库整体思路跟Flutter官方架构保持一致。Dart层的代码几乎不用改真正需要适配的是平台通道——也就是调用系统能力的那部分比如流量统计接口需要通过MethodChannel桥接到OpenHarmony原生侧用ArkTS或C实现。这个方案的实际体验是Flutter层代码跨平台复用在九成以上只有依赖系统API的功能才需要做平台适配。对移动数据监管这种重业务、轻系统的工具类App来说性价比极高。1.2 产品形态与功能范围移动数据使用监管助手App本质上是一个帮你盯住手机流量消耗的工具。它需要解决几个核心问题展示当前套餐周期内已用流量、剩余流量、日均消耗按天记录流量使用情况形成历史趋势支持自定义套餐周期比如每月1号重置或按开卡日重置能回溯往期套餐的使用情况方便对比和复盘套餐历史模块在整个App里的定位很清晰它承担所有“过去的数据”。用户不仅关心这月用了多少更关心上个月、上上个月用了多少想知道自己每个月的用量规律进而选择合适的套餐。整个模块可以拆成“每日用量列表 月度汇总 周期趋势图”三个子功能。1.3 与技术选型相关的几个关键决策在正式动手前有几项技术选型需要提前拍板它们直接决定后面开发的复杂程度数据来源OpenHarmony系统没有类似Android的TrafficStats全局流量统计接口需要读取系统网络管理服务提供的数据或者通过数据流量统计服务获取。不同版本API存在差异这块是项目里最不确定的点。本地存储方案历史数据量会持续增长必须设计持久化方案。这里选了sqflite它在OpenHarmony适配分支上可用SQL语法完全兼容。状态管理用了Provider理由很简单——历史模块的状态并不复杂用Bloc或者Riverpod会引入过多样板代码。Provider搭配ChangeNotifier足够支撑套餐历史页面的数据流转。图表方案优先考虑纯Dart实现因为任何依赖原生View的图表库都需要重新适配OpenHarmony。fl_chart完全用CustomPainter绘制天然跨平台成为首选。2. 套餐历史业务拆解与数据模型设计2.1 核心业务需求深度拆解套餐历史在需求层面看起来简单——把每个月的流量使用情况列出来就行。但一落回到细节就会发现很多“魔鬼”藏在角落里套餐周期的判定不能简单按自然月计算。有的套餐是每月1号重置有的是按开卡日期比如每月15号重置还有的按周结算。周期起算日不同历史统计的聚合维度就完全不同。重置时刻的处理流量统计在重置瞬间需要清零但系统流量计数器在不同事件重启、飞行模式切换、SIM卡更换下都可能产生偏差需要与本地缓存做校准。历史数据的完整性用户可能会跨越几个月查看历史如果中间有一段数据因为设备关机没有采集到UI上需要明确体现数据缺失而不是直接给个错误的总量。在设计阶段我把套餐历史拆成了三个子模块分别对应三类用户场景场景用户诉求功能落点查看当前用量本月还剩多少流量周期内汇总卡片历史回看上个月用了多少月度列表与筛选趋势分析哪几天用得多、日均增速周期内每日趋势图2.2 数据模型设计数据模型是整个模块的地基我定义了三个核心实体类/// 套餐计划 class PackagePlan { final String id; final String name; // 套餐名称例如“畅享39元套餐” final int totalBytes; // 套餐总量单位字节 final int cycleStartDay; // 结算周期起始日1-280表示每天重置 final String cycleType; // resetType: month / week / day final DateTime startTime; // 套餐生效时间 final DateTime? endTime; // 套餐失效时间null表示长期有效 } /// 单日用量记录 class UsageRecord { final String id; // 主键例如 2025-01-15 final DateTime date; // 当天日期 final int usedBytes; // 当日已用流量单位字节 final int packageId; // 归属套餐ID final int networkType; // 0移动数据1Wi-Fi2总计 final DateTime createdAt; // 记录创建时间 final DateTime updatedAt; // 记录更新时间 } /// 月度汇总视图查询结果不落库 class MonthlySummary { final String month; // 2025-01 final int totalBytes; // 月度总用量 final int dailyAverage; // 日均用量 final int maxDayBytes; // 单日峰值 final DateTime maxDay; // 峰值日期 final int daysRecorded; // 有记录的天数 }这里有个设计细节值得说明UsageRecord里加了networkType字段。因为系统统计的流量数据除了移动数据还可能包含Wi-Fi流量而套餐历史只关心移动数据用量。如果不区分类型最后统计出的数据一定会被用户质疑为“不准”。2.3 手动计算套餐周期的工具类套餐周期不能按自然月硬算需要用工具类动态计算某一天属于哪个套餐周期。这块逻辑我单独抽了一个工具文件核心方法如下class PackageCycleUtil { /// 计算某个日期所属的套餐周期起始日 static DateTime cycleStartFor(DateTime date, PackagePlan plan) { final day plan.cycleStartDay; final month date.month; final year date.year; DateTime cycleStart; if (day date.day) { // 今天还没到重置日说明周期从本月起始日开始 cycleStart DateTime(year, month, day); } else { // 今天已经过了重置日回到上一个月的重置日 final prevMonth DateTime(year, month - 1, 1); cycleStart DateTime(prevMonth.year, prevMonth.month, day); } // 处理特殊月份有些月份没有31号需要回退到月末 final daysInMonth DateTime(cycleStart.year, cycleStart.month 1, 0).day; if (cycleStart.day daysInMonth) { cycleStart DateTime(cycleStart.year, cycleStart.month, daysInMonth); } return cycleStart; } /// 计算套餐周期内的日期集合 static ListDateTime daysInCycle(DateTime cycleStart, PackagePlan plan) { final nextStart _nextCycleStart(cycleStart, plan); final days DateTime[]; var cursor cycleStart; while (cursor.isBefore(nextStart)) { days.add(cursor); cursor cursor.add(const Duration(days: 1)); } return days; } static DateTime _nextCycleStart(DateTime currentStart, PackagePlan plan) { if (plan.cycleType month) { return cycleStartFor( DateTime(currentStart.year, currentStart.month 1, currentStart.day), plan, ); } // 按周就简单很多 return currentStart.add(const Duration(days: 7)); } }这套计算逻辑在遇到“2月没有29号”“跨年重置”这些边界条件时能保持正确实测在真机上跑没有出现周期错乱。3. 数据采集与平台通道适配3.1 系统流量数据获取的几个途径OpenHarmony的设备数据获取和Android不完全一样。Android的TrafficStats是公开稳定的APIOpenHarmony这边则需要根据系统版本选择不同的接口。我在实现时主要走了两条路一种是调用系统ohos.net.netmanager或数据统计相关接口获取接口级别的收发字节数。另一种是读取系统数据库或系统服务中的流量统计记录这种方式数据更完整但权限要求更高。考虑到生产环境的稳定性我最终采用的是“系统接口 增量计算 本地校准”的组合策略。每次采集先获取当前累计收发值然后与本地保存的上一次采集值做差得出该时间段内的新增流量。3.2 平台通道的封装实现Flutter层通过MethodChannel与OpenHarmony原生侧通信通道名定义和调用代码如下import package:flutter/services.dart; class TrafficDataChannel { static const _channel MethodChannel(com.example.data_guard/traffic); /// 获取当前移动网络累计接收字节数 static Futureint getMobileRxBytes() async { try { final result await _channel.invokeMethodint(getMobileRxBytes); return result ?? 0; } on PlatformException catch (e) { debugPrint(获取下行流量失败: ${e.message}); return 0; } } /// 获取当前移动网络累计发送字节数 static Futureint getMobileTxBytes() async { try { final result await _channel.invokeMethodint(getMobileTxBytes); return result ?? 0; } on PlatformException catch (e) { debugPrint(获取上行流量失败: ${e.message}); return 0; } } }原生侧的实现逻辑需要读系统网络管理服务。这里要注意OpenHarmony的接口调用是异步的需要把结果通过success回调返回给Flutter侧不能直接在同步代码块里返回数据。我第一次写的时候在这里吃过亏导致Flutter侧永远拿到null。3.3 定时采集与增量计算采集策略我设计成三层启动时全量采集 前台每10分钟增量采集 关键事件触发采集。关键事件包括应用从后台切回前台、日期变化跨天、系统网络状态变化。class TrafficCollector { Timer? _timer; int _lastRxBytes 0; int _lastTxBytes 0; void startCollecting() { _timer?.cancel(); _timer Timer.periodic(const Duration(minutes: 10), (_) { _collectAndSave(); }); } Futurevoid _collectAndSave() async { final rx await TrafficDataChannel.getMobileRxBytes(); final tx await TrafficDataChannel.getMobileTxBytes(); final now DateTime.now(); // 增量计算注意处理计数器重置系统重启等情况 int deltaRx rx - _lastRxBytes; int deltaTx tx - _lastTxBytes; if (deltaRx 0 || deltaTx 0) { // 计数器重置说明设备重启过丢弃本次增量并重置基准值 _lastRxBytes rx; _lastTxBytes tx; return; } _lastRxBytes rx; _lastTxBytes tx; if (deltaRx deltaTx 0) return; // 写入本地数据库 await _cacheRepository.appendUsage( date: now, usedBytes: deltaRx deltaTx, networkType: 0, ); } }这里有个很重要的边界处理系统流量计数器在设备重启后会清零这时候增量计算会出现负值。如果直接存库会把历史数据全部污染掉必须识别出计数器重置场景并丢批次更新基准值。这个坑我是真机测试时发现的不处理的话一天的数据能差出好几个G。3.4 与应用生命周期联动采集器不能做“孤儿”操作必须跟App的生命周期绑定。我在main.dart里通过WidgetsBindingObserver监听应用前后台状态确保采集不会在后台频繁发起无效请求也不会在进程被杀后丢失状态。class AppLifecycleObserver with WidgetsBindingObserver { override void didChangeAppLifecycleState(AppLifecycleState state) { switch (state) { case AppLifecycleState.resumed: // 回到前台立即补采一次并刷新UI TrafficCollector.instance.collectNow(); break; case AppLifecycleState.paused: // 退到后台停止定时采集避免无谓耗电 TrafficCollector.instance.stopCollecting(); break; default: break; } } }实测下来这套联动策略能保证数据不丢同时电量消耗也控制在可接受范围内。4. 套餐历史页面UI实现与状态管理4.1 页面整体结构与交互设计套餐历史的UI最终采用上下两段式布局上半部分当前周期概览区展示套餐总量、已用量、剩余量、周期起止日期以及一个可视化的环形进度条用来直观呈现套餐消耗比例。下半部分历史记录区用列表方式展示“每日用量 月度汇总”顶部支持月份切换底部是趋势折线图展示选定周期内每天的流量变化。整个页面基于CustomScrollView进行滚动管理好处是概览区可以跟随内容一起滚动又能在视觉上悬浮收缩体验更贴近系统设置类页面的质感。页面代码结构大致如下class HistoryPage extends StatelessWidget { const HistoryPage({super.key}); override Widget build(BuildContext context) { return ConsumerUsageHistoryModel( builder: (context, model, child) { return CustomScrollView( slivers: [ SliverAppBar( title: const Text(套餐历史), pinned: true, expandedHeight: 220, flexibleSpace: FlexibleSpaceBar( background: _PackageSummaryCard( summary: model.currentSummary, plan: model.currentPlan, ), ), ), SliverPersistentHeader( pinned: true, delegate: _MonthSelectorDelegate( monthList: model.monthList, selectedMonth: model.selectedMonth, onMonthChanged: model.switchMonth, ), ), SliverList( delegate: SliverChildBuilderDelegate( (context, index) { final record model.dailyRecords[index]; return _DailyUsageTile(record: record); }, childCount: model.dailyRecords.length, ), ), SliverToBoxAdapter( child: _TrendChart( data: model.trendData, cycleStart: model.currentCycleStart, cycleEnd: model.currentCycleEnd, ), ), ], ); }, ); } }4.2 状态管理Provider ChangeNotifier套餐历史模块的数据流不算复杂用ChangeNotifier管理就够了。设计了一个UsageHistoryModel负责统筹套餐计划、当月汇总、每日记录、趋势数据四个子状态。class UsageHistoryModel extends ChangeNotifier { final UsageRepository _repository; final PackagePlan? currentPlan; ListUsageRecord dailyRecords []; MonthlySummary? currentSummary; ListMonthlySummary monthList []; DateTime selectedMonth; UsageHistoryModel(this._repository, this.currentPlan) : selectedMonth DateTime.now(); /// 加载指定月份的历史记录 Futurevoid loadMonth(DateTime month) async { selectedMonth DateTime(month.year, month.month); // 先算周期根据套餐重置日定位该月所有周期 final cycleStarts _computeCycleStartsInMonth(month, currentPlan); // 拉取数据库记录 final records await _repository.getRecordsBetween( start: cycleStarts.first, end: cycleStarts.last.add(const Duration(days: 1)), ); // 按天聚合 dailyRecords _aggregateByDay(records); // 计算月度汇总 currentSummary _buildSummary(month, cycleStarts, records); notifyListeners(); } /// 计算某个月份内涉及的周期起始列表 ListDateTime _computeCycleStartsInMonth(DateTime month, PackagePlan? plan) { // 这里调用 PackageCycleUtil.cycleStartFor 逐个日期推算 } }这里的关键点在于一个自然月内可能跨两个套餐周期比如周期起始日是15号所以不能仅用自然月去聚合数据必须先算出该月内所有周期的起始日再分别拉取与统计。这一点也是整个模块最容易算错的地方。4.3 日均与峰值的计算逻辑月度汇总的日均值和峰值计算不是简单的平均值和最大值需要考虑数据缺失的场景。如果某天没有记录那就不该计入日均的分子也不该参与峰值比较。对应的代码片段MonthlySummary _buildSummary( DateTime month, ListDateTime cycleStarts, ListUsageRecord records, ) { final totalBytes records.foldint(0, (sum, r) sum r.usedBytes); final daysRecorded records.map((r) r.date.day).toSet().length; final summary MonthlySummary( month: ${month.year}-${month.month.toString().padLeft(2, 0)}, totalBytes: totalBytes, dailyAverage: daysRecorded 0 ? 0 : (totalBytes / daysRecorded).round(), maxDayBytes: records.isEmpty ? 0 : records.map((r) r.usedBytes).reduce(max), maxDay: records.isEmpty ? month : records.reduce((a, b) a.usedBytes b.usedBytes ? a : b).date, daysRecorded: daysRecorded, ); return summary; }这段逻辑看上去不复杂但如果漏掉daysRecorded这个字段后面做图表时会发现数据不足的天也画成了0视觉上产生很奇怪的“低谷”用户会误以为那天断网了。记录天数的目的就是为了在图表上区分“真实0”和“无数据”。4.4 日期筛选与月份切换月份切换我使用了一个SliverPersistentHeader吸顶显示一对左右箭头中间是当前选中的月份。切换时触发loadMonth重新拉数据因为数据量不大一个月最多31条记录不需要做复杂的分页缓存直接全量查询加内存缓存就够了。class _MonthSelectorDelegate extends SliverPersistentHeaderDelegate { override Widget build( BuildContext context, double shrinkOffset, bool overlapsContent, ) { return Material( color: Theme.of(context).scaffoldBackgroundColor, child: Row( mainAxisAlignment: MainAxisAlignment.spaceBetween, children: [ IconButton( icon: const Icon(Icons.chevron_left), onPressed: _canGoPrev ? () onMonthChanged(selectedMonth.subtract(const Duration(days: 1))) : null, ), Text(${selectedMonth.year}年${selectedMonth.month}月), IconButton( icon: const Icon(Icons.chevron_right), onPressed: _canGoNext ? () onMonthChanged(selectedMonth.add(const Duration(days: 1))) : null, ), ], ), ); } }这里有个细节不能直接用month.subtract(const Duration(days: 1))来让月份减一会踩到“只有28/29/30/31天”的坑。更稳妥的做法是直接用DateTime的month加减然后重新构造日期。我实际用的是DateTime(month.year, month.month - 1, 1)这样跨年和2月都不出错。5. 数据持久化与趋势图实现5.1 本地数据库表结构设计套餐历史的数据用数据库来存最合适天然支持时间范围查询和聚合计算。建表语句如下CREATE TABLE IF NOT EXISTS usage_records ( id TEXT PRIMARY KEY, date TEXT NOT NULL, used_bytes INTEGER NOT NULL DEFAULT 0, package_id TEXT NOT NULL DEFAULT , network_type INTEGER NOT NULL DEFAULT 0, created_at TEXT NOT NULL, updated_at TEXT NOT NULL ); CREATE INDEX IF NOT EXISTS idx_records_date ON usage_records(date); CREATE INDEX IF NOT EXISTS idx_records_package ON usage_records(package_id);id字段我设计成了“包ID 日期 网络类型”的组合字符串比如pkg_001_2025-03-15_cellular。这样同一日期同一网络类型的新记录插入时可以通过主键冲突直接做更新避免产生脏数据。索引方面只用到了日期和包ID因为所有查询都是按这两个维度过滤。5.2 数据迁移与升级策略App在后续迭代中可能改表结构所以数据库版本管理也要提前规划。我在仓库层封装了版本升级回调每次开发中修改表结构时递增版本号并编写对应的迁移脚本。class AppDatabase { static const _dbName data_guard.db; static const _dbVersion 2; static FutureDatabase open() async { return openDatabase( join(await getDatabasesPath(), _dbName), version: _dbVersion, onCreate: (db, version) async { await db.execute(_createUsageTable); }, onUpgrade: (db, oldVersion, newVersion) async { if (oldVersion 2) { await db.execute(ALTER TABLE usage_records ADD COLUMN network_type INTEGER NOT NULL DEFAULT 0); } }, ); } }这段代码反映了一个实际教训最初建表时没有预留network_type字段后来联调发现Wi-Fi流量也被算进来必须加字段。幸好当时还没发布正式包不然就要写迁移脚本了。所以设计表的时候宁可多留几个可能需要的字段也不要等上线后补。5.3 趋势图的绘制方案趋势图我用fl_chart的LineChart实现数据源是某个月份内每天的流量值。需要说明的是对于缺失数据的日期我特意不添加对应的点让折线在数据空缺处断掉而不是补齐为0。这样视觉上能直观看出哪几天没有数据比用0填充更诚实。LineChart _buildTrendChart(ListDailyUsage data) { final spots FlSpot[ for (var i 0; i data.length; i) if (data[i].hasData) FlSpot(i.toDouble(), data[i].bytes / (1024 * 1024).toDouble()), ]; return LineChart( LineChartData( minY: 0, maxY: _computeMaxY(data), lineBarsData: [ LineChartBarData( spots: spots, isCurved: true, color: Colors.blue, barWidth: 2, dotData: const FlDotData(show: true), belowBarData: BarAreaData( show: true, color: Colors.blue.withOpacity(0.15), ), ), ], ), ); }单位转换这里有个小坑系统返回的流量值是字节直接画进图表会导致Y轴数值巨大一个G就是十位数折线图会压成一条直线。所以我统一除以1024*1024换算成MB并保留两位小数。交互方面fl_chart的LineTouchData支持触摸显示tooltip可以在用户点击某个点时展示当天的精确用量。5.4 缓存与在线数据的取舍由于套餐历史是纯本地数据不存在“在线拉取”的逻辑但为了避免每次进入页面都重新聚合我加了一个内存缓存层缓存最近一次查询的月度汇总结果10分钟内有效。超过时限或数据有更新如定时采集写入时再重新跑聚合。这个缓存对页面响应速度的提升非常明显。因为聚合操作虽然不重但如果数据积累到一年以上每次进页面都要查一次数据库、遍历上千条记录在低端设备上会有可见的卡顿。加一层轻量缓存后用户感受上就是秒开。6. 常见问题与排查技巧实录6.1 Flutter插件在OpenHarmony上的兼容性这是最容易被卡住的一环。纯Dart的package比如provider、intl、fl_chart在OpenHarmony上基本能无缝使用但凡是依赖原生代码的插件比如shared_preferences、sqflite、path_provider都需要检查是否有OpenHarmony适配版。我遇到的典型报错是Error resolving plugin [id: dev.flutter.flutter-plugin-loader, version: ...]这个报错的根本原因是项目引用了某些未适配OpenHarmony的插件导致Flutter工具链在解析插件时失败。排查思路是逐个注释依赖用二分法定位出问题插件再用OpenHarmony兼容版替代。我最终用的插件清单里sqflite用的是社区维护的sqflite_ohos分支shared_preferences也有对应适配版本。如果是自己团队内部封装的原生插件就需要在pubspec.yaml里声明支持ohos平台的实现。6.2 套餐历史数据不准怎么办数据不准的问题十有八九出在统计口径上。我调试时发现过的几个情况Wi-Fi和移动数据混在一起统计导致套餐历史数值虚高设备重启后计数器清零增量计算出现负值跨天边界处理不当某天的数据被记到了前一天或后一天针对这些情况我的排查顺序是先看数据库里的原始记录确认采集是否正常然后检查采集时间戳看是否有时间漂移最后核对网络类型字段看是移动数据还是Wi-Fi。有一次用户反馈“流量凭空多了500MB”追查下来是他连了公共Wi-Fi但系统将Wi-Fi流量统计进了移动数据通道属于系统API的统计口径问题只能在采集时通过判断网络类型做过滤。6.3 周期计算边界条件验证套餐周期计算是历史模块最容易出bug的地方。我写单元测试时专门覆盖了这些场景重置日为31号遇到2月怎么办重置日为1号跨年时怎么算本月是否跨越两个周期设备时间手动修改后周期边界如何处理其中“手动修改系统时间”是最难处理的。如果用户把时间往前调会导致新采集的数据写入“过去”的日期破坏当天记录。目前的方案是采集时对比设备当前时间和上次记录时间的差值如果差值超过6小时就认为发生了异常跳变暂停写库并提示用户校准时间。这块逻辑不用做太复杂能在边界场景下不“炸”就行。做过统计类App的朋友应该明白用户对流量数据的敏感度极高数值哪怕差0.1MB都会来质疑而时间跳变是最容易引发数值异常的原因。6.4 性能优化建议套餐历史页面在数据量小的时候很快但数据积累到一定程度就要注意了列表复用每个_DailyUsageTile都是标准组件Flutter的列表复用机制能兜底但不要在Item里做复杂计算。聚合结果缓存月度汇总结果缓存10分钟避免每次刷新都重新遍历全表。图片与图标懒加载趋势图的点数量控制在31个以内超过的部分做降采样。数据库索引查询条件字段必须建索引别偷懒。我实测在低端OpenHarmony开发板上整个页面加载首帧在300ms以内滚动流畅度没有问题。性能瓶颈更多集中在首次冷启动时插件的初始化这一块需要配合原生侧的启动优化来做。7. 写在最后的实操心得套餐历史这个模块做完之后我自己复盘了一下觉得有几个点最值得其他开发者借鉴。第一平台差异比想象中更早出现。原以为Flutter能把平台差异完全屏蔽掉实际到数据采集一层的通道适配还是要回到OpenHarmony的系统接口理解上来。建议做任何跨平台工具类应用之前先梳理“哪些能力是需要调用系统API的”这些地方要预留充足的适配时间。第二数据统计类功能的准确性大于一切。用过流量监管工具的用户对数字的信任非常敏感。宁可某些天显示“暂无数据”也不要给一个凭空的0或一个包含Wi-Fi流量的假汇总。数据诚实产品才能长久。第三周期计算一定要写单元测试。日期相关的边界条件多到爆炸靠手工测试不可能覆盖全我最后补的测试用例覆盖了两年跨度的所有特殊日期组合才敢放心把这个模块提交。如果后续要扩展我建议往“超额提醒”和“流量包叠加”方向走这两个功能在数据模型层面已经预留了空间加需求时不用再动表结构。希望通过这篇实战分享能帮你少踩几个坑。