这确实是个挺费解的边缘问题，结合你提到的Chrome 75（2019年的旧版本）+ Windows 10环境，以及用户无功能异常反馈的情况，我梳理了几种大概率的原因：

• Chrome 75的特定CSP报告bug
  这个版本的Chrome在处理一些边缘场景的frame加载时，存在CSP报告字段填充错误的问题。比如当浏览器尝试处理内部特殊URI（如about:blank）、未完全初始化的frame，或者某些第三方资源的间接加载时，会错误地将blocked-uri留空，但实际上并没有拦截合法的请求。这类bug在后续的Chrome版本中已经被修复，所以你用新版本浏览器无法复现。

• 浏览器扩展的干扰
  Windows 10上的Chrome 75用户可能安装了广告拦截、隐私防护类扩展。这些扩展会在后台拦截或修改frame请求，但部分扩展的处理逻辑不够完善，会导致浏览器生成的CSP报告中blocked-uri为空。由于扩展的拦截并未影响页面本身的合法功能，用户自然不会感知到异常，只会产生无意义的违规报告。

• 同源空白frame的特殊处理异常
  虽然你的CSP策略设置frame-src https:，但同源页面加载about:blank frame时，旧版本Chrome的CSP检查逻辑存在矛盾：一方面about:blank不属于https协议，理论上会触发违规；另一方面浏览器对同源空白frame有豁免逻辑，实际不会拦截。这种矛盾导致浏览器错误上报了违规，但blocked-uri字段未正确填充，而功能不受影响。

• 动态创建frame的瞬时违规
  如果页面通过JavaScript动态创建frame，在frame的src属性未设置为合法https地址之前，浏览器的CSP检查可能会扫到这个未初始化的frame，触发一次blocked-uri为空的违规报告。但随后代码会给frame设置合法的src，所以实际功能完全正常，只有一次瞬时的虚假上报。

总的来说，这类空blocked-uri的违规报告大多是旧版本浏览器bug或外部因素导致的虚假上报，不会影响用户体验，也不需要修改当前的CSP策略。如果要验证，可以找一台安装Chrome 75的Windows 10设备，禁用所有扩展后测试是否还会出现这类报告。

内容的提问来源于stack exchange，提问作者user2144597