运行 Webpack 打包后的页面时，控制台突然抛出 Uncaught TypeError: xxx is not a function。这个报错的字面意思很明确：代码试图调用一个不是函数的值。但真正棘手的地方在于，源码中明明有对应函数，打包后却变成了 undefined 或其他对象。要解决它，不能只盯着报错行，需要回到模块导入导出、打包配置以及浏览器加载顺序这几个层面逐一排查。
一、从报错信息反推模块加载问题
控制台报错中的 xxx 不一定就是源码里的函数名。Webpack 打包时会对模块进行作用域隔离和变量重命名，因此提示里的 xxx 可能是压缩后短名称，也可能是某个导入变量。遇到这行错误，第一步应该展开浏览器 Console 面板中的堆栈信息，查看是哪个 bundle 文件、哪一行抛出的异常。
如果项目使用了生产模式压缩，建议在 Windows 项目根目录（例如 C:\Users\Admin\my-app）打开终端，修改 webpack.config.js 中的 devtool 为 source-map，重新执行 npx webpack --mode production。这样生成的 source map 会让浏览器直接显示源码位置，而不是压缩后的近似行号，排查效率会高很多。
定位到具体模块后，不要急于修改代码。先观察这个函数是通过什么方式导出的，又是通过什么方式导入的。很多此类报错都源于 import 和 export 的语义不匹配，或者模块初始化顺序异常。
二、导入导出不匹配：最常见且最容易修复的一类
ES Module 使用 export default 和 export 区分默认导出与具名导出，CommonJS 则通过 module.exports 和 exports.xxx 暴露内容。Webpack 虽然提供了两者互操作的兼容层，但兼容规则并不是完全透明的。例如一个 CommonJS 模块这样写：
// utils.js
exports.formatDate = function(date) {
return date.toLocaleDateString();
};
如果在业务代码中使用 import formatDate from './utils'，Webpack 会将 module.exports 整个对象作为默认导出返回，此时 formatDate 实际上是一个对象，而不是函数。调用时就会抛出 Uncaught TypeError: formatDate is not a function。正确做法是改成具名导入：
// main.js
import { formatDate } from './utils';
console.log(formatDate(new Date()));
反过来也一样：如果模块通过 export default function hello() {} 导出，却在导入时写成 import { hello } from './hello'，得到的结果同样是 undefined。此外，还要注意 Babel 转译后 export default 会被挂到 exports.default 上，如果手动拼接 CommonJS 与 ES Module 代码，建议统一模块规范，或者显式使用 import xxx from 与 export default 成对出现。
三、循环依赖和 tree shaking：两类隐蔽但常见的触发器
循环依赖并非一定报错，但如果两个模块在初始化阶段就互相调用函数，就可能拿到尚未赋值的绑定。下面这段代码在 Webpack 打包后运行会抛出类似 Uncaught TypeError: a is not a function 的错误：
// a.js
import { b } from './b';
export function a() {
return 'a';
}
console.log(b());
// b.js
import { a } from './a';
export function b() {
return 'b';
}
console.log(a());
原因在于 ES Module 的 live binding 机制：模块初始化时会先建立绑定，然后执行模块体。当 a.js 执行到 console.log(b()) 时，b.js 可能还没有执行完，b 虽然已经被提升为函数声明，但模块自身的初始化顺序会导致部分绑定在调用瞬间不是函数。解决循环依赖的方法是抽离公共逻辑到第三个模块，或者延迟调用到事件回调中，不要在模块顶层立即执行。
tree shaking 是把双刃剑。为了减小体积，Webpack 在生产模式下会移除没有被引用的导出代码。但如果某个模块包含副作用，例如直接修改 window 对象，而 package.json 中设置了 "sideEffects": false，这段副作用代码就可能被整体删除。典型表现是某个依赖库的函数在打包后消失了，调用时报 is not a function。修复方式是把包含副作用的文件加入 sideEffects 数组，例如：
// package.json
{
"sideEffects": [
"./src/side-effect.js",
"*.css"
]
}
四、在 Windows 本地环境中完成验证与修复
修改导入导出方式或配置后，需要重新打包验证。假设项目位于 C:\Users\Admin\my-app，可以直接在终端执行 cd C:\Users\Admin\my-app 后运行 npx webpack --mode production --devtool source-map。生成的产物在 C:\Users\Admin\my-app\dist 目录下，刷新页面后打开浏览器开发者工具的 Sources 面板，搜索对应函数名或模块路径，确认该函数在 bundle 中是否真实存在。
如果问题来自第三方依赖，可以使用 npm ls 依赖名 检查版本树，确认是否安装了两个不同版本。例如项目中同时存在 node_modules\lodash 和 node_modules\some-lib\node_modules\lodash，就可能因版本差异导致导出结构不一致。此时可以尝试升级或锁定依赖版本，并在 Webpack 的 resolve.alias 中强制指向同一个版本。
最后建议把修复过程沉淀为一条排查清单：先看 import 与 export 是否匹配，再查是否存在循环依赖，接着确认 sideEffects 配置是否误伤副作用代码，最后用 source-map 定位打包产物。按这个顺序操作，大多数 Webpack 打包后运行报错 Uncaught TypeError: xxx is not a function 都能在较短时间内定位并解决。
Webpack打包Uncaught TypeErroris not a function修改时间：2026-10-06 13:39:51