子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）

大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

很多人第一次写 Flutter 网络请求时，思路其实很简单：
引入 Dio，封装一个 get/post，请求成功就把数据丢给页面用。

项目早期，这种写法不仅快，而且几乎没有阻力。但只要接口开始频繁变化，或者业务复杂度上来，问题就会一口气全部出现：

• 错误处理到处都是
• 页面直接解析 JSON
• 改一个字段，几十个地方一起崩

这时候你会发现——真正决定网络层上限的，不是 Flutter，而是有没有前端架构经验。

为什么前端更早重视网络分层

前端生态经历过接口爆炸式增长的阶段，所以很早就形成一套共识：

UI 不能直接依赖接口返回结构。

在大型 Web 项目里，常见分层是：

API 层  →  DTO
Domain 层 → Entity
UI 层  → ViewModel

这样做的核心目的不是“优雅”，而是对抗接口变化。现实情况是：

• 后端字段经常改名
• 返回结构随版本变化
• 不同端的数据格式还不一致

如果 UI 直接用原始 JSON，那每次接口改动都会变成一次“全项目级重构”。

这也是为什么很多前端工程师一写 Flutter，第一反应就是：不能让页面碰 Dio。

iOS 的 URLSession 为什么天然更克制

对比来看，iOS 生态反而更早形成约束感。典型做法是：

• URLSession 只在最底层
• 上面一定有 Service / Repository
• 页面永远拿不到原始响应

这背后的原因很现实：

强类型语言不允许你随便改字段。

一旦 Model 改动，编译期就会报错，所以开发者自然会把“变化”挡在更底层。

但 Flutter 团队经常忽略这一点，因为 Dart 对 JSON 太友好了——友好到容易失去边界感。

Flutter 为什么不该“直接用 Dio”

很多教程都会教你这样写：

final res = await dio.get('/user');
return User.fromJson(res.data);

看起来完全没问题，但真正的隐患在这里：

页面知道了接口长什么样。

当接口从：

{ name: "Tom" }

变成：

{ user_name: "Tom" }

理论上只该改一处解析逻辑，但现实往往是：

• 多个页面各自解析
• 不同地方字段名不统一
• 修 bug 变成全局搜索替换

问题从来不在 Dio，而在于——网络层没有真正分层。

跨端一致的 DTO / Entity 模型到底在解决什么

很多人觉得 DTO / Entity 很“重”，但只要经历过一次接口大改，就会明白它的价值。

一个更稳定的结构通常是：

Network Response → DTO → Entity → UI

每一层职责非常清晰。

DTO 只关心接口长什么样。
字段可以丑、可以多余、可以随版本变化。

Entity 只关心业务真正需要什么。
字段稳定、语义清晰、与后端解耦。

这样当接口变化时：

只需要改 DTO → Entity 的转换。

UI 层完全不动，这才是网络层真正的“抗震能力”。

一套更通用的 Flutter 网络抽象方式

如果结合前端和 iOS 的经验，Flutter 更长期稳定的结构通常是这样的：

network/
  client.dart        // Dio 实例
  interceptor.dart   // 统一错误处理
  response.dart      // 基础响应模型

features/
  user/
    data/
      user_api.dart      // 只返回 DTO
      user_dto.dart
      user_repository.dart // DTO → Entity
    domain/
      user_entity.dart

这里最关键的不是目录，而是依赖方向必须固定：

• UI 只能依赖 Entity
• Repository 负责转换
• Dio 永远停在最底层

只要守住这三条规则，网络层基本不会随着业务膨胀而失控。

错误处理为什么必须集中

另一个常见痛点是：

每个页面都在 try-catch。

短期看很灵活，长期看却是灾难：

• 错误文案不统一
• 登录失效处理到处复制
• 埋点统计无法集中

更合理的做法其实很简单：

把错误拦在拦截器或 Repository。

页面只接收两种结果：

成功的数据，可展示的业务错误

而不是一堆网络异常枚举，这样 UI 才能真正保持干净。

网络层设计，本质是“对变化的预判”

很多人觉得网络分层是“过度设计”，其实只是是否经历过接口地震的区别。

当项目还很小时：

• 直接用 Dio 最快
• DTO 看起来很多余

但只要进入中大型阶段，真正拉开团队差距的，往往不是性能、也不是组件库，而是：

改一次接口，需要动多少代码。

总结

Flutter 的网络层之所以经常失控，不是因为工具不够强，而是我们太容易忽视一件事：

UI 不应该认识接口。

前端多年的演进、iOS 长期的分层习惯，其实早就给出了答案。

当你开始用 DTO 隔离变化、用 Repository 稳定模型、用统一错误收口复杂度时，网络层才真正从“能用”，走向“能活很久”。