企业官网建设流程全解析

• 教程
• 文档

本指南基于 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 -v

flutter 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 SDK；Xcode 已安装，却没有可用的 iOS Simulator Runtime，CocoaPods 也未安装。因此后续截图全部来自实际运行的 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 web

• flutter analyze做静态分析，检查代码中的类型与使用问题；
• flutter test运行测试。建议让 AI 增加一条用户流程测试：

请写一个 Widget Test：打开首页，点击「记一笔」，确认费用说明、金额和保存按钮出现。

表单校验稳定后再补：请测试空表单不能保存，并能看见两个错误提示。

本页临时项目实际执行结果为：flutter analyze没有发现问题；Widget Test 通过 1 项，验证了首页能够显示并打开录入表单。空表单提示与本机恢复则通过浏览器实际操作验证，但尚未写成完整自动化测试——教程不会把它们冒充为测试套件已覆盖的内容。

• flutter build web生成生产构建，产物位于build/web。本页实际执行成功，随后通过本地静态服务器打开该生产构建，完成了录入、错误反馈、保存和刷新恢复测试。注意应通过服务器检查构建产物，而不是双击 HTML 文件。

11. 移动端必须分别打开验证

Web 运行通过后，回到：

flutter devices

Android 模拟器出现后运行：

flutter run -d <Android 设备编号>

Mac 装好 iOS Simulator Runtime 后，再选择 iPhone 模拟器：

flutter run -d <iPhone 模拟器编号>

两端至少重新检查：中文与金额在大字体下是否溢出、底部表单是否被软键盘遮住、返回手势能否正常关闭表单、应用彻底关闭再打开后本机记录是否恢复、相机/照片/通知权限被拒绝时会发生什么、断网与恢复网络以及重复重试会不会丢单或生成重复记录。

这一步在本文写作时尚未完成：当时的flutter doctor找不到 Android SDK，Xcode 也没有可用的 iOS Simulator Runtime，且项目使用了需要 CocoaPods 的插件。移动端截图不能用 Web 截图替代——准备好对应环境后，应补上 Android 模拟器、iOS 模拟器和至少一台真机的运行截图。

12. 构建与发布是两条独立流水线

Web 生产构建用flutter build web。Android 上架一般生成 App Bundle：

flutter 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 分层等进阶内容，可作为后续深入的企业级扩展参考。

• 教程
• 文档