Dart BrowserClient突发XMLHttpRequest错误排查求助

结合你的场景，咱们来拆解这个突然出现的问题：你的Dart浏览器应用用BrowserClient发请求，运行两小时后突然触发CORS预检错误，提示x-ijt字段不在服务器的Access-Control-Allow-Headers列表里；同时Roboto字体请求也报相同错误；用IOClient在命令行运行正常，开启WebStorm的「Allow unsigned requests」后恢复，但你明明没修改过配置。

下面是可能的核心原因：

1. WebStorm内置服务器/调试工具自动注入了x-ijt请求头 #

WebStorm的内置开发服务器（用来调试浏览器应用的那个）在某些场景下会自动给请求加额外的头字段，x-ijt就是其中之一——它一般和WebStorm的增量编译、热重载或者内部请求追踪功能挂钩。

很大概率是运行两小时后，WebStorm的某个后台进程（比如热重载重启、调试会话自动续期）自动开启了这个头注入逻辑，而你的后端CORS配置里根本没把x-ijt加入Access-Control-Allow-Headers，导致浏览器的预检OPTIONS请求失败，抛出了ClientException。Roboto字体请求报错也是同样的道理——WebStorm把这个头也加到了字体请求里，触发了CORS拦截。

2. BrowserClient和IOClient的CORS行为差异 #

你说用IOClient在命令行运行正常，这是因为：

• BrowserClient基于浏览器原生的XMLHttpRequest实现，严格遵守浏览器的CORS规则，会自动发送预检请求验证自定义头是否被允许；
• IOClient基于Dart的dart:io HttpClient，运行在命令行环境下，不受浏览器CORS规则约束，自然不会触发预检错误。

3. 「Allow unsigned requests」选项的作用 #

开启这个选项后，WebStorm的内置服务器会调整请求处理逻辑：要么直接停止自动注入x-ijt这类额外头字段，让请求回到之前的正常状态；要么自动修改响应的Access-Control-Allow-Headers，把x-ijt加进去，让浏览器的预检请求通过。

为什么没改配置却突然出问题？ #

就算你没手动改设置，也有几种可能触发这个情况：

• WebStorm可能偷偷打了小补丁或者更新了内部服务（哪怕主版本是2019.2，后台的小更新还是可能发生）；
• 调试会话超时后自动重启，触发了默认配置，开启了头注入；
• 项目的.idea工作区文件（存本地WebStorm设置的）被意外修改——比如版本控制同步、误操作点到了隐藏的设置开关。

验证建议 #

• 打开项目的.idea/workspace.xml，搜索allowUnsignedRequests相关配置，看看有没有最近的变更；
• 手动在后端的CORS配置里把x-ijt加到Access-Control-Allow-Headers里，然后关闭「Allow unsigned requests」测试——如果不再报错，就能确认是头注入导致的问题。

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