ArkTS家电保修簿：日历月到期计算与Preferences存储

鸿蒙专家

在实现一个本地家电保修簿时，核心不是做售后平台，而是把购买日期、保修月数和维修记录放进同一个电器详情，让到期状态、筛选和凭证线索围绕同一批本地档案工作。原文的实现使用 ArkTS 与 ArkUI，在 DevEco Studio 工程 entry/src/main/ets/pages/Index.ets 中完成首页，并在模拟器上以 2026 年 11 月 1 日作为当前日期进行状态核对。应用不连接品牌售后，不自动识别发票或保修条款，也不发送到期通知；日期和月数由使用者录入，程序只负责计算到期日、按状态筛选并保存记录。

录入与数据模型
首页初次打开时列表为空，页面保留录入入口。一条记录至少需要电器名称、购买日期和保修月数；品牌、型号、分类、订单或凭证位置、备注、图片 URI 和维修记录数组用于后续查找与补充。购买日期按 YYYY-MM-DD 输入，保修时长按整月填写。保存前会检查名称、日期格式、购买日期是否晚于今天，以及保修月数是否为 1 到 120 的整数。这些校验只避免明显无效输入进入计算，并不验证保修承诺本身。搜索匹配名称、品牌、型号和分类；订单号和备注留在详情页，避免首页卡片过载。记录保存后首页按到期日排序，越早到期越靠前，列表用于快速定位，详情保留凭证线索。

状态是日期计算视图
三种状态不是手工标签。程序先由购买日期和保修月数计算到期日，再按到期日与当前日期的天数差分类：早于今天为已过保；剩余 0 到 30 天（含第 30 天）为 30 天内到期；超过 30 天为保修中。以模拟器显示的 2026 年 11 月 1 日为基准，净水器到期日 2025 年 11 月 1 日，已过期 365 天；空调到期日 2026 年 12 月 1 日，还剩 30 天；冰箱到期日 2027 年 11 月 1 日，还剩 365 天。首页计数对应每种状态一条。筛选状态变化时重新计算当前记录状态并筛掉不匹配条目；搜索在筛选结果内继续按名称、品牌、型号或分类缩小范围。列表按距离到期的天数升序排列，因此过保净水器排前，30 天到期的空调次之，保修期更长的冰箱在后。筛选不会改变顶部计数，计数仍统计全部档案；若到期日是今天显示今天到期，过期后显示已过期天数。已过保记录不会从本地列表消失，仍可打开、补充信息或查看维修经过。

日历月到期计算
日期计算不能按每月固定 30 天近似，否则月长差异会累积到到期日。原文模型先定位目标年月，再取目标月最后一天，并把原日期的日号限制在该范围内。核心逻辑为：

2. const lastDay = new Date(Date.UTC(targetYear, targetMonthIndex + 1, 0)).getUTCDate();
3. const targetDay = Math.min(day, lastDay);

复制代码

这样 2024 年 1 月 31 日加一个月会落到闰年 2 月 29 日；平年二月落到 28 日；目标月只有 30 天时，31 日落到 30 日；目标月有 31 天时原日号可保留。剩余天数按日历日期计算，闰日会自然参与天数差。输入校验和到期计算是两件事：表单先拒绝 2024-02-30 这类日历上不存在的日期，也不接受晚于今天的购买日期；通过校验后才拆分年月日参与日历月计算。状态变成已过保不会改写到期日，因此同一条档案可同时保留稳定的计算结果和随当前日期变化的剩余天数。

维修记录与Preferences持久化
维修记录逐次追加在对应电器档案下，每条保存日期和一段文字，适合记录故障现象、处理方式或服务单号。新增记录时复制当前电器档案字段，把新记录追加到 repairs 数组，再把更新后的档案列表交给 WarrantyStore.save()。保存接口成功后才替换内存中的档案数组并关闭录入状态；本地保存失败则给出提示，不把失败误报成已保存。编辑时从旧记录取回 repairs 数组再构造更新后的档案，调整品牌、型号或保修时长不会抹掉已有维修历史；删除需要确认，并同时移除该电器及其维修记录。档案和维修历史由 WarrantyStore 统一写入 Preferences，序列化成 JSON 字符串，每次保存后调用 flush()；页面重新打开时先初始化存储，再读取并解析记录。凭证图片选择入口已接入录入流程，选中的 URI 随档案保存，详情页在有 URI 时显示预览。需要注意，原文画面只确认了维修历史显示和源码写入流程，退出再启动后的恢复结果、图片选择器返回和详情预览未在画面中验证，仍需补前后对照实测。

实践取舍
把保修状态做成按日期计算的视图，可以让首页筛选、排序和详情核对使用同一组输入；一旦购买日期或保修月数录错，后续状态会跟着错，因此录入时最值得核对的是这两项。Preferences 适合本机小型档案的 JSON 化保存，但保存失败提示和重启恢复验证必须单独覆盖；原文也明确应用不核实发票真伪、不识别保修条款、不联系售后。对于需要整理多台电器的场景，先按 30 天内到期筛选，再用搜索定位品牌或型号，比逐条翻档案更直接。

热心网友5

这个思路挺清楚的，尤其是把保修状态做成“按日期计算的视图”，而不是手工标签，后面筛选、排序和详情核对都用同一组输入，逻辑不容易分叉。日历月到期那段处理得也对，先取目标月最后一天再用 Math.min 限制日号，31 日加一个月落到 2 月 28/29 日、落到 30 天月份这些边界都覆盖到了，比按 30 天近似靠谱很多。 我会特别留意两个地方：一是“今天”的取法最好统一，如果购买日期校验、到期日计算和剩余天数分别用了本地时间和 UTC，跨时区或午夜附近可能差一天，建议明确以本地日历日为准，只在取月末时用 UTC 辅助。二是 Preferences 保存失败时先不替换内存数组、不关闭录入状态这个顺序很关键，重启恢复和图片 URI 预览也确实要补实测，尤其是保存后杀进程再打开、选图后返回详情这两条链路。 另外测试时可以专门覆盖：购买日期等于今天、保修 1 个月和 120 个月、1 月 31 日加一个月、闰年 2 月 29 日、12 月跨年，以及筛选后计数仍统计全部档案这些点。整体上这个本地保修簿的取舍挺务实，不追求售后平台能力，先把本地档案、到期计算和维修记录串起来，方向是对的。

热心网友5

这个实现思路挺清晰的，尤其是把“保修状态”做成由购买日期和保修月数计算出来的视图，而不是手工维护标签，筛选、排序和详情核对就能围绕同一份数据工作，不容易出现状态和到期日对不上。日历月计算里先定位目标年月、取目标月最后一天，再用 Math.min 限制原日号，这个处理比按 30 天近似靠谱很多，闰年二月和 31 日落 30 日的情况都能覆盖。 有几个地方后续可以重点补测：一是剩余天数计算最好统一日期基准，比如都按本地日历零点或 UTC 日期零点算，避免时区和夏令时导致差一天；二是 Preferences 保存失败时内存列表不要提前替换，这点楼主已经提到了，最好再加一次“保存失败后页面数据是否仍与本地一致”的回归；三是维修记录追加时复制档案字段、保留 repairs 数组，这个对编辑时不丢历史很关键。图片 URI 随档案保存后，退出再启动、权限是否仍可读、详情页预览是否正常，也确实需要前后对照实测。 另外首页筛选不改变顶部计数、计数仍统计全部档案，这个取舍挺合理；如果用户档案多，按 30 天内到期筛选再搜索品牌型号，会比逐条翻更实用。整体看是一个偏本地工具型的实现，边界说明也比较克制，没有把不验证保修承诺、不发通知这些能力说满。

热心网友6

这个思路挺清楚的，尤其是把保修状态做成按日期计算出来的视图，而不是手工打标签，筛选、排序和详情核对都围绕同一组购买日期和保修月数走，状态和到期日不容易对不上。日历月到期计算那段也抓住了关键点：先定位目标年月，再取目标月最后一天并截断日号，像 1 月 31 日加一个月落到闰年 2 月 29 日、平年 2 月 28 日，比按 30 天近似靠谱得多。 另外，保存成功后才替换内存数组、编辑时不抹掉维修历史、删除时连维修记录一起移除，这些细节对本地档案类应用挺重要。Preferences 做小型 JSON 存储够用，但保存失败提示和退出再启动后的恢复验证确实要单独覆盖；楼主也提到重启恢复、图片选择器返回和详情预览还没在画面中验证，建议补一组前后对照实测。输入校验只拦明显无效数据，不验证保修承诺本身，这个边界说得很明白；实际使用时最值得核对的就是购买日期和保修月数，录错会连带影响后续状态，所以详情里保留凭证线索和维修记录还是有价值的。

轰客

谢谢楼主的分享