分享一下 在ios上 uni-app 通过oauth2登录遇到的一些阻碍和解决办法。

就当纪念一下抠了好几天的头。虽然实现了，也花了很多时间，但是没有什么成功了的实感，有种莫名其妙的感觉。
不论咋样，还是记录一下吧，百度之后竟然完全没有人用这个方式 在ios上登录，而ds和cursor一众ai费拉不堪，ds胡说八道的程度越来越严重了

oauth2的登录描述比较粗糙。

有一个最想知道的问题，想知道 ios中app和 webview 的 cookie传递。

过程：
1.根据文档设置 ios的schemes。注：urltypes 只能用string格式，不可用数组，否则打包 的link.info 中 没有 CFBundleURLTypes 的标签。
2.login接口后，后端会产生一个短暂的cookie会话，根据该会话证明过程中登录情况。若无法验证到该cookie会话，将直接跳回登录界面。
3.使用webview 打开 authorize 页面，如果验证成功，会通过schemes唤醒 app,接着验证获取token并跳转主页面。

其中遇到3个阻碍。

1. 在login接口后的 cookie会话，没有 设置 domain 时，webview 打开 authorize页面，一直都是cookie验证会话失败，直接跳转回登录界面。在设置 domain后，第一次 登录 cookie会话验证失败，而第二次继续登录的验证都通过了。
   询问了ds等ai，给出的解释是 在ios时，网络请求和Cookie存储与App本身不在同一进程，默认不共享NSHTTPCookieStorage。所以通过webview 后端会拿不到cookie从而导致失败。而安卓的cookie在uni-app底层已经同步过，所以不存在该问题。但问题是为什么设置了domain后，除了第一次失败，后续的登录都成功了？是不是底层也对ios同步过？但为什么第一次不成功？强制手动给webview注入cookie，没有一个方式成功。设置延时任务也没有用，设置多长也没有用，第一次就是不能通过。
   后续与后端沟通，通过 生成token附带在 authorize的path后，后端使用token来验证会话解决该问题。

2.page.json中 设置过 // "condition": {
// //模式配置，仅开发期间生效
// "current": 0, //当前激活的模式(list 的索引项)
// "list": [{
// "name": "", //模式名称
// "path": "", //启动页面，必选
// "query": "" //启动参数，在页面的onLoad函数里面得到
// }]
// }。

从而导致 schemes唤醒后，无法获取schemes携带的数据。安卓无此问题。

3.后端schemes因为ios的安全机制是无法自动唤醒app，除非用户手动点。Universal Links 也没办法在同域名下进行唤醒。但是，实际上 传递数据已经触发，在plus.runtiem.arguments中是有数据的。所以直接搞了一个 定时任务监听这个数据，一旦有数据就可以直接后续的步骤，不需要用户手动点击。安卓可以直接通过schemes唤醒app并直接拿到数据，所以也不需要这个定时任务