1. 项目缘起与整体设计思路1.1 为什么选宠物生命周期管理这个方向做任何一个从零起步的项目第一步永远不是写代码而是想清楚这东西到底给谁用、解决什么痛点。宠物生命周期管理这个方向乍看像是个小众赛道但实际拆开看它覆盖的场景密度相当高从领养/购买建档、疫苗接种提醒、驱虫周期管理、体重曲线追踪、发情与配种记录、孕产护理、到老年期的慢性病用药提醒再到最后的临终关怀与纪念存档——每一个环节都是真实养宠人反复遇到、又反复用纸笔或备忘录凑合解决的问题。我身边养猫养狗的朋友几乎人手一个Excel或者手机备忘录记录的内容五花八门有人记疫苗日期有人记体重有人记驱虫药品牌和剂量。问题是这些记录彼此孤立时间一长就断档等到宠物生病去医院医生问上次驱虫是什么时候体重最近有没有异常波动大部分人是答不上来的。这就是典型的数据存在但不可用状态。所以这个项目的核心定位很明确把宠物的时间线做成一条可回溯、可提醒、可导出给兽医看的结构化数据流。它不是社交App不是宠物电商就是一个纯粹的工具型应用把记录—提醒—回顾这个闭环做扎实。1.2 用AI辅助从零搭建的可行性判断标题里提到全流程AI实现这里得先把话说清楚AI不是帮你把整个App一键生成出来那是营销话术。真实的用法是——把AI当成一个随叫随到、不会不耐烦的结对搭档它帮你做的是需求拆解、技术选型对比、脚手架代码生成、报错排查、测试用例补全、文档撰写。而架构决策、数据模型设计、业务逻辑校验这些需要人来拍板的部分仍然得你自己扛。我实测下来AI在以下几类任务上效率提升最明显样板代码生成比如CRUD接口、数据模型定义、表单校验逻辑这类重复度高、模式固定的代码AI一次生成准确率能到80%以上。报错定位把错误堆栈贴进去它能快速给出几个可能原因和排查方向省去大量搜索时间。技术方案对比比如本地存储用SQLite还是Realm状态管理用Provider还是Riverpod它能列出各自的适用场景和坑点。测试用例补全边界条件、异常输入这些容易漏的测试点AI补得比人全。而AI容易翻车的地方也很明确涉及具体版本号的API调用、涉及平台差异的原生配置、涉及业务规则的复杂状态流转。这几类必须人工核对不能盲信。1.3 技术栈选型与理由这个项目我最终选的是Flutter SQLite本地 可选云同步的组合。理由如下维度选择理由跨平台Flutter一套代码覆盖iOS/Android宠物主群体两端分布均匀不值得写两套本地存储SQLitesqflite插件数据结构化程度高需要复杂查询按时间范围、按类型筛选SQLite最合适状态管理Riverpod比Provider更灵活编译期安全适合中大型项目提醒通知flutter_local_notifications本地通知足够不需要服务端推送图表fl_chart体重曲线、用药频率可视化轻量够用云同步可选自建轻量后端或对象存储先做本地同步作为二期这里有个关键决策点值得展开为什么先做本地而不是直接上云。很多人一上来就想做账号体系、云端同步结果光登录注册就耗掉一半精力核心功能反而没做扎实。宠物数据本质上是个人私密数据本地存储完全能满足单设备使用等核心闭环跑通了再考虑多设备同步。这个顺序不能反。2. 核心数据模型与业务逻辑拆解2.1 宠物生命周期的时间线抽象整个App的数据核心可以抽象成一条以宠物为主键的时间线。所有记录都是挂在这条时间线上的事件节点。我把它拆成三层宠物档案层宠物基本信息名字、品种、性别、生日、绝育状态、芯片号、头像。事件记录层疫苗、驱虫、体检、用药、体重、发情、配种、孕产、就诊、纪念。提醒规则层基于事件类型自动生成的下次提醒时间。这个三层结构的好处是新增一种记录类型时只需要在事件层加一个type提醒层加一条规则不用动整体架构。这就是数据模型设计的前瞻性。2.2 事件表的设计与字段说明核心表pet_events的字段设计如下这是AI辅助生成后我手动调整过的版本CREATE TABLE pet_events ( id INTEGER PRIMARY KEY AUTOINCREMENT, pet_id INTEGER NOT NULL, event_type TEXT NOT NULL, -- vaccine/deworm/weight/medication/heat/pregnancy/visit/memorial event_date INTEGER NOT NULL, -- 时间戳统一存UTC title TEXT, description TEXT, value REAL, -- 体重数值、用药剂量等 unit TEXT, -- kg/ml/mg next_remind_date INTEGER, -- 下次提醒时间可空 remind_interval_days INTEGER, -- 提醒间隔用于自动计算 attachments TEXT, -- JSON数组存图片路径 created_at INTEGER NOT NULL, updated_at INTEGER NOT NULL, FOREIGN KEY (pet_id) REFERENCES pets(id) ON DELETE CASCADE );这里有几个设计细节值得说第一时间统一存UTC时间戳。很多人图省事存字符串结果跨时区、排序、范围查询全是坑。存整数时间戳展示时再转本地时区这是铁律。第二value和unit分离。体重可能是kg也可能是g用药可能是ml也可能是mg把数值和单位分开存查询和统计时才好处理。第三remind_interval_days的存在。这是为了支持周期性提醒——比如驱虫每90天一次存了间隔天数下次提醒时间就能自动算出来不用每次手动填。第四attachments用JSON字符串。SQLite没有原生数组类型图片路径这种一对多关系要么建关联表要么存JSON。考虑到附件数量少、不需要单独查询存JSON更轻量。2.3 提醒规则的自动计算逻辑提醒是这个App的灵魂。我设计的规则是事件保存时如果该类型有默认提醒周期自动计算下次提醒时间。逻辑如下int? calculateNextRemind(String eventType, int eventDate) { final defaultIntervals { vaccine: 365, // 疫苗一年一次 deworm: 90, // 驱虫三个月一次 visit: 180, // 体检半年一次 }; final interval defaultIntervals[eventType]; if (interval null) return null; return eventDate interval * 24 * 60 * 60 * 1000; }这段逻辑看着简单但有个坑闰年、月份天数不一致的问题。如果直接用加365天来算疫苗提醒遇到闰年就会差一天。更严谨的做法是用日期库做月份加减final next DateTime.fromMillisecondsSinceEpoch(eventDate); final remind DateTime(next.year 1, next.month, next.day);这样明年同月同日才是准确的。这个细节AI第一次生成时用的是加天数方案我手动改成了日期构造方案。3. 从零搭建的完整实操流程3.1 环境准备与项目初始化第一步是环境搭建。Flutter的环境配置这里不展开假设你已经装好了SDK。项目初始化命令flutter create pet_lifecycle --org com.example --platforms ios,android cd pet_lifecycle然后加依赖pubspec.yaml里加上dependencies: flutter: sdk: flutter sqflite: ^2.3.0 path: ^1.8.3 riverpod: ^2.4.0 flutter_riverpod: ^2.4.0 flutter_local_notifications: ^16.0.0 fl_chart: ^0.66.0 image_picker: ^1.0.4 intl: ^0.18.1注意版本号不要盲目抄flutter pub outdated看一下当前最新稳定版AI给的版本号经常是过时的。我踩过一次坑用了AI推荐的旧版本结果和Flutter SDK不兼容报了一堆莫名其妙的错。3.2 数据库初始化与迁移策略数据库初始化我封装了一个DatabaseHelper单例class DatabaseHelper { static final DatabaseHelper _instance DatabaseHelper._internal(); factory DatabaseHelper() _instance; DatabaseHelper._internal(); Database? _db; FutureDatabase get database async { _db ?? await _initDb(); return _db!; } FutureDatabase _initDb() async { final path join(await getDatabasesPath(), pet_lifecycle.db); return openDatabase( path, version: 1, onCreate: _onCreate, onUpgrade: _onUpgrade, ); } Futurevoid _onCreate(Database db, int version) async { await db.execute( CREATE TABLE pets ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, species TEXT, breed TEXT, gender TEXT, birthday INTEGER, neutered INTEGER DEFAULT 0, chip_id TEXT, avatar TEXT, created_at INTEGER NOT NULL ) ); await db.execute(...pet_events建表语句...); } Futurevoid _onUpgrade(Database db, int oldV, int newV) async { // 版本迁移逻辑后续加字段时在这里处理 } }迁移策略必须提前想好。我见过太多项目第一版没写onUpgrade第二版加字段时用户数据全丢了。正确做法是每次改表结构version加1在onUpgrade里写对应的ALTER TABLE语句。哪怕现在用不上框架先搭好。3.3 核心页面与状态管理实现页面结构我分成四个Tab首页时间线、宠物档案、提醒中心、设置。首页用时间线展示所有事件按时间倒序排列。状态管理用Riverpod核心Provider设计final databaseProvider ProviderDatabaseHelper((ref) DatabaseHelper()); final petListProvider FutureProviderListPet((ref) async { final db await ref.watch(databaseProvider).database; final rows await db.query(pets, orderBy: created_at DESC); return rows.map((e) Pet.fromMap(e)).toList(); }); final eventListProvider FutureProvider.familyListPetEvent, int((ref, petId) async { final db await ref.watch(databaseProvider).database; final rows await db.query(pet_events, where: pet_id ?, whereArgs: [petId], orderBy: event_date DESC); return rows.map((e) PetEvent.fromMap(e)).toList(); });这里用FutureProvider.family是关键它让每个宠物的数据独立缓存切换宠物时不会互相干扰。这个模式AI一开始给的是普通Provider我改成了family性能提升明显。3.4 本地通知的配置与触发通知这块是坑最多的。flutter_local_notifications在Android和iOS上的配置差异很大Android端需要在AndroidManifest.xml加权限uses-permission android:nameandroid.permission.POST_NOTIFICATIONS/ uses-permission android:nameandroid.permission.SCHEDULE_EXACT_ALARM/ uses-permission android:nameandroid.permission.RECEIVE_BOOT_COMPLETED/RECEIVE_BOOT_COMPLETED这个权限很多人会漏结果手机重启后所有定时通知全失效。这个坑我踩过排查了半天。iOS端需要在AppDelegate里配置通知权限请求并且在Info.plist里说明用途。通知调度代码Futurevoid scheduleRemind(PetEvent event) async { if (event.nextRemindDate null) return; final scheduledDate DateTime.fromMillisecondsSinceEpoch(event.nextRemindDate!); if (scheduledDate.isBefore(DateTime.now())) return; await flutterLocalNotificationsPlugin.zonedSchedule( event.id!, ${event.title} 提醒, 该给毛孩子安排上了, tz.TZDateTime.from(scheduledDate, tz.local), const NotificationDetails( android: AndroidNotificationDetails(pet_remind, 宠物提醒, importance: Importance.high, priority: Priority.high), iOS: DarwinNotificationDetails(), ), androidScheduleMode: AndroidScheduleMode.exactAllowWhileIdle, uiLocalNotificationDateInterpretation: UILocalNotificationDateInterpretation.absoluteTime, ); }关键点androidScheduleMode必须用exactAllowWhileIdle否则系统会为了省电把通知延迟用户可能晚几个小时才收到。这个参数是精确闹钟的核心。4. 常见问题排查与避坑经验4.1 数据库相关的高频问题问题一database is locked错误。多线程同时写数据库时会报这个。解决方案是确保所有数据库操作走同一个单例并且用事务包裹批量操作await db.transaction((txn) async { for (final event in events) { await txn.insert(pet_events, event.toMap()); } });问题二查询结果类型不匹配。SQLite存的整数读出来可能是int也可能是String取决于插入方式。稳妥做法是在fromMap里做类型转换factory PetEvent.fromMap(MapString, dynamic map) { return PetEvent( id: map[id] as int?, eventDate: (map[event_date] as num).toInt(), value: map[value] null ? null : (map[value] as num).toDouble(), // ... ); }用as num再转比直接as int安全得多。4.2 通知不触发的排查清单通知不触发是最让人抓狂的问题我整理了一个排查顺序排查项检查方法常见原因权限是否授予检查系统设置里的通知权限用户拒绝后没引导重新开启精确闹钟权限Android 12 需单独申请漏了SCHEDULE_EXACT_ALARM重启后失效检查RECEIVE_BOOT_COMPLETED权限缺失或没注册receiver时间已过期打印scheduledDate对比当前时间计算逻辑错误时区问题检查tz.local是否正确初始化没调initializeTimeZones时区初始化这个坑特别隐蔽必须在main里先调void main() async { WidgetsFlutterBinding.ensureInitialized(); tz.initializeTimeZones(); tz.setLocalLocation(tz.getLocation(Asia/Shanghai)); runApp(const ProviderScope(child: MyApp())); }漏了这一步通知时间会差好几个小时而且不报错极难排查。4.3 AI辅助开发的使用心得用AI写这个项目我总结了几个实用技巧技巧一给AI喂上下文。不要只丢一句帮我写个宠物列表页要把数据模型、状态管理方案、UI风格一起给它。上下文越完整生成代码越可用。技巧二让AI先出方案再写代码。比如我要做提醒功能先给我三个技术方案对比不要写代码等它列完方案你选定后再让它写实现。这样能避免它直接给你一个不合适的方案。技巧三报错信息完整粘贴。包括堆栈、你的代码片段、相关配置。信息越全定位越准。我试过只贴一行错误AI给的答案全是泛泛而谈贴了完整堆栈后一次就定位到是版本兼容问题。技巧四生成后必做代码审查。AI生成的代码有几个高频问题空安全处理不严谨、异步没加await、资源没释放。这些必须人工过一遍。5. 功能扩展与后续演进方向5.1 数据导出与兽医协作核心闭环跑通后最有价值的扩展是数据导出。养宠人带宠物去医院时如果能一键导出一份PDF报告包含疫苗记录、用药历史、体重曲线医生能快速了解情况。实现上用pdf和printing两个包把数据渲染成表格和图表。这个功能的技术难点不在生成PDF而在数据组织——要把散落的事件按类型聚合、按时间排序、计算统计值比如平均体重、用药频次。这部分逻辑建议单独抽一个ReportGenerator类和UI解耦。5.2 多宠物家庭的数据隔离很多家庭养多只宠物数据隔离必须做好。我的方案是所有查询强制带pet_id条件并且在UI层用Tab或下拉切换当前宠物。这里有个容易忽略的点删除宠物时要级联删除其所有事件建表时的ON DELETE CASCADE就是干这个的但SQLite默认不开启外键约束需要在onConfigure里手动开onConfigure: (db) async { await db.execute(PRAGMA foreign_keys ON); },漏了这句删宠物后事件数据会变成孤儿数据越积越多。5.3 云同步的取舍云同步是二期功能但架构上要提前留口子。我的建议是本地数据表加sync_status和remote_id两个字段标记每条记录的同步状态。这样后续接入同步时不用改表结构只需要加同步逻辑。同步策略上宠物数据适合最后写入优先Last Write Wins因为冲突概率低。但要注意时间戳必须用服务端时间否则设备时间不准会导致同步错乱。6. 我个人的实操体会这个项目从零到能跑通核心闭环我大概花了三周业余时间其中AI辅助省下的时间估计有一半以上。但有几个体会特别深第一AI能加速但不能替代思考。数据模型怎么设计、提醒逻辑怎么算、状态怎么流转这些决策AI给的建议只能当参考最终拍板还得靠自己。我见过有人完全照搬AI的架构结果做到一半发现扩展不了推倒重来。第二越早处理边界情况越省事。闰年、时区、权限、重启、级联删除这些边界情况如果第一版不考虑后面补起来成本翻倍。AI生成代码时默认走happy path边界处理得靠自己补。第三本地优先的策略是对的。先不碰账号和云同步把单机体验做扎实用户能立刻用起来。等有了真实反馈再决定要不要上云、怎么上云。这个顺序让我少走了很多弯路。最后分享一个小技巧每次让AI生成代码后让它自己写对应的单元测试。测试用例能帮你发现很多逻辑漏洞而且写测试的过程本身就是在梳理业务规则。我现在的习惯是核心业务逻辑必须配测试UI层可以松一点。这样重构时心里有底不怕改坏。
