20210906-14关于flutterweb获取cookie与发送http请求的区别

发现似乎还是要先具体尝试一下，而且似乎我这个是直接跑在了浏览器上，所以不存在cookie的"持久化问题"

但是却存在其他问题：

其实他这里所提到的dio_cookie_manager组件的存在意义是：

首先他是为原生app准备的，因为原生app和浏览器不同，他在最开始是无法“接住”任何服务器发来的cookie缓存的， 因此原生app在post一个网页前，需要先有效化dio_cookie_manager这样才能让app获取到cookie

而对于网页app来说似乎业务逻辑就发生了根本的变化了，因为此时cookie已经存在于浏览器里边了，我需要做的其实是 让运行在浏览器上的flutter与浏览器进行通信，从而拿到cookie的具体值，然后携带这个具体值再去进行post等操作

因此根据我目前的实际情况来说，我并不需要用到 dio_cookie_manager与cookie_jar，而只需要用到负责处理post，get这些请求的dio即可

除非这些包能有实现与浏览器通信的方法

真正能实现我需求的其实是这篇文章：

其中的get-cookie部分

而这篇文章则解释了evaluateJavascript()的本质就是Flutter调用js：

这篇是篇好文章

可还是无法解决实际问题，真正的方法其实是更为底层的：

也就是如下：

import dart：html

====

关于反向代理的底层逻辑：

现在发现最终的重定向虽然没有让cookie违背path与domain原则，但是除了这两个原则之外还有第三个原则，那就是子目录原则：

比如 http://www. abc.com/test1/setcookie .html 中的cookie， http://www. abc.com/test2/getcookie .html 是无论如何也拿不到的，只有 http://www. abc.com/test1/test2/get cookie.html 才能拿到

其实这个和path到时有些神似，但是区别在于 ”path虽然可以决定把cookie储存到哪里，但是不能决定(设置/修改)自己是谁

于是接下来，我就需要通过反向代理，把./testflutterx映射到./zw/testflutterx了

反向代理的底层逻辑可以这么理解：

先拿出一个真正希望被用户访问的路径(也就是 https://www. xxx.com/yyy 的某一个)，映射给物理服务器上另一个web服务(端口)的网页目录路径，同时，这个首先被拿出的路径，以及子路径，相关路径文件就都失效了，因为它被“映射给别人了”然而被映射的路径还是可以使用的，这就是反向代理的底层逻辑。接下来我将开始进行相关的配置工作，和以往不同，这次映射和被映射的路径都会来自“真正希望被用户访问的路径”

20210911flutter的dio脑仁不累的教程：

另一篇比较不错的文章，初始化讲的很好：

错误码设计：

目前似乎必须区分一下错误类型了，不能一水的只返回错误失败

可以不暴露给前端微信的错误码，但是必须有自己的自定义错误码从而区分诸如：

c.v1.postuserinfo失败后，前端需要做的是进行wxoauth2redirect？还是展示失败页面告诉用户哪里出问题了

似乎对于设计逻辑上，我自己的错误码逻辑需要屏蔽掉wx的错误码逻辑，或者说一个系统只能存在一套错误码逻辑，不能出现如下思路：

c.JSON(http.StatusBadRequest, gin.H{
    "error":"操作失败",
    "code":"1234",
    "wxerrcode":wxerrcode(这个struct不该出现，同一系统不能出现两套错误码逻辑)
})