企业官网建设流程全解析

• 前端
• 开发工具

导读

本指南以仓库内 .agent/skills/mobile-design/decision-trees.md 为核心，系统讲解移动端项目（iOS / Android / 跨平台）在架构起航阶段必须做出的五类关键决策：框架选型、状态管理、导航模式、存储策略、离线与认证方案。文档在仓库中的定位是mobile-design技能包（.agent/skills/mobile-design/SKILL.md）的决策参考文件，配套 mobile-design-thinking.md、mobile-navigation.md、mobile-backend.md 等深度参考，并被mobile-developer智能体（见 .agent/ARCHITECTURE.md）在移动端开发任务中按需加载。读完本文，你将掌握一套"先问需求、再选技术"的决策框架，能够根据 OTA 更新诉求、UI 一致性要求、离线依赖程度等真实约束，为任意移动端项目搭出可落地、可扩展的技术栈。

重要定位：这套决策树是思考指南（THINKING guides），不是可直接照抄的答案（copy-paste answers）。文档开篇即强调：每个项目都有独特的约束，需求模糊时必须先向用户提出澄清问题，依据实际需要而非默认习惯做选择。

一、第一层决策：框架选型（Framework Selection）

框架选择是移动端架构的"总开关"，它决定了后续所有模式与工具链的可用范围。原文档给出了一张主决策树（Master Decision Tree），以下是其完整逻辑：

WHAT ARE YOU BUILDING? │ ├── Need OTA updates without app store review? │ │ │ ├── Yes → React Native + Expo │ │ ├── Expo Go for development │ │ ├── EAS Update for production OTA │ │ └── Best for: rapid iteration, web teams │ │ │ └── No → Continue ▼ │ ├── Need pixel-perfect custom UI across platforms? │ │ │ ├── Yes → Flutter │ │ ├── Custom rendering engine │ │ ├── Single UI for iOS + Android │ │ └── Best for: branded, visual apps │ │ │ └── No → Continue ▼ │ ├── Heavy native features (ARKit, HealthKit, specific sensors)? │ │ │ ├── iOS only → SwiftUI / UIKit │ │ └── Maximum native capability │ │ │ ├── Android only → Kotlin + Jetpack Compose │ │ └── Maximum native capability │ │ │ └── Both → Consider native with shared logic │ └── Kotlin Multiplatform for shared │ ├── Existing web team + TypeScript codebase? │ │ │ └── Yes → React Native │ ├── Familiar paradigm for React devs │ ├── Share code with web (limited) │ └── Large ecosystem │ └── Enterprise with existing Flutter team? │ └── Yes → Flutter └── Leverage existing expertise

框架横向对比

对比表揭示了一个容易被忽略的核心权衡：Flutter 的双端 UI 完全一致，是以放弃平台原生视觉语言为代价的；而 React Native 更接近"用 Web 团队熟悉的范式写移动应用"，其 OTA 能力（Expo EAS Update）是另外两大路线不具备的差异化优势。

何时选原生（Native）

CHOOSE NATIVE WHEN: ├── 需要极致性能（游戏、3D） ├── 需要深度 OS 集成 ├── 平台专属功能是核心卖点 ├── 团队具备原生开发经验 ├── App Store 是主要分发渠道 └── 长期维护优先级高 AVOID NATIVE WHEN: ├── 预算/时间有限 ├── 需要快速迭代 ├── 双端需要完全一致的 UI ├── 团队以 Web 技术为主 └── 跨平台是首要诉求

仓库中的配套佐证

• 框架决策树在技能包中的位置：.agent/skills/mobile-design/SKILL.md 末尾的 "Framework Decision Tree" 是本文档的精简版，并明确指引"完整决策树见 decision-trees.md"（相对链接已指向本文档，SKILL.md 中亦有对应条目）。
• React Native 参考栈：.agent/skills/app-builder/templates/react-native-app/TEMPLATE.md 给出了与决策树一致的具体组合：React Native + Expo 框架、TypeScript 语言、Expo Router 导航、Zustand + React Query 状态、NativeWind 样式、Jest + RNTL 测试，可作为选型后的脚手架蓝本。
• 框架选择与智能体职责的对应：.agent/ARCHITECTURE.md 中mobile-developer智能体的职责被定义为 "iOS, Android, RN"，使用的技能正是mobile-design，说明该决策树是实际开发流程中被强制加载的决策依据。

二、第二层决策：状态管理选型（State Management Selection）

选定框架后，下一个关键决策是状态管理。原文档分别针对 React Native 与 Flutter 给出了两棵决策树。

React Native 状态决策树

WHAT'S YOUR STATE COMPLEXITY? │ ├── 简单应用、页面少、共享状态极少 │ │ │ └── Zustand（或直接用 useState/Context） │ ├── 样板代码最少 │ ├── 易于理解 │ └── 可扩展至中型应用 │ ├── 以服务端数据为主（API 驱动） │ │ │ └── TanStack Query (React Query) + Zustand │ ├── Query 管服务端状态 │ ├── Zustand 管 UI 状态 │ └── 优秀的缓存与自动重取能力 │ ├── 功能复杂的大型应用 │ │ │ └── Redux Toolkit + RTK Query │ ├── 可预测、可调试 │ ├── RTK Query 负责 API │ └── 适合大型团队 │ └── 原子化、细粒度状态需求 │ └── Jotai ├── 基于 atom（类似 Recoil） ├── 最小化重渲染 └── 擅长派生状态

Flutter 状态决策树

WHAT'S YOUR STATE COMPLEXITY? │ ├── 简单应用、正在学习 Flutter │ │ │ └── Provider（或 setState） │ ├── 官方方案、简单 │ ├── Flutter 内置 │ └── 适合小应用 │ ├── 现代、类型安全、可测试 │ │ │ └── Riverpod 2.0 │ ├── 编译期安全 │ ├── 代码生成 │ ├── 非常适合中大型应用 │ └── 新项目推荐 │ ├── 企业级、需要严格模式 │ │ │ └── BLoC │ ├── Event → State 模式 │ ├── 非常可测试 │ ├── 样板代码较多 │ └── 适合大型团队 │ └── 快速原型 │ └── GetX（谨慎使用） ├── 实现快 ├── 模式约束弱 └── 大规模时容易失控

状态管理反模式清单

❌ 不要： ├── 用全局状态管理一切 ├── 混用多种状态管理方案 ├── 把服务端状态存进本地状态 ├── 跳过状态归一化（normalization） ├── 滥用 Context（重渲染开销大） └── 把导航状态放进应用状态 ✅ 要做： ├── 服务端状态 → 交给 Query 库 ├── UI 状态 → 尽量局部、本地优先 ├── 仅在必要时提升（lift）状态 ├── 每个项目只选一种方案 └── 让状态保持在它被使用的地方附近

仓库中的配套佐证

• "服务端状态交给 Query 库"与 React Native 模板一致：.agent/skills/app-builder/templates/react-native-app/TEMPLATE.md 明确列出zustand（本地状态）与@tanstack/react-query（服务端状态）的分工，正是决策树"Query 管服务端、Zustand 管 UI"的落地形态。
• "不要滥用 Context"的深层原因：状态管理之所以强调"最小化重渲染"，是因为移动端渲染性能直接关系到 60fps 流畅度——.agent/skills/mobile-design/mobile-performance.md 指出每帧必须在 16.67ms（60fps）内完成，超时即掉帧、产生卡顿感知。Context 变化引发的大范围重渲染正是移动端常见的性能杀手。
• "混用方案"反模式的额外佐证：.agent/skills/mobile-design/mobile-design-thinking.md 的 Pattern Questioning Matrix 对状态默认项提出同样质疑，例如"Redux everywhere？→ 简单应用用 Zustand；服务端用 TanStack Query"。

三、导航模式选型（Navigation Pattern Selection）

导航是应用的骨架。原文档以"顶层目的地数量"为第一判断维度，给出了清晰的决策树：

HOW MANY TOP-LEVEL DESTINATIONS? │ ├── 2 个目的地 │ └── 考虑：顶部 Tab 或简单 Stack │ ├── 3-5 个目的地（重要性相当） │ └── ✅ Tab Bar / 底部导航 │ ├── 最常见模式 │ └── 易于发现 │ ├── 5+ 个目的地 │ │ │ ├── 全部重要 → Drawer 导航 │ │ └── 隐藏但选项多 │ │ │ └── 部分次要 → Tab bar + drawer 混合 │ └── 单一线性流程？ └── 仅 Stack 导航 └── 引导注册、结算流程等

按应用类型的导航模式速查

仓库中的配套佐证

• 导航决策树的完整版：.agent/skills/mobile-design/mobile-navigation.md 以"应用类型"为入口给出了与之互补的另一棵决策树（3-5 个同等重要分区 → Tab Bar；深度层级内容 → Stack；超 5 个顶层目的地 → Drawer；单一线性流程 → 仅 Stack；平板/折叠屏 → Navigation Rail + 列表-详情），并深入展开 Tab 状态保持（每个 Tab 维护独立导航栈）、返回键处理（iOS 边缘右滑 vs Android 系统返回）、深链导航规则等细节，可作为本节的进阶阅读。
• "Tab 状态保持"是决策树未展开的隐性要求：原文档"导航模式"一节虽短，但其背后遵循的原则——切换 Tab 不重置栈、返回永远沿栈向上、不得劫持返回键——都在 .agent/skills/mobile-design/mobile-navigation.md 中被列为硬性规则（如 "Back ALWAYS navigates up the stack"、Never hijack back for other purposes）。

四、存储策略选型（Storage Strategy Selection）

存储决策应当按数据类型分门别类，而不是"一个方案打天下"。原文档给出的决策树：

WHAT TYPE OF DATA? │ ├── 敏感数据（令牌、密码、密钥） │ │ │ └── ✅ 安全存储（Secure Storage） │ ├── iOS: Keychain │ ├── Android: EncryptedSharedPreferences │ └── RN: expo-secure-store / react-native-keychain │ ├── 用户偏好（设置、主题） │ │ │ └── ✅ 键值存储（Key-Value Storage） │ ├── iOS: UserDefaults │ ├── Android: SharedPreferences │ └── RN: AsyncStorage / MMKV │ ├── 结构化数据（实体、关系） │ │ │ └── ✅ 数据库（Database） │ ├── SQLite（expo-sqlite, sqflite） │ ├── Realm（NoSQL, 响应式） │ └── WatermelonDB（大数据集） │ ├── 大文件（图片、文档） │ │ │ └── ✅ 文件系统（File System） │ ├── iOS: Documents / Caches 目录 │ ├── Android: 内部/外部存储 │ └── RN: react-native-fs / expo-file-system │ └── API 缓存数据 │ └── ✅ Query 库缓存 ├── TanStack Query（RN） ├── Riverpod async（Flutter） └── 自动失效机制

存储方案对比

仓库中的配套佐证

• "令牌必须安全存储"在技能包中被上升为强制纪律：.agent/skills/mobile-design/SKILL.md 的 "Security Sins" 表格将"Token in AsyncStorage"列为绝不许可的行为，正确做法是SecureStore/Keychain/EncryptedSharedPreferences；.agent/skills/mobile-design/mobile-backend.md 进一步给出令牌分层策略（短生命周期 access token 存内存、长生命周期 refresh token 存 SecureStore/Keychain 并每次使用轮换）。
• RN 模板中的存储落地：.agent/skills/app-builder/templates/react-native-app/TEMPLATE.md 的存储组件明确为Expo SecureStore，与决策树的安全存储分支完全对应。

五、离线策略选型（Offline Strategy Selection）

离线能力是移动应用区别于 Web 应用的核心约束之一。原文档按"离线的重要性"划分三档：

HOW CRITICAL IS OFFLINE? │ ├── 锦上添花（有网时正常用即可） │ │ │ └── 缓存最近数据 + 展示过期数据 │ ├── 实现简单 │ ├── TanStack Query + staleTime │ └── 显示"最后更新时间" │ ├── 核心功能必须离线可用 │ │ │ └── Offline-first 架构 │ ├── 本地数据库作为数据源（source of truth） │ ├── 联网后同步到服务端 │ ├── 制定冲突解决策略 │ └── 操作入队等待后续同步 │ └── 实时性至关重要（协作、聊天） │ └── WebSocket + 本地队列 ├── 乐观更新 ├── 最终一致性 └── 复杂的冲突处理

四种离线实现模式

1. CACHE-FIRST（简单） 请求 → 查缓存 → 若过期则拉取 → 更新缓存 2. STALE-WHILE-REVALIDATE 请求 → 先返回缓存 → 后台拉取更新 → 更新 UI 3. OFFLINE-FIRST（复杂） 操作 → 写入本地数据库 → 入同步队列 → 联网时同步 4. SYNC ENGINE（同步引擎） 使用：Firebase、Realm Sync、Supabase realtime 自动处理冲突解决

仓库中的配套佐证

• 冲突解决策略的展开：.agent/skills/mobile-design/mobile-backend.md 给出了与"Offline-first"配套的冲突解决策略谱系——Last-write-wins（简单数据、单用户）、Server-wins（关键交易）、Client-wins（重度离线应用）、Merge（文档类按字段合并）、CRDT（实时协作），并给出了客户端同步队列的标准流程：本地写入 → 入队{ action, data, timestamp, retries }→ 有网时 FIFO 处理 → 失败指数退避重试（最多 5 次）→ 冲突按策略解决。
• "展示最后更新时间"的缓存细节：对"锦上添花"档，.agent/skills/mobile-design/mobile-backend.md 补充了只读数据（新闻、目录）应使用"简单缓存 + TTL + ETag/Last-Modified 失效"的具体实现，让"缓存最后数据"这一原则可落地。

六、认证模式选型（Authentication Pattern Selection）

认证决策树以"需要何种认证"为入口：

WHAT AUTH TYPE NEEDED? │ ├── 简单邮箱/密码 │ │ │ └── 基于令牌（JWT） │ ├── refresh token 安全存储 │ ├── access token 存内存 │ └── 静默刷新流程 │ ├── 社交登录（Google、Apple 等） │ │ │ └── OAuth 2.0 + PKCE │ ├── 使用平台 SDK │ ├── Deep link 回调 │ └── iOS 必须接入 Apple Sign-In │ ├── 企业级/SSO │ │ │ └── OIDC / SAML │ ├── WebView 或系统浏览器 │ └── 正确处理重定向 │ └── 生物识别（FaceID、指纹） │ └── 本地认证 + 安全令牌 ├── 生物识别解锁存储的令牌 ├── 不能替代服务端认证 └── 提供 PIN/密码回退

令牌存储的红线与正确做法

❌ 绝不把令牌存在： ├── AsyncStorage（明文） ├── Redux/state（未正确持久化） ├── 等价于本地存储的地方 └── 日志或调试输出 ✅ 令牌永远存在： ├── iOS: Keychain ├── Android: EncryptedSharedPreferences ├── Expo: SecureStore ├── 支持生物识别保护则优先

仓库中的配套佐证

• 静默刷新流程的完整逻辑：.agent/skills/mobile-design/mobile-backend.md 补充了原文档未展开的静默再认证请求流：携带 access token 请求 → 收到 401 → 有 refresh token 则调用/auth/refresh→ 成功则重试原请求、失败则强制登出；并给出三层令牌模型（access / refresh / device token），其中 device token 用于支持"登出所有设备"。
• "不用 AsyncStorage 存令牌"与安全纪律一致：这与第四节存储策略、.agent/skills/mobile-design/SKILL.md 的 Security Sins 表完全闭环——三处文档对同一规则反复强调，可见该约束在技能体系中的重要级别。

七、项目类型模板（Project Type Templates）

决策树的价值在于组合应用。原文档给出三类典型项目的推荐栈，可直接作为选型后的总装清单。

电商应用（E-Commerce App）

RECOMMENDED STACK: ├── 框架: React Native + Expo（定价策略需要 OTA） ├── 导航: Tab bar（首页、搜索、购物车、账户） ├── 状态: TanStack Query（商品）+ Zustand（购物车） ├── 存储: SecureStore（认证）+ SQLite（购物车缓存） ├── 离线: 缓存商品、购物车操作入队 └── 认证: 邮箱/密码 + 社交登录 + Apple Pay KEY DECISIONS: ├── 商品图片: 懒加载、积极缓存 ├── 购物车: 通过 API 跨设备同步 ├── 结算: 安全、步骤最少 └── 深链: 商品分享、营销活动

社交/内容应用（Social/Content App）

RECOMMENDED STACK: ├── 框架: React Native 或 Flutter ├── 导航: Tab bar（动态流、搜索、发布、通知、个人主页） ├── 状态: TanStack Query（动态流）+ Zustand（UI） ├── 存储: SQLite（动态流缓存、草稿） ├── 离线: 缓存动态流、发布操作入队 └── 认证: 以社交登录为主，Apple 登录必需 KEY DECISIONS: ├── 动态流: 无限滚动、列表项记忆化 ├── 媒体: 上传队列、后台上传 ├── 推送: 深链到具体内容 └── 实时: WebSocket 推送通知

生产力/SaaS 应用（Productivity/SaaS App）

RECOMMENDED STACK: ├── 框架: Flutter（UI 一致）或 RN ├── 导航: Drawer 或 Tab bar ├── 状态: Riverpod/BLoC 或 Redux Toolkit ├── 存储: SQLite（离线）、SecureStore（认证） ├── 离线: 全量离线编辑 + 同步 └── 认证: 企业级 SSO/OIDC KEY DECISIONS: ├── 数据同步: 冲突解决策略 ├── 协作: 实时还是最终一致？ ├── 文件: 大文件处理 └── 企业: MDM、合规要求

仓库中的配套佐证

• 模板与决策树的组合一致性：三类模板恰好分别示范了不同决策路径的组合结果——电商选择了"OTA 优先"路径（RN + Expo），生产力应用选择了"UI 一致性优先"路径（Flutter），与第一节主决策树的分支逻辑一一对应。
• 更多应用类型的决策细化：.agent/skills/mobile-design/mobile-design-thinking.md 的 "CONTEXT-BASED DECISION PROTOCOL" 还补充了 Utility（工具类，可仅 Stack 导航、快速启动优先）与 Media/Streaming（媒体流，横向轮播 + 预加载 + 后台播放）两类应用的差异化决策点。

八、决策清单与澄清问题（Decision Checklist & Questions to Ask User）

任何项目启动前的检查清单

• 目标平台已定义（iOS/Android/双端）？
• 已基于标准完成框架选择？
• 已确定状态管理方案？
• 已选定导航模式？
• 每种数据类型都有存储策略？
• 已明确离线需求？
• 已设计认证流程？
• 从一开始就规划了深链（deep linking）？

项目需求模糊时必须向用户提出的问题

If project details are vague, ASK: 1. "是否需要不经过应用商店审核的 OTA 更新？" → 影响框架选择（Expo = 可以） 2. "iOS 和 Android 是否需要完全一致的 UI？" → 影响框架（Flutter = 一致） 3. "离线需求是什么？" → 影响架构复杂度 4. "是否已有后端/认证系统？" → 影响认证与 API 方案 5. "目标设备？仅手机，还是需要平板？" → 影响导航与布局 6. "企业级还是消费级？" → 影响认证（SSO）、安全、合规

仓库中的配套佐证

• "先问再做"是技能包的强制要求：.agent/skills/mobile-design/SKILL.md 设有专门章节 "CRITICAL: ASK BEFORE ASSUMING (MANDATORY)"，要求当用户需求开放式时必须询问平台、框架、导航、状态管理、离线、目标设备六项；mobile-design-thinking.md的 "MOBILE DESIGN COMMITMENT" 也要求开工前填写项目平台、将避免的默认模式、平台差异等承诺项——填不出来就说明对项目理解不足，应回头补调研。
• 深链必须"从第一天规划"：原文档清单强调 deep linking 前置规划，.agent/skills/mobile-design/mobile-navigation.md 从反面印证了这一点——"后来再补深链很难：需要导航重构、屏幕依赖不清晰、参数传递复杂"，并给出 URL 结构应镜像导航层级（如myapp://home/product/123/reviews）的规范。

九、反模式决策（Anti-Pattern Decisions）

常见决策反模式速查

仓库中的配套佐证

• 反模式清单的体系化呼应：这张表与 .agent/skills/mobile-design/SKILL.md 的 "AI MOBILE ANTI-PATTERNS" 清单（性能罪、触控/UX 罪、安全罪、架构罪四大类）以及mobile-design-thinking.md的 "AI MOBILE SAFE HARBOR" 默认模式警告（Tab bar 就用到底、Redux 到处都是、FlatList 一律默认等）构成了完整的"反默认"防御体系。三者共同传达的核心信息是：选型必须基于项目上下文，而非训练数据中的流行默认值。
• "按项目评估"与智能体架构的配合：.agent/ARCHITECTURE.md中 16 个专职智能体按领域拆分（mobile-developer用mobile-design技能），其设计意图正是让每个决策都发生在对应的上下文里，避免"同一套栈套用所有项目"。

十、快速参考（Quick Reference）

框架快速选择

需要 OTA？ → React Native + Expo 需要双端一致 UI？ → Flutter 追求极致性能？ → 原生 有 Web 团队？ → React Native 快速原型？ → Expo

状态管理快速选择

简单应用？ → Zustand / Provider 服务端数据为主？ → TanStack Query / Riverpod 企业级？ → Redux / BLoC 原子化状态？ → Jotai

存储快速选择

密钥类？ → SecureStore / Keychain 设置项？ → AsyncStorage / UserDefaults 结构化数据？ → SQLite API 缓存？ → Query 库

结语：决策树是思考框架，不是答案库

原文档在结尾给出了最重要的提醒，值得在落地时反复回味：

Remember:These trees are guides for THINKING, not rules to follow blindly. Every project has unique constraints. ASK clarifying questions when requirements are vague, and choose based on actual needs, not defaults.

结合仓库中与之配套的 .agent/skills/mobile-design/mobile-design-thinking.md 与 .agent/skills/mobile-design/SKILL.md，可以提炼出完整的落地方法：先用本文的决策树锚定"该选什么"的方向，再用思考协议对每个默认选择提出质疑（为什么选它？有没有替代？性能影响是什么？平台差异在哪？），最后用澄清问题确认项目真实约束。这套"决策树 + 反默认质疑 + 澄清提问"的组合，正是让移动端架构选型从"拍脑袋"走向"可论证"的关键路径。

• 前端
• 开发工具