前言
近期排查客户上报的问题时，遇到了一个比较费解的问题，在这边梳理一下排查的流程、遇到的难点、找到的一些相关资料，来对整一个问题进行一个总结，也借此机会做一个分享
问题现象
客户这边反馈在mpaas近期升级后，有发现在低版本的android手机上无法正常打开某链接，会出现打开后直接跳转错误页面的问题，而在高版本的android上现象正常。
排查思路
1.复现
在收到这类需求后，笔者这边首先依据客户的描述，尝试在最新基线68.33下进行复现，避免出现系已解决的bug导致的问题。
测试结果与用户反馈一致，android7下可以看到跳转进入错误页面（显示报错500），在android10下则无该现象。
2.细化测试用例
由于出现现象的场景为nebula容器，一般涉及该现象的有两点，UC内核和Nebula容器本身，因而我们采用以下几个场景进行测试：
1.使用nebula容器，uc内核，android7下可以看到跳转进入错误页面，在android10下则无该现象。
2.使用nebula容器，系统内核，android7和android10下都可以正常使用。
该场景可以通过移除ucKey或者使用param.putString(H5Param.USE_SYS_WEBVIEW,"YES")
3.使用系统原生webview容器，不涉及nebula容器，android7和android10下都可以正常使用。
通过排除变量法，我们这边可以初步确认系uc内核的原因。
3.对比具体差异
在初步确认系uc问题后，我们先判断相关的访问链路，使用inspect/chales等工具，可以协助我们拿取到完整的访问请求报文，以对比成功/失败时的差异。
笔者此次使用的是Inspect方案。
（图1）
首先，我们查看一下链接失败的情况 可以看到系某个登陆接口报错，确实报了500。
然后我们尝试使用Android10的设备打开这个报错的url，却发现在该机型下，code码返回的是200。
（图2）
对比图1和图2，我们可以初步把问题的原因归结到的可能是该响应的报错导致的这个现象，而与响应直接相关的就是请求报文，于是我们开始比对两次请求报文之间的具体差异。
(图3)
在图3中，我们可以发现两点差异，即：
1.ua请求不同。
2.cookie使用方式不同。
我们对这两个分别进行验证。
4.验证假设
1.验证UA
基于以往的经验，笔者先验证是否是UA导致的，
我们采用：
MPNebula.setUa(new H5UaProvider() {
@Override
public String getUa(String s) {
Log.d(TAG, "getUa: " + s);
return "";
}
});
将android10下的UA信息直接赋予Android7下，但验证结果发现问题依旧存在。
2.验证Cookie
因确实没有遇到由于是Cookie导致的问题，做到这一步的时候实际是比较懵的，但幸好有百度。
Set-Cookie: SESSION=YWJjYWYyMjQtMGY0NC00YzMyLTgxYjItYzkxNWM1MjAyNzFi; Path=/; HttpOnly; SameSite=Lax
Cookie: SESSION=NWMxMTcwZTgtZjkzMC00ZGE3LWFlMmUtZjg1MjAxNWRlNDIy
两项差异我们可以看到，主要是在成功的选项中出现了SameSite=Lax 这个特殊的参数信息，通过百度：
从Chrome 80版本起，Google将开始「强制」实施一套全新的默认安全的Cookie分类系统，其具体内容包含两点：
1.默认为所有「没有声明」samesite属性的Cookie加上SameSite=Lax；
2.如果声明了SameSite=None，必须同时带上Secure属性，才允许在「跨站」上下文中被访问；
此举将从源头上有效遏制跨站点请求伪造(CSRF)攻击，使得用户的隐私和安全得到更好的保障，Web生态更加健康
因而极有可能是由于UC默认在低版本没有完成这一块的适配导致的。
5.解决
在这里，我们首先给出结论，通过查阅文档，确认UC提供的方案为:
UCSettings.setGlobalBoolValue(SettingKeys.EnableSameSiteCookieDegradation, true);
我们在应用初始化后加入如上配置，再次验证问题，问题解决。
