有没有可能你的 customfield_10301 实际也是要传递对象的方式： {"id": "10205"} ， 要不就是这个 key 确实是在这个问题类型里面不存在 基本我遇到的就是这两种清理

好难

这句话就能说明你们领导对于测开岗位本身的定位以及工作内容就不清晰，这个还是明确好来再开展工作更合适

可否提供一个最小的可复现的项目 我来试试看？或者说加个微信，我来看看，我好久没有处理过这个了，可能得确认下

真香， 用 didi 原生的逻辑，会出现各种的 index，越界的报错。 直接用了 MinderJsonPatchUtil 就没有问题，太棒了 哈哈。

一旦两个版本对应的 代码文件被修改了比如说增加了一行，这个时候探针的数据长度就不一样了呀。

插件还有一种模式是 background 的模式发送 ，这种是不会有跨域问题的呀

加个微信私聊下？

信息量有点少，首先我个人觉得跟那个图片加载应该没有太多的关系。因为我用 istanbul-middleware 比较少，所以没有遇到过这样子的问题
我建议你这么尝试分析下看看

1. 重点对比下 css 样式的内容的差异 (因为这个样式问题，按理就是 css 的加载问题才对)
2. 网络请求加载的文件是否都一样的， 如果还没解决 可以加个微信 我们私聊下

哦 我懂了，这个肯定是需要你自己二次开发 im 的， 我们这边的前端代码覆盖率没有用到 im, 是自己根据 cypress 的code-coverage 做的二次开发同时我们是跟运维的同学做了合作，在包部署平台使用容器的 sidecar 的方式，拦截了所有的请求，并且往页面中注入定时上报的代码，上报的内容就就包含了对应的项目名称等，这样子我们的覆盖率服务（你可以理解为 im）就可以知道是那个应用的服务率数据了。 关于前端代码覆盖率的实现 我可以找时间分享下我们这边的一些内容