我之前帮不少开发者踩过这个坑——IE11里弹出SCRIPT1002: Syntax error，还指向一个根本打不开的blob URL，F12调试器抓不到有效位置，连VS附加进程都找不到线索，简直头疼。其实这个错误的本质很简单：IE11不支持ES6+的某些语法，而blob URL是构建工具（Webpack、Vite这类）在开发模式下生成的动态打包代码，把报错的源头给藏住了。下面是亲测有效的调试和解决方法：

1. 先把blob URL换成真实的JS文件（定位源头第一步） #

很多构建工具为了提升开发效率，会把代码打包成blob URL加载，但这直接让IE11的报错失去了定位意义。你得先关掉这个特性，让脚本直接指向原始文件：

• Webpack：在dev配置里把devtool改成'source-map'（别用eval或cheap-module-eval-source-map，这些都是生成blob的罪魁祸首），同时把output.pathinfo设为false。
• Vite：要么在vite.config.js里添加legacy: { buildSsrCjsExternalHeuristics: true }，要么直接打个生产包（生产构建一般会生成真实的JS文件，不会用blob）。

这么操作之后，IE11的报错应该会直接指向具体的.js文件和行号，一下子就能锁定哪行代码出问题了。

2. 检查代码/依赖的转译是否到位 #

如果还是找不到源头，那大概率是某些代码没被Babel转译成IE11能识别的ES5语法：

• 确认你的Babel配置（比如.babelrc或babel.config.js）里包含@babel/preset-env，并且明确设置了targets: { ie: "11" }，确保箭头函数、模板字符串、解构赋值这类ES6+语法都被转译。
• 别漏了第三方依赖！有些UI库或工具包的现代版本会直接用ES6+代码，没做降级处理。你得在构建工具里把这些依赖加入转译范围——比如Webpack的module.rules里，给这些依赖单独配置babel-loader。

3. 用ESLint提前排查，避免到IE里踩坑 #

与其等IE报错，不如在开发阶段就把不兼容的语法揪出来。用eslint-plugin-compat这个插件就能实现：

• 先安装插件：npm install eslint-plugin-compat --save-dev
• 然后在.eslintrc里配置：

  {
    "plugins": ["compat"],
    "rules": {
      "compat/compat": "error"
    },
    "settings": {
      "compat": {
        "targets": {
          "ie": "11"
        }
      }
    }
  }
  

  运行ESLint之后，所有IE11不支持的语法都会直接标红，提前解决就不会再遇到这个报错了。

4. 排查动态加载的脚本 #

如果你的应用有用fetch或者eval动态加载脚本的情况，这些脚本很可能没经过转译，直接在IE11里运行就会触发语法错误。解决办法：

• 把动态加载的脚本提前加入构建流程，确保被Babel转译。
• 或者做浏览器判断，给IE11加载专门的降级版本脚本（比如提前转译好的ES5版本）。

5. 兜底技巧：强制让IE11调试器暂停在报错位置 #

如果上面的方法都不管用，试试这个终极trick：

• 打开IE11的F12开发者工具，切换到「调试器」标签，点击暂停按钮（就是那个类似播放键暂停的图标），然后刷新页面。
• 虽然报错指向blob，但脚本执行到语法错误的瞬间，调试器会强制暂停在对应的代码位置。你可以复制这段代码的特征片段，去你的源码里搜索，就能找到对应的文件了。

内容的提问来源于stack exchange，提问作者Petter Hågholm