用 Flutter 从零构建跨平台门店费用簿录入、校验、本机持久化与 Web 构建全流程实战【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe门店费用簿是 Easy Vibe 课程「跨平台开发」模块中的一个典型实战项目用一套 Dart 代码同时覆盖 Android、iOS 与 Web 三种目标。本文将基于 Flutter 应用开发指南 的完整步骤从环境检查、项目创建、首页与表单搭建到字段校验、本机保存和自动化测试逐步展开并对照中文版详细教程与仓库中的真实运行截图讲清楚每一步的验收标准与坑点。读完你不仅能复现一个可刷新恢复的门店费用簿原型还能理解「能编译」与「能上架」之间还隔着哪些平台验证工作。Flutter 与 Dart先分清两个名字在动手之前先把两个容易混淆的概念分开Dart是编写页面、状态和业务逻辑的语言Flutter是界面框架和开发工具负责提供 Widget、渲染、调试、测试以及各平台的构建能力。Flutter 并不是把网页套进手机外壳。当它发布到 Android 或 iOS 时应用会包含 Flutter 引擎并通过平台嵌入层接入系统能力相机、定位、通知、本地存储这类能力通常通过插件使用插件没有覆盖的部分还可以用 Kotlin 或 Swift 编写平台代码。从产品视角看Flutter 比较适合以下场景Android 与 iOS 的主要页面和业务流程高度接近团队从零开始做会员、交易、内容、门店或企业内部应用产品有统一的设计系统希望两端视觉一致除了手机未来还可能提供 Web 或桌面版本团队愿意学习 Dart并保留少量 Kotlin / Swift 的接入能力。如果产品只是已有网站的简单包装可以考虑 PWA 或 Capacitor如果核心是蓝牙、车机、系统扩展或最新平台 API则应该先用一个关键功能原型对比 Flutter 与原生方案不要只凭「一套代码」决定长期架构。更多选型判断可参考 跨平台技术选型指南。先看真实产品从 My BMW、Google Pay 与 Nubank 学什么文档用三个已上线的 Flutter 应用说明「跨平台不是万能药产品判断、平台适配、测试与发布流程一样都不能省」My BMW连接车主与车辆服务的应用统一了不同品牌、系统和多个市场的版本。最值得借鉴的不是汽车界面而是「用户先看见当前状态再决定下一步操作」的信息组织方式以及按业务领域拆模块、自动验证不同平台构建的做法。Google Pay迁移前先让资深工程师做首页、聊天和支付的纵向原型把关键原生插件一并验证得到反馈后才逐步扩大重写。这给费用簿的直接提醒是先跑通一条可以验收的链路看汇总 → 录入费用 → 看到错误或成功反馈 → 刷新后恢复不要一上来就加审批、报销、云同步。Nubank用多项标准比较 Kotlin Native、React Native 与 Flutter 之后才选定新功能逐步采用、旧功能按计划迁移并建立自己的设计系统把单元、组件和端到端测试纳入开发方式。这三个案例放在一起结论很明确Flutter 省下的是重复实现而不是产品判断、平台适配、测试和发布流程。门店费用簿正是沿用了这套思路——先做最小可用链路再做拆分、适配与发布验证。第一步检查环境跑起空白项目安装好 Flutter 之后先运行环境诊断不要急着让 AI 改一串环境变量flutter doctor把flutter doctor -v的输出原样交给 AI让它只指出第一个必须修复的问题修完一项再重新检查。需要注意Web 旁边出现对勾不代表 Android SDK 和 iOS 签名也已经准备好。然后创建项目并启动flutter create store_expense_ledger cd store_expense_ledger flutter run -d chrome教程实际验证使用的环境是Flutter 3.44.9 与 Dart 3.12.2。当时flutter doctor显示Chrome 可用但本机没有 Android SDKXcode 已安装却没有可用的 iOS Simulator RuntimeCocoaPods 也未安装。因此后面所有截图均为Flutter Web 的真实运行构建文档明确说明这些截图不冒充 Android 模拟器或 iPhone 真机——这一条事实边界值得所有读者留意教程的截图对应什么运行环境必须如实交代。如果空白项目没有启动只把第一段有效错误交给 AI空白 Flutter 项目启动失败。错误是【粘贴错误】请只修复启动问题。先确认计数器模板能运行再开始写费用簿。这样后面出错时你能判断问题来自业务修改而不是 SDK、下载或设备配置。第二步先排首页信息再做表单第一轮只使用演示数据请把首页改成「门店费用簿」。显示本月金额、备用金、最近费用和「记一笔」按钮先用演示数据。这一步看的是信息顺序而非数据库打开页面以后店长应该马上看见总额、预算和最近几笔记录主要按钮只有一个颜色和字号可以调整但不要用五六种卡片同时抢注意力。页面太挤时就让 AI「只保留总额、预算、最近记录和新增按钮其他先删掉」。首页稳定以后再做最小表单点击「记一笔」时打开底部表单只填写费用说明和金额。底部表单适合短任务因为用户还能看见原来的页面字段变多、需要拍照或审批信息时就应该换成完整页面不要把所有内容硬塞进一个弹层。第三步校验要落在字段上保存要有明确反馈这一轮只处理错误反馈费用说明不能为空金额必须大于 0。保存失败时把原因写在对应字段下面。实际点击空表单的「保存到本机」以后两个字段会变红并分别说明缺少什么。这里没有只写「参数错误」也没有弹出一个马上消失的统一提示——用户能在出错的位置直接修改接着补保存成功反馈保存成功后关闭表单把新记录放到列表顶部并明确告诉用户已经保存在本机。实测输入「打印纸」和56后金额从 ¥890.50 变为 ¥946.50待同步数量从 1 变为 2列表顶部出现新记录底部同时显示「已保存在本机联网后再同步」。这类反馈看起来只是文案却能避免用户因为不确定而连续点五次需要特别说明的是当前版本没有真实服务器「待同步」只是清楚表达产品状态不能据此宣称云端同步已经完成。接服务器以前要自己决定读取以本机还是远端为准、失败怎样重试、何时改变同步状态并让服务端识别重复提交不能只靠按钮暂时禁用。第四步本机持久化——刷新之后记录还在少量演示数据可以先使用shared_preferencesflutter pub add shared_preferences然后只给 AI 一个目标请把费用记录保存在本机。页面刷新或应用重启后新记录仍然存在。保存「打印纸 ¥56」以后教程重新加载了整个 Web 应用刷新后的首页截图仍然能看到它——这一步验证的是本机持久化不是服务器同步。这里有一个明确的边界shared_preferences适合设置和少量简单值不适合大量费用、附件、查询和事务。产品继续扩大时应该换成数据库并把数据层放进 Repository把数据来源入口收敛到数据层这样测试费用计算时不必真的打开页面测试页面时也能替换掉服务器。第五步测试与构建——analyze、test、build web本地保存跑通后进入自动验证环节flutter analyze flutter test flutter build web按文档记录的实际结果flutter analyze没有发现问题Widget Test 通过验证了首页能够显示并能打开录入表单flutter build web成功产物生成在build/web。随后通过本地静态服务器打开这个生产构建完成录入、错误反馈、保存和刷新恢复测试——而不是直接双击 HTML 文件。教程也诚实说明空表单提示和本机恢复是通过浏览器实际操作验证的尚未写成完整自动化测试因此不把它们冒充成测试套件已经覆盖。想再补一条用户流程可以这样要求 AI请写一个 Widget Test打开首页点击「记一笔」确认费用说明、金额和保存按钮出现。表单校验稳定以后再加请测试空表单不能保存并能看见两个错误提示。项目扩大后的测试分工一般是费用计算和 ViewModel 适合单元测试页面状态适合 Widget Test登录、上传、离线恢复和同步适合集成测试。第六步Android 与 iOS 必须分别打开构建与发布是两条独立流水线Web 运行通过以后回到flutter devices确认 Android 模拟器与 iOS 模拟器出现在列表里flutter run -d Android 设备编号 flutter run -d iPhone 模拟器编号两边至少重新检查这些项中文、金额和大字体是否溢出底部表单是否被软键盘遮住返回手势能否正常关闭表单应用彻底关闭再打开后本机记录是否恢复相机、照片和通知权限被拒绝时会发生什么断网、恢复网络和重复重试会不会丢单或生成重复记录。发布侧Web 生产构建用flutter build webAndroid 上架一般生成 App Bundleflutter build appbundle仍需要 Android SDK、应用编号、版本号、发布签名和商店控制台配置iOS 发布在 Mac 上完成flutter build ipa需要 Xcode、签名证书、Provisioning Profile、唯一 Bundle ID生成 IPA 之后还要上传 TestFlight、测试并提交审核。两个商店的隐私说明、截图、审核规则和账号都不同「一套 Dart 代码」不会生成一个同时提交给两个商店的万能安装包。文档特别强调这一步当时尚未完成——flutter doctor找不到 Android SDKXcode 没有可用的 iOS Simulator Runtime项目又使用了需要 CocoaPods 的插件因此不能把 Web 截图当作移动端验证准备好对应环境后应补上 Android 模拟器、iOS 模拟器和至少一台真机的运行截图。这正是「能编译」与「能上架」之间真实存在的距离。收尾一笔费用能保存和恢复原型才算跑通回头看这个小费用簿空表单会告诉用户哪里不对保存以后汇总和列表一起更新页面明确区分本机保存与服务器同步刷新整个应用后新记录还在——它已经不再是一张静态卡片页。如果准备把它交给真实门店试用下一步不必急着加图表和十几个入口而是先接一套测试后端只做「上传一笔费用」和「失败后重试」再用两个账号检查门店隔离用飞行模式检查离线队列。等这条链路稳定再增加小票、审批和统计。Flutter 真正省事的地方是 Android 和 iOS 可以共同维护这条业务链路真正不能省的仍然是两端设备、权限、签名、商店和失败场景的逐项验证。想继续深入了解可以对照本仓库 跨平台模块的完整教程目录 以及 跨平台技术选型指南把费用簿原型继续扩展到真实业务场景。【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考