教程文档【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址https://gitcode.com/datawhalechina/easy-vibe点击查看免费下载本指南基于 easy-vibe 仓库中 Flutter 跨平台应用章节 展开以「门店费用簿store_expense_ledger」为实战项目完整走通 Flutter 开发的核心链路环境检查、项目创建、首页与表单搭建、字段级校验、本机持久化、自动化测试与 Web 构建。读完本文你将掌握一套用一套 Dart 代码同时面向 Android、iOS 与 Web 的落地方法并理解「能编译」与「能上架」之间的真实差距。1. 先分清 Dart 与 Flutter再判断场景是否合适第一次接触 Flutter 时容易把两个名字混为一谈Dart是编写页面、状态和业务逻辑的编程语言Flutter是界面框架与开发工具链负责 Widget 渲染、调试、测试和各平台构建能力。Flutter 并不是「把网页套进手机外壳」。当它发布到 Android 或 iOS 时应用内会携带 Flutter 引擎并通过平台嵌入层接入系统能力相机、定位、通知和本地存储通常通过插件调用插件没有覆盖的能力还可以用 Kotlin 或 Swift 编写平台原生代码。这一点决定了选型时的判断标准Flutter 适合 Android 与 iOS 需要几乎相同产品与设计、且团队愿意共用设计与业务实现的场景反之如果产品长期依赖大量 Android 或 Apple 独有能力、两端交互差异很大原生 Compose 与 SwiftUI 往往更直接。在 easy-vibe 的选平台指南中Flutter 与 React Native、uni-app、Capacitor 同属于「跨平台框架」这一中间路线——本质上是在开发效率与原生体验之间做取舍。如果产品只是已有网站的简单包装可以先评估 PWA 或 Capacitor如果最重要的是蓝牙、车机、系统扩展或最新平台 API则应该先用一个关键功能原型对比 Flutter 与原生方案而不是只凭「一套代码」决定长期架构。2. 从真实产品中学习My BMW、Google Pay 与 Nubank宝马、Google Pay 和 Nubank 面向的用户完全不同但都在正式产品中使用了 Flutter它们安排页面状态、迁移已有功能和组织测试的方式可以直接指导我们的费用簿My BMW把「车辆当前状态」放在最前面用户先看见现状再决定下一步操作同时按业务领域拆模块并自动验证不同市场和平台的构建。Google Pay迁移前先用少量资深工程师做纵向原型把关键原生插件一并验证再逐步扩大重写。它给费用簿的直接提醒是第一版只跑通「看汇总 → 录入费用 → 看到错误或成功反馈 → 刷新后恢复」这一条可验收的小链路先暴露表单、状态和存储问题而不是顺手加入审批、报销、角色和云同步。Nubank没有因为 Flutter 热门就直接迁移而是先用多项标准对比方案并收集开发者反馈选定后用主题统一整页颜色把汇总卡、费用行、同步提示拆成小组件并把单元、组件和端到端测试纳入开发方式。这三个案例放在一起结论很明确Flutter 省下的是重复实现不是产品判断、平台适配、测试和发布流程。3. 环境检查先跑flutter doctor再看本机缺什么安装 Flutter 后第一件事不是急着写代码而是运行flutter doctor -vflutter doctor会逐项检查 Flutter SDK、Chrome、Android SDK、Android Studio、Xcode、iOS Simulator 与 CocoaPods 的状态。注意事项Web 旁边出现对勾不代表Android SDK 和 iOS 签名也已就绪建议把检查结果交给 AI一次只修复第一个必须解决的问题修完一项再重新检查本指南实际验证使用的环境是Flutter 3.44.9、Dart 3.12.2 与 Chrome。flutter doctor -v当时显示Chrome 可用但本机没有 Android SDKXcode 已安装却没有可用的 iOS Simulator RuntimeCocoaPods 也未安装。因此后续截图全部来自实际运行的 Flutter Web 构建不会冒充 Android 模拟器或 iPhone 真机截图。4. 创建项目从计数器模板跑起在准备存放项目的目录执行flutter doctor flutter create store_expense_ledger cd store_expense_ledger flutter run -d chrome建议的顺序是先确认空白计数器模板能在 Chrome 中启动再开始改造。这样后面出错时你能确定问题来自业务修改而不是 SDK 下载或设备配置。若空白项目启动失败只把第一段有效错误交给 AI让它只修复启动问题。如果计划后续运行移动端还可以用flutter devices查看当前真正可用的目标设备——看到 Chrome 不等于手机环境已经完成Android Emulator 与 iOS Simulator 应当分别出现在列表里。5. 先搭首页信息结构再谈数据库第一轮只使用演示数据让 AI 完成一个目标请把首页改成「门店费用簿」。显示本月金额、备用金、最近费用和「记一笔」按钮先用演示数据。这一轮的重点是信息顺序店长打开页面后应该立刻看见总额、预算和最近几笔记录主要按钮只有一个颜色和字号可以调整但不要用五六种卡片同时抢注意力。页面太挤时再逐步精简首页只保留总额、预算、最近记录和新增按钮其他先删掉。6. 把「本机保存」和「服务器同步」两个状态摆上页面成熟应用不会用一个转圈图标代替所有状态。对门店费用来说至少要分清「已经存在本机」和「已经到达服务器」请给首页增加最后同步时间和待同步数量。断网时也要能看懂记录是否已经保存在本机。本页实际构建的版本中顶部写着最后同步时间和待同步数量费用行也标记了「待同步」而不是只在控制台打印一条日志。当前版本没有真实服务器「待同步」只是清楚表达产品状态不能据此宣称云端同步已经完成。后续接入服务器前应先决定读取以本机还是远端为准、失败怎样重试、何时改变同步状态。7. 增加底部费用表单首页稳定后再做最小表单点击「记一笔」时打开底部表单只填写费用说明和金额。底部表单适合短任务因为用户还能看见原来的页面字段变多、需要拍照或审批信息时就应该换成完整页面。先让两个字段能输入再单独增加校验规则。8. 校验不要让「保存」按钮静悄悄地失败这一轮只处理错误反馈费用说明不能为空金额必须大于 0。保存失败时把原因写在对应字段下面。实际点击空表单的「保存到本机」后两个字段会变红并分别说明缺少什么这里没有只写「参数错误」也没有弹出一个马上消失的统一提示——用户能在出错的位置直接修改。接着补保存成功反馈保存成功后关闭表单把新记录放到列表顶部并明确告诉用户已经保存在本机。本页实测输入费用说明和金额56后总额随之更新、待同步数量 1、列表顶部出现新记录、底部同时出现「已保存在本机联网后再同步」这类反馈看起来只是文案却能避免用户因为不确定而连续点五次。以后接真实后端还要让服务端识别重复提交不能只靠按钮暂时禁用。9. 持久化关闭应用以后记录还要回来少量演示数据可以先用shared_preferences保存。本页原型把费用列表序列化后写入本机flutter pub add shared_preferences然后只给 AI 一个目标请把费用记录保存在本机。页面刷新或应用重启后新记录仍然存在。保存费用后重新加载整个 Web 应用刷新后的首页仍能看到该记录——这一步验证的是本机持久化不是服务器同步。注意shared_preferences适合设置和少量简单值不适合大量费用、附件、查询和事务产品继续扩大时应换用数据库并把数据层收进 Repository。本指南进度以此为界本机保存已跑通账户体系、后端和服务器同步留待接入企业后端时再按「编辑、删除确认、稳定标识符、后端」的顺序逐项补齐。10. 测试与构建先静态分析再 Widget Test最后生产构建依次执行flutter analyze flutter test flutter build webflutter analyze做静态分析检查代码中的类型与使用问题flutter test运行测试。建议让 AI 增加一条用户流程测试请写一个 Widget Test打开首页点击「记一笔」确认费用说明、金额和保存按钮出现。表单校验稳定后再补请测试空表单不能保存并能看见两个错误提示。本页临时项目实际执行结果为flutter analyze没有发现问题Widget Test 通过 1 项验证了首页能够显示并打开录入表单。空表单提示与本机恢复则通过浏览器实际操作验证但尚未写成完整自动化测试——教程不会把它们冒充为测试套件已覆盖的内容。flutter build web生成生产构建产物位于build/web。本页实际执行成功随后通过本地静态服务器打开该生产构建完成了录入、错误反馈、保存和刷新恢复测试。注意应通过服务器检查构建产物而不是双击 HTML 文件。11. 移动端必须分别打开验证Web 运行通过后回到flutter devicesAndroid 模拟器出现后运行flutter run -d Android 设备编号Mac 装好 iOS Simulator Runtime 后再选择 iPhone 模拟器flutter run -d iPhone 模拟器编号两端至少重新检查中文与金额在大字体下是否溢出、底部表单是否被软键盘遮住、返回手势能否正常关闭表单、应用彻底关闭再打开后本机记录是否恢复、相机/照片/通知权限被拒绝时会发生什么、断网与恢复网络以及重复重试会不会丢单或生成重复记录。这一步在本文写作时尚未完成当时的flutter doctor找不到 Android SDKXcode 也没有可用的 iOS Simulator Runtime且项目使用了需要 CocoaPods 的插件。移动端截图不能用 Web 截图替代——准备好对应环境后应补上 Android 模拟器、iOS 模拟器和至少一台真机的运行截图。12. 构建与发布是两条独立流水线Web 生产构建用flutter build web。Android 上架一般生成 App Bundleflutter build appbundle它仍然需要 Android SDK、应用编号、版本号、发布签名和商店控制台配置。iOS 发布在 Mac 上完成flutter build ipa它需要 Xcode、签名证书、Provisioning Profile、唯一 Bundle ID 和 App Store Connect生成 IPA 之后还要 Validate、上传 TestFlight、测试并提交审核。两个商店的隐私说明、截图、审核规则和账号都不同推送、内购和登录也有平台政策差异。「一套 Dart 代码」不会生成一个同时提交给两个商店的万能安装包。13. 原型跑通的标准一笔费用能保存、能恢复回头看这个小费用簿它已经不只是几张静态卡片空表单会告诉用户哪里不对保存以后汇总和列表一起更新页面明确区分本机保存与服务器同步刷新整个应用以后新记录还在。下一步不必急着加图表和十几个入口。如果准备给真实门店试用先接一套测试后端只做「上传一笔费用」和「失败后重试」再用两个账号检查门店隔离用飞行模式检查离线队列。等这条链路稳定再增加小票、审批和统计。Flutter 真正省事的地方是 Android 和 iOS 可以共同维护这条业务链路真正不能省的仍然是两端设备、权限、签名、商店和失败场景的逐项验证。本指南对应的完整中文实操版本见 docs/zh-cn/stage-3/cross-platform/flutter-app/index.md其中还包含自适应布局、Platform Channel 接入原生能力与 View/ViewModel/Repository/Service 分层等进阶内容可作为后续深入的企业级扩展参考。赞分享教程文档【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址https://gitcode.com/datawhalechina/easy-vibe点击查看免费下载相关推荐easy-vibe 跨平台实战用 Flutter 与 Vibe Coding 从零构建门店费用簿应用easy vibe 跨平台实战用 Flutter 与 Vibe Coding 从零构建门店费用簿应用 本文是 easy vibe 教程「高级开发 · 跨平台」教程文档人工智能Vibe Codingeasy-vibe 跨平台实战用 Flutter 从 0 到 1 开发门店费用簿应用easy vibe 跨平台实战用 Flutter 从 0 到 1 开发门店费用簿应用 本指南以 easy vibe 项目第三阶段「跨平台开发」中的 Flutt教程文档用 Flutter 开发跨平台应用从门店费用簿原型到可验证的多端构建用 Flutter 开发跨平台应用从门店费用簿原型到可验证的多端构建 Flutter 可以用一套 Dart 代码同时产出 Android、iOS 与 Web教程文档人工智能Vibe Coding上一篇ProperTree终极指南跨平台Plist编辑器的完整使用教程下一篇在Docker中运行Synology DSMVirtual DSM完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 Flutter 开发跨平台应用：在 easy-vibe 中把门店费用簿从空项目做到可测试、可构建
教程文档【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址https://gitcode.com/datawhalechina/easy-vibe点击查看免费下载本指南基于 easy-vibe 仓库中 Flutter 跨平台应用章节 展开以「门店费用簿store_expense_ledger」为实战项目完整走通 Flutter 开发的核心链路环境检查、项目创建、首页与表单搭建、字段级校验、本机持久化、自动化测试与 Web 构建。读完本文你将掌握一套用一套 Dart 代码同时面向 Android、iOS 与 Web 的落地方法并理解「能编译」与「能上架」之间的真实差距。1. 先分清 Dart 与 Flutter再判断场景是否合适第一次接触 Flutter 时容易把两个名字混为一谈Dart是编写页面、状态和业务逻辑的编程语言Flutter是界面框架与开发工具链负责 Widget 渲染、调试、测试和各平台构建能力。Flutter 并不是「把网页套进手机外壳」。当它发布到 Android 或 iOS 时应用内会携带 Flutter 引擎并通过平台嵌入层接入系统能力相机、定位、通知和本地存储通常通过插件调用插件没有覆盖的能力还可以用 Kotlin 或 Swift 编写平台原生代码。这一点决定了选型时的判断标准Flutter 适合 Android 与 iOS 需要几乎相同产品与设计、且团队愿意共用设计与业务实现的场景反之如果产品长期依赖大量 Android 或 Apple 独有能力、两端交互差异很大原生 Compose 与 SwiftUI 往往更直接。在 easy-vibe 的选平台指南中Flutter 与 React Native、uni-app、Capacitor 同属于「跨平台框架」这一中间路线——本质上是在开发效率与原生体验之间做取舍。如果产品只是已有网站的简单包装可以先评估 PWA 或 Capacitor如果最重要的是蓝牙、车机、系统扩展或最新平台 API则应该先用一个关键功能原型对比 Flutter 与原生方案而不是只凭「一套代码」决定长期架构。2. 从真实产品中学习My BMW、Google Pay 与 Nubank宝马、Google Pay 和 Nubank 面向的用户完全不同但都在正式产品中使用了 Flutter它们安排页面状态、迁移已有功能和组织测试的方式可以直接指导我们的费用簿My BMW把「车辆当前状态」放在最前面用户先看见现状再决定下一步操作同时按业务领域拆模块并自动验证不同市场和平台的构建。Google Pay迁移前先用少量资深工程师做纵向原型把关键原生插件一并验证再逐步扩大重写。它给费用簿的直接提醒是第一版只跑通「看汇总 → 录入费用 → 看到错误或成功反馈 → 刷新后恢复」这一条可验收的小链路先暴露表单、状态和存储问题而不是顺手加入审批、报销、角色和云同步。Nubank没有因为 Flutter 热门就直接迁移而是先用多项标准对比方案并收集开发者反馈选定后用主题统一整页颜色把汇总卡、费用行、同步提示拆成小组件并把单元、组件和端到端测试纳入开发方式。这三个案例放在一起结论很明确Flutter 省下的是重复实现不是产品判断、平台适配、测试和发布流程。3. 环境检查先跑flutter doctor再看本机缺什么安装 Flutter 后第一件事不是急着写代码而是运行flutter doctor -vflutter doctor会逐项检查 Flutter SDK、Chrome、Android SDK、Android Studio、Xcode、iOS Simulator 与 CocoaPods 的状态。注意事项Web 旁边出现对勾不代表Android SDK 和 iOS 签名也已就绪建议把检查结果交给 AI一次只修复第一个必须解决的问题修完一项再重新检查本指南实际验证使用的环境是Flutter 3.44.9、Dart 3.12.2 与 Chrome。flutter doctor -v当时显示Chrome 可用但本机没有 Android SDKXcode 已安装却没有可用的 iOS Simulator RuntimeCocoaPods 也未安装。因此后续截图全部来自实际运行的 Flutter Web 构建不会冒充 Android 模拟器或 iPhone 真机截图。4. 创建项目从计数器模板跑起在准备存放项目的目录执行flutter doctor flutter create store_expense_ledger cd store_expense_ledger flutter run -d chrome建议的顺序是先确认空白计数器模板能在 Chrome 中启动再开始改造。这样后面出错时你能确定问题来自业务修改而不是 SDK 下载或设备配置。若空白项目启动失败只把第一段有效错误交给 AI让它只修复启动问题。如果计划后续运行移动端还可以用flutter devices查看当前真正可用的目标设备——看到 Chrome 不等于手机环境已经完成Android Emulator 与 iOS Simulator 应当分别出现在列表里。5. 先搭首页信息结构再谈数据库第一轮只使用演示数据让 AI 完成一个目标请把首页改成「门店费用簿」。显示本月金额、备用金、最近费用和「记一笔」按钮先用演示数据。这一轮的重点是信息顺序店长打开页面后应该立刻看见总额、预算和最近几笔记录主要按钮只有一个颜色和字号可以调整但不要用五六种卡片同时抢注意力。页面太挤时再逐步精简首页只保留总额、预算、最近记录和新增按钮其他先删掉。6. 把「本机保存」和「服务器同步」两个状态摆上页面成熟应用不会用一个转圈图标代替所有状态。对门店费用来说至少要分清「已经存在本机」和「已经到达服务器」请给首页增加最后同步时间和待同步数量。断网时也要能看懂记录是否已经保存在本机。本页实际构建的版本中顶部写着最后同步时间和待同步数量费用行也标记了「待同步」而不是只在控制台打印一条日志。当前版本没有真实服务器「待同步」只是清楚表达产品状态不能据此宣称云端同步已经完成。后续接入服务器前应先决定读取以本机还是远端为准、失败怎样重试、何时改变同步状态。7. 增加底部费用表单首页稳定后再做最小表单点击「记一笔」时打开底部表单只填写费用说明和金额。底部表单适合短任务因为用户还能看见原来的页面字段变多、需要拍照或审批信息时就应该换成完整页面。先让两个字段能输入再单独增加校验规则。8. 校验不要让「保存」按钮静悄悄地失败这一轮只处理错误反馈费用说明不能为空金额必须大于 0。保存失败时把原因写在对应字段下面。实际点击空表单的「保存到本机」后两个字段会变红并分别说明缺少什么这里没有只写「参数错误」也没有弹出一个马上消失的统一提示——用户能在出错的位置直接修改。接着补保存成功反馈保存成功后关闭表单把新记录放到列表顶部并明确告诉用户已经保存在本机。本页实测输入费用说明和金额56后总额随之更新、待同步数量 1、列表顶部出现新记录、底部同时出现「已保存在本机联网后再同步」这类反馈看起来只是文案却能避免用户因为不确定而连续点五次。以后接真实后端还要让服务端识别重复提交不能只靠按钮暂时禁用。9. 持久化关闭应用以后记录还要回来少量演示数据可以先用shared_preferences保存。本页原型把费用列表序列化后写入本机flutter pub add shared_preferences然后只给 AI 一个目标请把费用记录保存在本机。页面刷新或应用重启后新记录仍然存在。保存费用后重新加载整个 Web 应用刷新后的首页仍能看到该记录——这一步验证的是本机持久化不是服务器同步。注意shared_preferences适合设置和少量简单值不适合大量费用、附件、查询和事务产品继续扩大时应换用数据库并把数据层收进 Repository。本指南进度以此为界本机保存已跑通账户体系、后端和服务器同步留待接入企业后端时再按「编辑、删除确认、稳定标识符、后端」的顺序逐项补齐。10. 测试与构建先静态分析再 Widget Test最后生产构建依次执行flutter analyze flutter test flutter build webflutter analyze做静态分析检查代码中的类型与使用问题flutter test运行测试。建议让 AI 增加一条用户流程测试请写一个 Widget Test打开首页点击「记一笔」确认费用说明、金额和保存按钮出现。表单校验稳定后再补请测试空表单不能保存并能看见两个错误提示。本页临时项目实际执行结果为flutter analyze没有发现问题Widget Test 通过 1 项验证了首页能够显示并打开录入表单。空表单提示与本机恢复则通过浏览器实际操作验证但尚未写成完整自动化测试——教程不会把它们冒充为测试套件已覆盖的内容。flutter build web生成生产构建产物位于build/web。本页实际执行成功随后通过本地静态服务器打开该生产构建完成了录入、错误反馈、保存和刷新恢复测试。注意应通过服务器检查构建产物而不是双击 HTML 文件。11. 移动端必须分别打开验证Web 运行通过后回到flutter devicesAndroid 模拟器出现后运行flutter run -d Android 设备编号Mac 装好 iOS Simulator Runtime 后再选择 iPhone 模拟器flutter run -d iPhone 模拟器编号两端至少重新检查中文与金额在大字体下是否溢出、底部表单是否被软键盘遮住、返回手势能否正常关闭表单、应用彻底关闭再打开后本机记录是否恢复、相机/照片/通知权限被拒绝时会发生什么、断网与恢复网络以及重复重试会不会丢单或生成重复记录。这一步在本文写作时尚未完成当时的flutter doctor找不到 Android SDKXcode 也没有可用的 iOS Simulator Runtime且项目使用了需要 CocoaPods 的插件。移动端截图不能用 Web 截图替代——准备好对应环境后应补上 Android 模拟器、iOS 模拟器和至少一台真机的运行截图。12. 构建与发布是两条独立流水线Web 生产构建用flutter build web。Android 上架一般生成 App Bundleflutter build appbundle它仍然需要 Android SDK、应用编号、版本号、发布签名和商店控制台配置。iOS 发布在 Mac 上完成flutter build ipa它需要 Xcode、签名证书、Provisioning Profile、唯一 Bundle ID 和 App Store Connect生成 IPA 之后还要 Validate、上传 TestFlight、测试并提交审核。两个商店的隐私说明、截图、审核规则和账号都不同推送、内购和登录也有平台政策差异。「一套 Dart 代码」不会生成一个同时提交给两个商店的万能安装包。13. 原型跑通的标准一笔费用能保存、能恢复回头看这个小费用簿它已经不只是几张静态卡片空表单会告诉用户哪里不对保存以后汇总和列表一起更新页面明确区分本机保存与服务器同步刷新整个应用以后新记录还在。下一步不必急着加图表和十几个入口。如果准备给真实门店试用先接一套测试后端只做「上传一笔费用」和「失败后重试」再用两个账号检查门店隔离用飞行模式检查离线队列。等这条链路稳定再增加小票、审批和统计。Flutter 真正省事的地方是 Android 和 iOS 可以共同维护这条业务链路真正不能省的仍然是两端设备、权限、签名、商店和失败场景的逐项验证。本指南对应的完整中文实操版本见 docs/zh-cn/stage-3/cross-platform/flutter-app/index.md其中还包含自适应布局、Platform Channel 接入原生能力与 View/ViewModel/Repository/Service 分层等进阶内容可作为后续深入的企业级扩展参考。赞分享教程文档【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址https://gitcode.com/datawhalechina/easy-vibe点击查看免费下载相关推荐easy-vibe 跨平台实战用 Flutter 与 Vibe Coding 从零构建门店费用簿应用easy vibe 跨平台实战用 Flutter 与 Vibe Coding 从零构建门店费用簿应用 本文是 easy vibe 教程「高级开发 · 跨平台」教程文档人工智能Vibe Codingeasy-vibe 跨平台实战用 Flutter 从 0 到 1 开发门店费用簿应用easy vibe 跨平台实战用 Flutter 从 0 到 1 开发门店费用簿应用 本指南以 easy vibe 项目第三阶段「跨平台开发」中的 Flutt教程文档用 Flutter 开发跨平台应用从门店费用簿原型到可验证的多端构建用 Flutter 开发跨平台应用从门店费用簿原型到可验证的多端构建 Flutter 可以用一套 Dart 代码同时产出 Android、iOS 与 Web教程文档人工智能Vibe Coding上一篇ProperTree终极指南跨平台Plist编辑器的完整使用教程下一篇在Docker中运行Synology DSMVirtual DSM完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考