7.3 Web 与桌面落地的差异处理

7.3 Web 与桌面落地的差异处理

本节摘要：第 1 章说过宿主壳模式让"换端"很便宜，但便宜不等于零成本。本节盘点 Web 与桌面两个端的真实差异落点：Web 端的渲染模式选择、存储降级、路由与地址栏、跨域与首帧成本；桌面端的窗口与菜单、键鼠交互习惯与分发方式。读完你将拿到一张"上新端之前逐项核对"的差异清单，而不是到线上才发现踩坑。

Web 端：最特殊的宿主

Web 是六端里唯一"代码形态都变了"的端：Dart 被编译成 JavaScript，像素画在浏览器画布上。三个差异必须在立项时想清楚。

渲染模式二选一。 画布模式（CanvasKit/skwasm）把整套图形栈编进产物，像素级一致、动效最顺，代价是首帧下载量大、加载时间对弱网用户很不友好；HTML 模式用浏览器元素渲染，产物轻、可选中可检索，代价是观感与动效的一致性让位于浏览器实现。轻记账的判断：后台管理向的轻记账 Web 版选画布模式——用户是登录后的记账者，首屏多等一秒可接受，操作流畅度不可妥协；若做面向搜索引擎的内容页，画布模式等于 SEO 空白（画布上的文字搜索引擎读不到），那条产品线就不该用 Flutter。

存储要降级。 第 4 章选的 sqflite 在 Web 上没有原生实现，落点是浏览器存储（键值走 localStorage，结构化数据走 IndexedDB 封装）。仓库模式再次救场：Web 端注入 Web 版仓库实现，业务代码零改动。判断口径也顺带回顾第 4 章那把尺子——Web 上轻记账只需"离线也能看本周账单"，IndexedDB 足够，不必引入更重的方案。

// 仓库工厂按端注入，上层业务永远只见 BillRepository 接口
BillRepository createRepository() {
  if (kIsWeb) {
    return IndexedDbBillRepository();   // Web：浏览器存储封装
  }
  return DbBillRepository();            // 移动与桌面：sqflite
}
​

网络与路由各有一坎。 网络的坎是跨域：浏览器的同源策略要求服务端显式允许跨源请求，移动端从不存在的这道门在 Web 上必须服务端配合打开——联调前先确认，别等前端一个人对着控制台报错排查半天。路由的坎是地址栏：第 4 章的声明式路由表在 Web 上自动获得真实地址与浏览器前进后退，这正是当时选声明式的回报时刻；再配一句地址隐藏（去掉路径里的井号），分享出去的链接才体面。

桌面端：老玩家的主场，新交互的规矩

桌面端代码形态与移动一致（AOT 本机码），机制零改动，差异全在交互习惯与产品形态上。

窗口、菜单与生命周期。 移动端没有的概念在桌面全是标配：窗口可缩放（布局要真正响应宽度变化，第 3 章的约束系统这次是主角而非配角）、菜单栏、关闭按钮（关闭是退出还是最小化到托盘，要跟平台习惯走）。窗口标题、最小尺寸、初始位置都有现成的窗口插件管理，但布局响应式只能自己练：同一页面在 400 像素宽的窗口要单列，1600 像素宽要双栏——用 LayoutBuilder 按宽度断点切换骨架：

LayoutBuilder(builder: (context, constraints) {
  final wide = constraints.maxWidth >= 900;
  return wide
      ? Row(children: [const SizedBox(width: 320, child: BillListPane()), Expanded(child: const DetailPane())])
      : const BillListPane(); // 窄窗口退化为单列
})
​

键鼠交互的规矩。 悬停态要给（桌面用户靠悬停预判可点击），右键菜单按场景补，列表要支持键盘上下移动与回车确认，滚动条在长内容上默认可见——这些移动端不存在的习惯，桌面用户视为理所当然。Flutter 的桌面化组件（可选中的文本、悬停效果、滚动条）已备好物料，缺的是你记得用。

分发方式完全不同。 没有应用商店托底的平台，更新机制要自己设计：Windows 走安装器加自更新检查，macOS 面对公证与签名流程，Linux 多格式分发。轻记账桌面的务实路线是先做内部工具版（安装器直发同事），验证价值后再投入自动更新体系——桌面版的服务对象常常是"重度用户"，迭代压力小于移动端，发布节奏可以保守。

差异清单：上端之前逐项核对

把两端的差异收进一张核对表，每次上端过一遍：

这张表的用法是逐行问"我这端要怎么办"，答不出来的行就是上线前必须解决的事项。差异清单的最大价值不在记住答案，而在把"多端落地"从一句愿景拆成可勾选的工程项——第 1 章选型时承诺的"边际成本很低"，到这一章是它接受审计的时刻。

Web 部署三件小事

部署 Web 版比移动端省心，但有三件小事值得提前做。其一，缓存策略：构建产物的文件名带哈希，静态资源可以放心长缓存，但入口页本身必须不缓存——否则用户拿到的是旧入口，加载的还是旧哈希的产物，"发了版用户看不到"的工单多半源于此。其二，产物体积核对：画布模式的产物体积在构建日志里一目了然，把首帧下载量写进发布检查单，防止某次依赖引入悄悄翻倍。其三，浏览器兼容基线：项目声明的浏览器支持范围要写进文档，画布模式依赖较新的浏览器特性，老浏览器的降级方案（提示升级还是拒绝服务）要提前定，别等客服转来第一张截图才发现。

桌面端同样有一件容易忘的事：崩溃与日志的落点。移动端有商店与系统级的崩溃通道，桌面版的崩溃落盘与上报要自己接——复用第 6 章的监控通道即可，但要明确桌面版的崩溃报告同样进同一块看板，两个端各自为政的监控迟早漏掉一端的事故。

决策回顾：第 1 章的判断在四端还成立吗

收个尾。第 1 章给过选型判断："界面形式多、迭代快的业务应用适合 Flutter"。走到四端再看这句话，它要加一条注释：移动与桌面上这句话几乎无条件成立（同一份 AOT 产物，机制零分叉）；Web 上成立与否取决于产品形态——操作型应用（轻记账 Web 版）成立，内容型应用（靠搜索流量的页面）不成立；嵌入场景下成立与否取决于存量工程的健康度——壳要能托得住，Flutter 才有发挥余地。把第 1 章的判断表拿出来，逐行加上这半年的四端注释，你会得到一份比任何通用文章都可靠的、属于你们项目的选型档案——这正是"落地记录"视角的初衷。

本节要点回顾

• Web 代码形态都变了：渲染模式按"内容型还是操作型"选，画布模式与 SEO 互斥；
• Web 存储降级走仓库工厂按端注入，业务零改动；跨域要服务端放行，联调前确认；
• 声明式路由在 Web 上自动获得地址栏与前进后退，是第 4 章决策的回报时刻；
• 桌面差异在交互与形态：响应式布局、键鼠习惯、分发与自更新自己扛；
• 差异核对表逐行过，答不出的行就是上线前必须解决的事项。

四端的差异都处理完了。最后一节收口：工程怎么组织、四端怎么签名构建、上架物料与发布后监控，把整本书的落地之旅画上句号。