琦玉老师比我秃调试网络请求，是移动端开发里最绕不开的日常操作之一。做 Flutter 开发时，Dio 基本是事实标准的 HTTP 客户端，而 Pretty Dio Logger 则是搭配它最顺手的一款请求日志插件。最近我把一部分 Flutter 业务迁移到 OpenHarmony 设备上跑，原以为日志工具链会有不少适配工作量，结果发现 Pretty Dio Logger 这种纯 Dart 实现的插件，在 OpenHarmony 的 Flutter 环境里几乎零成本就能用起来，体验和 Android/iOS 上完全一致。这篇文章就围绕“Flutter for OpenHarmony + Pretty Dio Logger”这套组合，写写我在实际项目里怎么配置、怎么调参、怎么拿它快速定位问题，以及那些文档里不会写清楚的坑。
不管你是刚开始接触 OpenHarmony 上的 Flutter，还是已经在做鸿蒙设备端的应用调试，这篇内容都能帮你少走点弯路。我会从选型思路讲到完整接入步骤，再给出一套可复用的封装模板，最后把几个高频问题逐个拆开讲透。
1. 项目背景与整体设计思路
1.1 为什么 Flutter 应用需要网络请求监控
很多刚入门的同学觉得，调试网络请求不就是打开 DevTools 或者抓包工具看一眼吗？但实际上，移动端网络问题是一个特别磨人的环节。你辛辛苦苦写完一个接口调用，真机上跑起来，发现页面数据没出来——这时候你根本不知道是请求根本没发出去，还是服务端返回了 500，还是 JSON 解析炸了。如果没有一个直观的请求日志输出，你只能靠猜，或者去抓包工具里翻半天。
抓包工具（比如 Charles、Fiddler）虽然功能强大，但在真机上配置代理、装证书，本身就有一堆成本。尤其是 OpenHarmony 这类新平台，抓包工具的兼容性还不一定跟得上。而 Pretty Dio Logger 这种日志插件的好处是：它不依赖任何外部代理，直接在应用进程里拦截 Dio 的请求和响应，把关键信息打印到控制台，一键开关，随开随用。这对于日常开发调试来说，效率要高得多。
1.2 Pretty Dio Logger 能解决什么问题
简单说，Pretty Dio Logger 是一个 Dart 包，以 Dio 拦截器（Interceptor）的形式工作。你只需要在创建 Dio 实例时把它加进 interceptors 列表，之后所有的 HTTP 请求、响应、错误，都会以格式化后的可读文本输出到日志里。
它能输出的内容包括：
- 请求方法、URL、请求头、请求体
- 响应状态码、响应头、响应体
- 请求耗时（从发出到收到响应的总时间）
- 错误信息与异常堆栈
- 自定义过滤规则，比如只打印某个域名的请求，或者忽略某些敏感接口
在实际开发里，这套能力基本覆盖了日常接口调试 90% 以上的场景。而且它对已有的业务代码侵入性极低——不需要改任何接口调用逻辑，只需要在初始化 Dio 的地方加几行配置。
1.3 为什么选 Pretty Dio Logger 而不是其他方案
在 Flutter 生态里，类似的网络日志插件还有 dio_log、logger + dio_interceptor 这类组合，但 Pretty Dio Logger 有几个很实在的优势：
- 纯粹用 Dart 实现：这是它能在 OpenHarmony 上无缝运行的关键。它不依赖任何原生平台通道（PlatformChannel），也不涉及 Android/iOS 的 Native 代码，所以不需要为 OpenHarmony 做任何额外适配。相比之下，一些用原生 View 实现悬浮窗日志的插件，在 OpenHarmony 上就需要重新适配，工作量完全不是一个量级。
- 配置灵活，开箱即用：插件的默认配置已经足够漂亮，但我们也能够按需关闭请求头、压缩响应体、限制最大行数等。
- 与 Debug 模式配合默契：日志输出走的是
print/debugPrint，在 Flutter 的 Debug 控制台里看效果非常直观，也能配合kDebugMode做到生产环境自动关闭。
我当时在 OpenHarmony 真机上跑通第一版时，看到控制台里打印出格式化的请求日志，第一反应是：真的就这么简单？因为完全没动任何平台相关的代码。对于一个新兴平台来说，这种零适配体验本身就说明了 Flutter 跨端能力的价值。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备与依赖集成
2.1 OpenHarmony Flutter 开发环境的基本要求
在开始接入 Pretty Dio Logger 之前，先确保你的 OpenHarmony Flutter 开发环境是能正常跑的。这里默认你已经完成了以下基础工作：
- 安