企业官网建设流程全解析

做了两年多的移动端 IM，年初接了个新需求：要把整套 IM 客户端搬到 Windows 和 macOS 桌面端。当时第一反应是好事，毕竟 Flutter 一套代码多端复用的诱惑确实大，但真正动手之后才发现，桌面端和移动端看着像，实际开发起来完全不是一回事。

这篇文章就复盘一下我在这套 Flutter IM 桌面端项目里做的几个核心设计——整体架构怎么搭、聊天窗口布局怎么拆、WebSocket 长连接怎么设计才稳。里面不会有大而全的框架介绍，全是自己调研、写代码、踩坑、重构之后沉淀下来的实操经验，希望对要入坑 Flutter 桌面端 IM 的朋友有点参考价值。

1. 项目架构设计与状态管理选型

1.1 为什么放弃了 Provider 换成 Riverpod

桌面端 IM 和移动端有个很大的区别：窗口可以同时打开多个会话，每个会话窗口都有自己的滚动位置、输入状态、未读计数和消息流，而这些状态之间还需要互相联动。比如我在会话 A 里读到一条消息，会话列表里的未读数要立刻减一，这个联动用传统的 Provider + ChangeNotifier 做起来非常别扭，因为 ChangeNotifier 本身是命令式的，状态变更要靠手动调用 notifyListeners，页面一多、状态一多，很容易出现忘记通知或者重复通知的问题。

后来我把状态管理层换成了 Riverpod，选它的核心理由有三个：

第一，Riverpod 的 Provider 是全局可声明的，配合ConsumerWidget可以做到非常细粒度的依赖注入，一个窗口只 rebuild 自己关心的那部分状态，不至于像Provider.of<T>(context)那样动不动 rebuild 整棵 widget 树。

第二，Riverpod 天然支持异步状态。IM 里到处都是异步操作：拉取历史消息、发送消息、获取未读数，用AsyncNotifierProvider可以直接把加载态、错误态都表达在状态里，省掉了一堆手动管理 loading flag 的样板代码。

第三，Riverpod 在测试场景下太香了。ProviderContainer可以脱离 widget 树直接做状态测试，这对 IM 这种状态逻辑极其复杂的项目来说是刚需，光消息重排和未读联动这两个状态，我用纯 Dart 的单元测试就覆盖了大部分核心路径。

1.2 目录结构怎么分：feature-first 才是 IM 的解法

IM 项目的目录如果按技术分层来写，比如models/、widgets/、pages/、services/、utils/，前期写起来会很爽，什么文件往哪丢一目了然。但项目一旦膨胀到几十个 feature，这种分法就乱了——聊天相关的 model、widget、service 散落在三四个目录，改一个聊天的功能要跨目录来回跳。

所以我最终采用 feature-first 的目录结构，核心是把业务模块做高内聚。每个 feature 下面自己管自己的 models、widgets、repositories 和 providers，跨 feature 共享的才抽到 core 或者 shared 里。

lib/ ├── core/ # 基础设施：网络、数据库、工具、主题 │ ├── network/ # WebSocket 客户端、HTTP client、拦截器 │ ├── db/ # sqflite 封装、消息表结构 │ ├── utils/ # 时间格式化、路径处理等工具函数 │ └── theme/ # 桌面端适配的主题配置 ├── features/ │ ├── auth/ # 登录、注册、会话保持 │ ├── conversation/ # 会话列表、未读管理 │ ├── chat/ # 聊天窗口主功能 │ │ ├── models/ # 消息模型、会话模型 │ │ ├── widgets/ # 气泡列表、输入框、表情面板 │ │ ├── repositories/ # 消息收发接口 │ │ ├── providers/ # Riverpod 状态定义 │ │ └── chat_page.dart │ ├── contacts/ # 联系人、好友请求 │ └── settings/ # 设置页、快捷键配置 └── app.dart # 应用入口、全局路由

这种结构在开发桌面端时有一个额外的好处：桌面端每个 feature 都可能需要独立的窗口入口（比如独立的会话窗口、独立的搜索窗口），feature-first 结构天然支持把每个 feature 的页面作为独立入口导出，做多窗口方案时非常顺手。

1.3 跨组件通信：桌面端特有的消息总线机制

移动端 IM 的跨页面通信主要靠路由传参和全局状态，但桌面端的场景不一样，窗口之间是真正的独立，一个会话窗口改了消息状态，另一个窗口得立刻知道。这时候光靠 Riverpod 的全局状态还不够，因为它解决的是数据层面的共享，但"通知某个窗口该刷新了"这种事件，用状态驱动去表达会觉得很勉强。

我们的方案是维护一个轻量级的消息总线，底层就是Stream<AppEvent>，然后用EventBus包装一层。事件类型包括MessageReceived、ConversationUnreadChanged、UserStatusChanged、WindowFocusChanged等。需要跨窗口监听的地方，在 initState 里订阅，在 dispose 里取消，防止窗口关掉了还在收到通知导致内存泄漏。

class AppEventBus { AppEventBus._(); static final AppEventBus instance = AppEventBus._(); final _controller = StreamController<AppEvent>.broadcast(); Stream<T> on<T extends AppEvent>() => _controller.stream.where((event) => event is T).cast<T>(); void fire(AppEvent event) => _controller.add(event); }

这里有个经验教训：事件总线一定只传事件，不要传大对象。我一开始图省事把整条消息模型塞进MessageReceived事件里，结果消息图片多的时候，一次事件分发导致好几个窗口同时解析解码图片数据，界面直接卡顿。后来改成只传消息 ID，窗口自己去本地数据库拉取，性能问题立刻缓解。

2. 桌面端聊天窗口布局的工程化实现

2.1 三栏式布局：会话列表、消息列表、输入区的协作逻辑

桌面端 IM 的布局几乎清一色是三栏式——左侧窄栏放会话列表或导航，中间栏显示聊天对话流，右侧或底部是输入区。别看这个布局常见，用 Flutter 实现时有一些桌面端特有的坑。

我最初的实现是三个Column直接拼在一起，谁的消息状态变了就把自己那个Column包在Consumer里。结果实际用下来发现一个问题：桌面窗口是可以自由拖拽大小的，窗口一窄，会话列表该收起、消息区该变宽，这个自适应逻辑如果写在 build 方法里，拖拽时会疯狂 rebuild。

后来我统一用LayoutBuilder做响应式判断，窗口宽度小于 700 时自动收起左侧导航，只保留图标；大于 1200 时启用双聊窗口模式，可以在右侧再打开一个会话。同时把三个区域的尺寸状态提升到顶层，用 Riverpod 管理，拖拽和折叠只改状态，不 rebuild 兄弟组件。

class ChatScaffold extends ConsumerWidget { @override Widget build(BuildContext context, WidgetRef ref) { final layout = ref.watch(layoutControllerProvider); return Scaffold( body: Row( children: [ if (layout.showConversationList) SizedBox(width: 260, child: ConversationList()), VerticalDivider(width: 1), Expanded( child: Column( children: [ Expanded(child: MessageList()), MessageInputArea(), ], ), ), ], ), ); } }

这个结构看起来简单，但实际动起来要配合很多细节：会话列表宽度要支持拖拽调节，消息列表要维护自己的 ScrollController，输入区的高度要跟随内容自动伸缩。这些细节在后面章节展开。

2.2 消息列表：滚动性能与自动定位的取舍

聊天消息列表是 IM 里最考验性能的部分。移动端几百条消息就够呛，桌面端窗口大、可视区域宽，用户还可能开好几个会话窗口，消息列表稍微卡一下感受非常明显。

我做消息列表用的方案是CustomScrollView+ 按天分组的SliverList。为什么不直接用ListView.builder？因为聊天消息需要按日期分组展示，如果用嵌套Column包多个ListView，滚动手势冲突会让人发疯。CustomScrollView配合SliverList，每个日期分组的 header 和消息 item 都是懒加载渲染，几千条消息滚动也基本无压力。

自动定位这里有个核心难点：当用户打开会话时，通常要定位到最近一条未读消息的位置，同时还要保留"加载更多历史消息"这个操作。我的处理方式是在消息列表顶部和底部各放一个加载指示器，配合 reverse: true 的滚动方向，向下滚动到底部加载更早的历史消息，向上滚动到顶部则自动回到最新消息位置。

CustomScrollView( reverse: true, // 最新消息在底部 controller: _scrollController, slivers: [ SliverToBoxAdapter(child: olderMessageLoader), ...messageSlivers, // 按日期分组 SliverToBoxAdapter(child: unreadDivider), SliverToBoxAdapter(child: newMessageLoader), ], )

实际写的多了之后我总结出一条经验：消息列表的滚动控制器不能只依赖 ScrollController 的默认行为，要自己维护一个消息索引到 offset 的映射，因为消息可能随时插入、删除（比如发送失败重试），纯 offset 定位很快就会错位。

2.3 输入区：多行输入、快捷键与粘贴图片

桌面端输入区和移动端的最大区别是：用户期望它像一个桌面原生文本编辑器，支持快捷键、支持拖拽文件、支持粘贴截图。Flutter 的TextField默认行为其实更接近移动端，不少东西要自己改造。

我用的是TextField包一层自定义Shortcuts+Actions来实现快捷键系统，比如 Enter 发送、Shift+Enter 换行、Ctrl+C 复制、Ctrl+V 粘贴。这里有几个 Windows 和 macOS 平台行为不一致的坑，比如快捷键在 Windows 下是 Ctrl，在 macOS 下是 Command，需要自定义一个isMetaPressed的判断工具类统一处理。

粘贴图片这件事，Flutter 桌面端没有现成的 API，我的方案是用paste_plus插件监听剪贴板变化，当检测到剪贴板里有图片数据时，自动在输入框上方生成图片预览缩略图，点击发送后和文本内容一起走消息发送流程。

class MessageInputArea extends StatefulWidget { // ... } class _MessageInputAreaState extends State<MessageInputArea> { final _focusNode = FocusNode(); final _textController = TextEditingController(); final List<PasteImageItem> _pendingImages = []; void _handleKeyEvent(KeyEvent event) { if (event is KeyDownEvent && _isSendShortcut(event)) { _sendMessage(); } } bool _isSendShortcut(KeyEvent event) { final isMeta = Platform.isWindows ? event.control : event.command; return isMeta && event.key == Key.enter; } }

2.4 文本缩放与 DPI 适配：css rem px 桌面端思路在 Flutter 的映射

开发过 Web 桌面端的同学应该熟悉 css rem 和 px 那套适配逻辑，Flutter 桌面端其实也有类似的需求，只是机制完全不同。Windows 上不同显示器的 DPI 差异很大，同样的逻辑像素，在 100% 缩放下和 150% 缩放下渲染出来的物理尺寸完全不同。

Flutter 默认用逻辑像素（logical pixel）作为单位，理论上它会自动缩放文本，但我实测了不同缩放比例下的表现，发现中文文本在小字号下渲染会有明显发虚——这是因为 Flutter 的文本渲染管线在某些字体下没有做 hinting。

我的适配方案是写了一个全局的AppTextScaler，它读取 MediaQuery 的 textScaler 来做基准缩放，同时对不同消息类型的字体大小做差异化的系数微调。比如时间戳和消息气泡内的文字按 1.0 缩放，会话列表标题按 0.95 缩放，因为标题要紧凑一点。另外所有固定尺寸的 UI 组件，比如头像、间距、圆角，一律走AppSpacing这个统一配置类，避免散落的魔法数字。

class AppSpacing { static double get s4 => 4 * AppTextScaler.scale; static double get s8 => 8 * AppTextScaler.scale; static double get s12 => 12 * AppTextScaler.scale; // ... }

这套方式有点类似 Web 端 rem 的思路，全局只有一个基准缩放因子，所有间距都从基准值派生，窗口动了、系统字体变了、DPI 变了，UI 仍然能保持比例协调。

3. WebSocket 长连接设计的底层逻辑

3.1 连接生命周期管理：从建立到关闭的状态机

IM 客户端最核心的网络通路就是 WebSocket 长连接。HTTP 是请求-响应模型，每次都要建连，IM 这种实时双向通信场景用 HTTP 轮询既不实时又浪费资源。WebSocket 一次握手建立连接后，双方便可以随时推送数据，这是 IM 的基础通信方式。

但 WebSocket 连接本身是脆弱的：网络切换、服务端重启、防火墙超时、移动端切后台，任何一个环节都能让它断掉。所以长连接管理的核心，是要把它当成一个有状态的对象来管理，我画了一个连接状态机，只有五种状态：disconnected（未连接）、connecting（连接中）、connected（已连接）、reconnecting（重连中）、closed（主动关闭）。

enum ConnectionState { disconnected, connecting, connected, reconnecting, closed }

这五种状态之间的跳转是有明确约束的，比如从connected只能跳到reconnecting或closed，不能直接跳到connecting。我在代码里用一个ConnectionStateMachine类统一管理状态迁移，每个状态进入时执行对应的动作：进入connecting时发起握、进入connected时启动心跳定时器、进入reconnecting时安排重连。

状态机最大的好处是让代码逻辑变得特别清晰。以前我也移动端那种 if-else 判断连接状态式的写法，桌面端多窗口场景下根本守不住——几个窗口同时触发重连，连接建立时机互相打架。状态机收敛之后，无论哪个窗口触发，都只是给状态机发一个事件，真正建立和断开的逻辑只有一套。

3.2 心跳机制：为什么不能省掉那一声 ping

WebSocket 连接上之后，服务端和客户端之间如果没有数据传输，很多中间网络设备（尤其是 NAT 网关和负载均衡器）会在一两分钟内把空闲连接回收掉。要保证连接长期不被断，必须用心跳包维持连接活性。

心跳的设计要考虑两个问题：发送什么内容、间隔多久。我用的应用层心跳是向服务端发送一个只包含type: "ping"的 JSON 帧，服务端回type: "pong"。这个和 WebSocket 协议层的 ping/pong control frame 是两回事，应用层心跳的好处是可以额外携带客户端时间戳，方便服务端校准时延。

心跳间隔我调试后定为 30 秒。这个值的设定有取舍关系：太短会有大量无意义流量，移动端还耗电；太长又可能被中间设备提前回收。30 秒在两者之间是通用值，但如果你的服务端部署在云端负载均衡后面，最好把负载均衡的空闲超时时间也调到大于 30 秒，否则负载均衡比你更早掐掉连接，心跳就白发了。

心跳检测要有超时判定。我设置的是连续三次心跳未收到 pong，也就是 90 秒内无任何响应，直接判定连接异常，触发重连流程。这里有一个很容易踩的坑：ping 发出后没收到 pong，不代表连接一定断了，可能服务端只是高负载延迟处理，也可能中间设备把 pong 缓存了延迟转发。所以我不用单次超时就断连，而是采用连续三次未响应再判定，给网络抖动留有余地。

class HeartbeatManager { Timer? _heartbeatTimer; int _missedPongs = 0; static const maxMissedPongs = 3; void start() { _heartbeatTimer = Timer.periodic( Duration(seconds: 30), (_) => _sendPing(), ); } void onPongReceived() { _missedPongs = 0; } void _sendPing() { if (_connection.isActive) { _connection.send('{"type":"ping"}'); _missedPongs += 1; if (_missedPongs >= maxMissedPongs) { _connection.forceClose(); } } } }

3.3 消息可靠性保障：ack 确认与消息补拉机制

WebSocket 是可靠传输协议，TCP 保证字节不丢不乱。但"字节到了"不等于"业务消息到了"——客户端把消息发出去，服务端可能收到了但处理失败，也可能服务端处理成功了但响应帧在网络中丢了。所以 IM 必须在应用层做消息可靠性保证。

我这里的方案是客户端本地消息总线。每条消息发出之前，先在本地的数据库插入一条sending状态的消息，分配一个客户端自增的msgId，然后立即在 UI 上显示出来。发送成功后收到服务端的 ack，把本地状态改成sent或delivered。如果服务端在超时时间内没有回 ack，消息显示发送失败，用户点重发按钮会触发重发流程。

服务端返回的 ack 除了确认消息到达，还会回传服务端分配的serverMsgId和时间戳，客户端把这些信息更新到本地，保证同一消息在多个设备上的排序一致。

class MessageSendService { Future<void> sendMessage(Message message) async { final localId = await _messageRepo.insert(message); final success = await _trySend(message, localId); if (!success) { await _messageRepo.markFailed(localId); } } Future<bool> _trySend(Message message, int localId) async { final response = await _wsClient .sendAndAwait(message.toJson(), timeout: Duration(seconds: 10)); return response != null; } }

这里有一个桌面端特有的处理：用户可能同时打开多个会话窗口，一条消息在窗口 A 发出去，窗口 B 也要实时看到。我采用的是数据库优先的设计——所有消息的写入都先落库，任何窗口收到数据库变更通知后重新读取该会话的消息列表并刷新 UI，消息本身不以内存对象的方式跨窗口传递。

3.4 断线重连策略：指数退避 + 随机抖动

断线重连是 IM 长连接最容易被轻视又最重要的一部分。如果重连逻辑写得糙，服务端抖动一下，几百上千个客户端同时疯狂重连，会形成重连风暴直接把服务端打崩。

我的重连策略分为三个层次：

第一层，快速重连。正常网络波动断线后，立刻尝试重连，等待时间从 1 秒开始。如果连续失败，每次重连等待时间翻倍：1 秒、2 秒、4 秒、8 秒，最多退避到 60 秒封顶。

第二层，随机抖动。指数退避如果不加抖动，服务端重启后所有客户端会在几乎同一时刻发起重连。我给每次重连等待时间加一个 0 到 1 秒的随机值，打散请求节奏。

第三层，网络状态感知。桌面端没有移动端那种 connectivity_plus 的网络监听，但 Flutter 桌面端也提供NetworkInterface.list可以观察网卡状态，我用它来感知网络变化，网络从断开恢复时立刻触发一次重连，不需要等待退避计时器结束。

Duration _nextRetryDelay(int retryCount) { final base = min(60, pow(2, retryCount).toInt()); final jitter = Random().nextInt(1000); return Duration(seconds: base) + Duration(milliseconds: jitter); }

重连成功之后，客户端要做的第一件事不是立刻拉全部数据，而是进行增量同步——把离线期间所有未确认的消息、未读会话重新拉取一遍。这个同步动作放在重连成功回调里，和正常的首次连接流程区分开，避免每次重连都全量拉数据造成服务端压力。

3.5 高并发长连接的客户端侧功夫

搜索热词里有"高并发im""smart-socket 单机百万长连接"，这类讨论大多站在服务端角度，但客户端在高并发场景下的功夫一点不少。

桌面端 IM 可能同时存在多个连接场景：主连接是 WebSocket，图片上传是 HTTP，文件传输是另一个独立的 Socket 通道或 HTTP 分片上传。如果每个通道各自为政，高并发生产环境下资源占用会非常可观。

我在客户端做的工作主要有三块：第一，连接复用。HTTP 请求统一走同一个连接池，WebSocket 只维护长连接，文件传输单独一个连接，但它的生命周期受主连接管理——主连接断了，文件传输连接也一并关闭，避免残留的无谓连接。第二，内存控制。大量图片消息到达时，Widget 层只显示缩略图，原图在用户主动点击时才加载并缓存到本地文件。第三，并发限流。历史消息分页拉取时，客户端串行拉取而不是并发，每次最多保持两个未完成的 HTTP 请求，防止弹出式流量把磁盘 IO 干满，桌面端磁盘速度虽快但大量小文件写入一样会造成卡顿。

4. 实操过程中遇到的坑与排查实录

4.1 环境与构建的坑：Windows 桌面端从头开始

Flutter 桌面端对环境的要求比移动端门坎高。热词里那些"flutter新建项目后跑不起来""you are applying flutter's main gradle plugin imperatively"对我来说还算熟悉，但从移动端转向桌面端时踩的坑是完全陌生的。

第一坑是 Windows 上跑 Flutter 桌面端需要 Visual Studio 的 C++ 桌面开发组件，而且 Flutter 官方对 Visual Studio 版本有要求。新版 Flutter IDE 提供的 UIKit 和 Windows 窗体支持要安装对应的 workload，没装好会在 flutter run 时直接报找不到 windows 平台的 compiler。

第二坑是 Impeller 渲染引擎。Flutter 3.10 之后 iOS 上默认用 Impeller 替代 Skia，桌面端在某些版本上也可以启用，但有一个明显问题：中文等复杂字体渲染在某些显卡驱动下会有瑕疵。实测下来，Windows 桌面端如果遇到字体渲染异常——文字发虚、描边断裂、方块闪烁——先试试在flutter run时加--no-enable-impeller，很多问题是渲染引擎和显卡驱动兼容性导致的，不一定是你代码写错了。

第三坑是端口占用和反病毒软件拦截。桌面端 IM 要监听本地端口（比如本地通知服务），Windows Defender 有时候会把 flutter 的调试端口误报为风险流量，导致 WebSocket 连接建立后几秒钟就被断开。排查了很久才发现是安全软件拦截，把 flutter 工具加入白名单就好了。

4.2 布局与交互的坑：桌面端特有的间歇性 bug

布局上我踩过的最诡异的一个坑是消息列表偶发性地跳动。同一个会话、同样的消息，有时候打开窗口就在列表底部，有时候定位到中间某条消息前。排查了很久，发现问题是窗口焦点变化触发的 rebuild 把ScrollController的 offset 重置了。

解决方案是单独维护一个ScrollPositionHolder类，把每个会话的滚动位置以会话 ID 为 key 缓存到内存中。窗口失焦时保存当前位置，重新激活或切换会话时恢复位置，而不是依赖 ScrollController 默认行为。

还有一个很让人迷惑的交互坑：快捷键在不同窗口焦点下失效。桌面端可以同时打开多个窗口，但全局快捷键（比如全局搜索 Ctrl+Shift+F）注册在某个窗口上，当焦点在其他窗口时，这个快捷键就不触发了。桌面端 IM 要做一个真正的全局快捷键，需要在系统层面注册，比如用hotkey_manager插件，或者在每个窗口里都注册相同逻辑的快捷键并通过事件总线联动。

4.3 WebSocket 的坑：粘包、半包、JSON 解析失败

WebSocket 底层是 TCP 流式协议，虽然 WebSocket 协议层自带消息分帧，不会出现 TCP 粘包半包问题，但如果 IM 应用把多个业务逻辑塞在一条 WebSocket 消息里，比如批量同步消息、心跳+同步、多端在线通知一起打包发送，接收端仍然需要做业务层的分包。

我和服务端约定所有消息都有一个seq和type字段，seq是服务端下发的全局递增序号，客户端收到消息后先按 seq 暂存，再根据 type 分发到对应的处理器。这么做除了分包，还能解决消息乱序的问题——WebSocket 理论上保序，但服务端多实例部署时，同一会话的消息可能从不同实例发出来，到达顺序不一定和 seq 一致。

JSON 解析失败是我在开发过程里遇到频率最高的问题。消息模型改了字段名，服务端还在推旧字段，或者字段类型变了（int 变 string），客户端解析抛异常，如果不加保护，一条坏消息能卡住整个消息处理循环。后来我在所有的消息入口加了 try-catch 和解析失败缓存，解析失败的消息不阻塞后续消息，记录日志并单独保存，方便复盘。

4.4 性能与内存泄漏的排查：从卡顿到崩溃

桌面端 IM 的卡顿来源和移动端不完全一样。移动端主要是列表滚动和图片解码，桌面端还有一个大头是窗口 resize。每次拖拽窗口大小，Flutter 都会重新 layout，如果布局里有一些高成本的组件（比如圆角裁剪、阴影、毛玻璃），整个 rebuild 耗时可能超过 100ms，拖拽过程中会明显掉帧。

我在排查性能问题时用 Flutter DevTools 的 Performance Overlay 看了帧数据，发现一个会话窗口里有几百个消息气泡，每个气泡都带有ClipRRect裁剪圆角和阴影，GPU 压力很大。优化手段是把短消息的圆角裁剪换成PhysicalShape，在 GPU 侧做裁剪，性能提升非常明显。另外，气泡的阴影只在 hover 时才渲染，平时关闭，交互时的视觉反馈和静态性能兼得。

内存泄漏比较隐蔽的一个场景是消息列表的图片缓存。桌面端窗口的会话可以无限切换，如果不做 LRU 缓存清理，图片数据会一直堆积在内存里。我写了一个简单的 LRU Cache，上限是 500 张图片和 256MB 内存，超出把最早的图片释放掉。实测连续切换 100 个会话后，内存占用曲线是平的，不再稳步上升。

做桌面端 IM 的这几个月，踩过的坑比预想的多，解决之后我对 Flutter 桌面端的信心反而比最初更强了。Flutter 桌面端目前最成熟的还是 UI 层，但像全局快捷键、系统托盘、窗口管理、原生多窗口这些能力，社区生态正在快速补齐，几个关键插件也都在活跃维护，遇到坑至少有地方翻文档、提 issue。

如果你正在做类似的 Flutter 桌面端 IM 项目，我的建议是先把这三个基础打牢：状态管理选型要放在目录结构之前确定，因为后面所有文件的组织方式都跟着状态管理来走；聊天窗口的布局框架要一次设计到位，抽屉、折叠、拖拽这些交互越晚介入改造成本越高；WebSocket 这块，把连接状态机、心跳、重连、消息可靠性的代码写扎实，别因为赶进度做成了到处是 if-else 的状态泥潭，不然项目越到后期，连接逻辑越不敢改，那才是真的麻烦。

最后分享一个细节：Flutter 桌面端项目里一定要多留日志。IM 这种实时通信项目，线上问题绝大多数发生在深夜里，用户没有反馈，只有日志会留下痕迹。我从项目第一天就在连接层、心跳层、消息处理层各加了带耗时统计的日志，后期线上排查问题时帮了大忙。这个习惯，建议你从写第一行代码就开始。