设计要求
支持网络库的可插拔的设计，以及和业务层代码的解耦机制吧（不干扰业务层代码）
简洁的进行使用以及支持配置化的实现发送网络请求
使用适配器模式 Adaptor 设计实现，实现高扩展性追求吧
统一的异常和返回值处理，从而到达最终的库适配业务，而不是业务适配第三方库的追求实现吧
网络库的封装
前期思考
第三方网络请求库总结
Dart 原生的 HttpClient
官方的 Http
第三方的 dio 库
注解版的 retrofit/chopper 等库吧
上面的架构的话
三方库调研
dio
http
retrofit 实现
适配器层的实现
http 适配
dio 适配
mock server 适配
统一的逻辑处理层的进行异常处理和信息的返回
请求的处理，可配置实现
响应的处理，输出统一的数据响应格式
异常的处理
restful api 支持前后端分析的设计
get | post | delete | put 等请求吧
Dao （data access object）层：
DAO是数据访问的抽象层，解决的是“如何访问数据”的问题；DTO是数据传输的载体，解决的是“数据如何流动”的问题
在Flutter中，DAO通常对应本地数据库（如sqflite）或远程API的封装，而DTO就是那些在UI层、网络层、持久化层之间传递的简单数据类
核心就是对接的是不同的业务的接口吧
例如首页、视屏列表、详情列表、点赞、收藏、登录注册等等，根据业务类型进行结构化的拆分实现吧
架构搭建
核心的话网络层的东西需要做的是
进行封装的核心的处理函数，进行在请求的时候进行一些信息的拦截，因为在实际业务中，我们的的状态码可能是一些响应状态码，也可能是一些业务层的状态码，此时我们就需要进行的是封装属于自己的一些状态信息实现吧
统一的错误处理实现，对于不同的错误进行单独处理，然后再防火墙的这一层进行拦截实现对应的处理实现吧
适配器层的实现，通过适配器的层的设计实现对应的对接不同的第三方库，实现网络请求库的可插拔的设计实现吧
核心分为这几块吧
一个基本的构建请求链接的工具吧
核心需要兼容的是：
1. 是否是 https 或者说是 http 的请求格式
2. 查询参数的
?的兼容3. 动态路径参数的兼容实现
一些业务层需要做的一些事情吧：因为上面的一些处理都是在我们的 url 链接上进行操作实现，但是我们的下面的两个是需要进行单独的业务层的实现，所以说这里的 net_base_request 只能提供对应的操作方法，其他的的确无法达到标准统一化，此时只需要把 api 进行暴露给外部使用即可
4. 请求体的兼容实现
5. 请求头的兼容实现
一个网络请求工具
核心是利用构建的 URL 链接工具的地址，和一些元信息，实现对应的实际操作吧
这个核心实现的是
网络请求库的可插拔的设计实现
以及实现对应的异常的错误处理实现
以及实现对应的适配器模式的实现
以及还需要进行处理我们的 json 数据的编码和解码的实现吧：dart:convert 进行处理吧
。。。。。。等等吧
一些请求头的判断：
是否支持 json 数据格式：
Content-type: application/json;charset=UTF-8如果是 json 的数据格式的话就需要进行对应的 json 的编解码实现吧，否则不是特别的好操作
核心使用的包就是
dart:convert库来实现吧或者说使用我们的 json_serializable 库实现json 的实体类的实现书写，此时是定义本地使用的一些 json schema 的模型的model 吧
但是需要配套的用json的注解库吧：json_annotation 来共同完成工作吧和 build_runner
注意一下：json_serilizable 和 build_runner 是dev 依赖，另一个是生产依赖
核心就是我们的一个数据模型的抽象吧