Uncaught TypeError: Cannot read property setState of undefined —— 这句报错对React类组件开发者来说基本等同于某种成人礼。我刚带新人的那阵子代码评审里最常出现的翻车就是onClick{this.handleClick}方法明明定义在组件类里运行起来却变成了一个不认识自己主人的函数this直接丢得干干净净。这篇React基础篇专门把this的指向问题掰开揉碎讲清楚。它适合所有刚接触React、或者在类组件和函数组件之间来回切换时被this坑过的人。文章不假设你已经精通JavaScript的this机制我会从最底层的调用规则讲起再逐个分析React场景里的丢失时刻、修复方案以及Hooks时代为什么你仍然需要懂这些。先给结论React类组件里的this丢失根源不在React而在于JavaScript函数调用方式。你把这个底层逻辑理解了后面所有方案都会变得顺理成章。1. this指向问题不是React的锅先理清原生JS的规则1.1 决定this的只有一件事函数是怎么被调用的很多同学对this的困惑来自于函数定义在哪个对象上this就应该指向哪个对象这个直觉。但这个直觉从一开始就是错的。JavaScript里this不是定义时确定的而是调用时确定的。同一个函数用不同方式调用this完全可能是不同的值。先看最基础的两种调用形式function show() { console.log(this); } show(); // 严格模式下是 undefined非严格模式下是 window const obj { name: 计数器, show }; obj.show(); // 这里 this 就是 objshow和obj.show引用的是同一个函数但输出完全不同。关键就一句话谁用点号调用了这个函数this 就是谁。如果你直接写show()前面没有宿主对象那 this 就找不到归属。除了默认调用和点号调用还有两种能主动指定this的方式。call和apply会立即执行函数并临时指定thisbind则返回一个永久绑定了 this 的新函数function show(prefix) { console.log(prefix, this.name); } const a { name: 组件A }; const b { name: 组件B }; show.call(a, call版本); // call版本 组件A const showForB show.bind(b); showForB(bind版本); // bind版本 组件B最后一种是new调用this指向构造函数创建出来的新对象。除了箭头函数日常开发里绝大多数this问题都逃不出这几种情况。我自己的理解方式是把它类比成谁叫你来的。一个函数就像上门服务的师傅物业公司某个对象用对讲机点名让它去某户它知道自己是物业公司派来的但如果是平台随手派发的工单师傅接到的只是一个裸的工号没有宿主自然就不知道自己代表谁了。this丢失本质上就是函数被裸调、宿主信息没有传过去。1.2 严格模式为什么让问题看起来更隐蔽一个很容易被忽视的细节是ES6模块和class内部默认处于严格模式。这意味着当this丢失时它不会像以前那样偷偷变成全局对象window而是直接变成undefined。很多初学者看到undefined反而更懵明明方法就在组件里怎么会是undefined其实这是好事。在严格模式下问题暴露得早你一眼就能看出绑定丢了。如果换成非严格模式this变成window后你调用setState可能只是报一句window.setState is not a function绕得更远。区块级说明React组件里的代码经过编译后也处于严格模式环境所以this丢失时基本都是undefined。这成了下面所有报错的统一形态。1.3 React类组件方法被搬了家丢失发生在哪里React类组件里的普通方法本质上就是定义在类原型上的普通函数。你把组件实例化之后方法和实例之间的关系是实例可以调用原型上的方法但方法本身并没有和实例绑死。写onClick{this.handleClick}时发生的事是你把handleClick这个函数引用从实例上取了下来把它交给React事件系统。React内部机制不会管你原来这个方法属于谁它只关心回调时间到了执行这个函数。执行方式接近于裸调用前面没有组件实例做宿主this自然就丢了。为了加深理解可以做一个对比。下面这行代码是点号调用this稳稳指向实例this.handleClick();而下面这种是取出函数引用再裸调用等同于React事件系统做的事情const fn this.handleClick; fn(); // this 丢失React当然不是故意制造麻烦它只是遵循JavaScript的语言规则。类组件方法不像某些语言里的方法那样自带对象归属感在JS里方法就是函数函数离开了宿主就可以不认账。理解了这一点你就知道接下来所有解决方案本质上都是想办法把 this 和实例重新绑定起来。2. 三个最容易踩的this丢失现场2.1 事件绑定写法onClick{this.handleClick}这是React里最常见、也最典型的丢this现场。哪怕你手上只有一个计数器组件也迟早会遇到class Counter extends React.Component { state { count: 0 }; handleClick() { this.setState({ count: this.state.count 1 }); } render() { return button onClick{this.handleClick}加一/button; } }点击按钮控制台立刻报错Cannot read property setState of undefined。这里undefined就是this。原因上一节已经讲了handleClick作为函数引用被传给了事件系统触发时被裸调调用者信息丢失。如果你好奇为什么不能在JSX里直接把方法挂上去可以试试这样写this反而是正确的button onClick{() this.handleClick()}加一/button这里箭头函数是在render阶段创建的它的外层作用域能拿到组件实例的this于是调用this.handleClick()时点号前面的宿主就是实例。但要注意这种方式每次都创建新函数性能上有自己的问题后面专门说。2.2 定时器与异步回调setInterval(this.tick)事件处理器会丢this异步回调一样会丢。最常见的是定时器class Timer extends React.Component { state { total: 0 }; tick() { // 报错Cannot read property setState of undefined this.setState({ total: this.total 1 }); } componentDidMount() { this.timer setInterval(this.tick, 1000); } componentWillUnmount() { clearInterval(this.timer); } }定时器到点之后setInterval在全局环境下执行传入的回调函数它不会记得这个回调是从哪个组件里取出来的。请求回调也是一模一样的道理fetchData() { fetch(some-url).then(this.processData); }then里的processData同样是裸调用this必然丢失。这类问题在类组件里非常常见因为异步回调天生就把函数和宿主对象拆开了。2.3 解构赋值和方法裸调用const { handleClick } this第三种丢失现场比较隐蔽经常出现在代码重构时。比如你把this上的方法解构出来再用const { handleClick } this; handleClick(); // this 没了解构取值的过程其实和const fn this.handleClick没有本质区别。this本身存储在变量handleClick里但方法体内部的this不会跟过来。类似的情况还有const handlers [this.handleClick]; handlers[0](); // this 丢失 [1, 2, 3].forEach(this.tick); // this 丢失这类问题的排查难度比前两种高因为代码表面上看不出问题。尤其是用数组、高阶函数、函数式工具库时方法被传来传去宿主早就丢了。3. 解决方案横向对比bind、类字段箭头函数、render内联各有什么坑3.1 constructor里bind最经典的做法在React类组件早期官方推荐的方案是在构造函数里用bind显式绑定class Counter extends React.Component { constructor(props) { super(props); this.state { count: 0 }; this.handleClick this.handleClick.bind(this); } handleClick() { this.setState({ count: this.state.count 1 }); } render() { return button onClick{this.handleClick}加一/button; } }bind返回了一个新函数这个新函数的this被永久指向组件实例。因为绑定发生在构造函数里每个实例只执行一次之后render里用的都是同一个函数引用对React.memo或PureComponent的优化非常友好。缺点是代码量会涨。组件里方法一多构造函数里就全是bind行很容易漏绑定。有些人会写一个循环统一绑定constructor(props) { super(props); [handleClick, tick, handleDelete].forEach( method (this[method] this[method].bind(this)) ); }这种写法确实省代码但团队里不是所有人都习惯这种魔法代码可读性会打折扣。我自己的建议是如果你选bind方案就老老实实逐行写出问题的时候排查成本最低。3.2 类字段箭头函数当前项目里的主流现代React项目里我更推荐直接在类里用箭头函数定义方法。这种语法叫类字段不是ES6正式规范但主流构建工具早就默认支持了class Counter extends React.Component { state { count: 0 }; handleClick () { this.setState({ count: this.state.count 1 }); }; render() { return button onClick{this.handleClick}加一/button; } }为什么箭头函数能解决问题因为箭头函数没有自己的 this它只会从创建它的作用域里继承this。类字段在底层相当于在构造函数里给实例赋值箭头函数创建的那一刻外层作用域正好能拿到实例的this于是它把最终的this牢牢记住。以后无论它被谁裸调、传给谁、解构给谁this都不会变。这种写法的优点很直观每个方法都是实例自己的属性不需要在构造函数里绑定代码干净整洁。缺点呢每个组件实例都会为每个方法创建一份函数内存上会多一点点开销但现代应用里这个量级完全可以忽略。对React.memo优化同样友好因为函数引用在实例生命周期里保持不变。要注意的是类字段语法依赖Babel插件。create-react-app这类脚手架从很早就内置了对应支持但如果你的项目是手工搭建的老式Webpack配置需要确认装了babel/plugin-proposal-class-properties这类插件否则会编译报错。3.3 render里bind和内联箭头函数方便但副作用明显很多初学者为了省事直接在JSX里绑定button onClick{this.handleClick.bind(this)}加一/button或者button onClick{() this.handleClick()}加一/button这两种写法都能让this不丢但它们有一个共同的副作用每次 render 都会创建新的函数引用。如果你的子组件用了React.memo或PureComponent它比较新旧props时发现onClick的引用每次都变了memo 对比直接失效子组件就会被强制重新渲染。场景放大一下一个列表组件里渲染500个子项每个子项都通过内联箭头函数传递回调那么每次父组件渲染都会凭空多出500个新函数。这些函数很快又被垃圾回收白白增加分配和回收开销。小项目无所谓大列表或者高频更新的复杂页面性能影响是能感受到的。所以我的结论是内联绑定适合临时调试、或者确信心跳很低的小组件不适合作为团队规范大面积使用。正确做法是在构造函数或类字段层面解决问题JSX里只写最干净的{this.handleClick}。3.4 事件传参的正确姿势this问题解决之后很多人会在传参时又踩一轮坑。常见的需求是onClick触发时需要知道这是哪一行的数据比如id。如果方法已经用bind绑定过可以直接这么传constructor(props) { super(props); this.state { list: [] }; this.handleDelete this.handleDelete.bind(this); } handleDelete(id, event) { // 第一个参数是 id第二个参数是原生事件对象 } render() { return ( button onClick{this.handleDelete.bind(this, item.id)} 删除 /button ); }注意bind的传参规则bind的第一个参数是this从第二个参数开始会按顺序传给原函数。所以handleDelete.bind(this, item.id)执行时handleDelete收到的第一个参数就是item.id事件对象会被自动放在最后一个参数位置。如果方法是用类字段箭头函数写的传参一般需要在外面包一层handleDelete (id) { // 处理 id }; button onClick{() this.handleDelete(item.id)}删除/button这又会变成每次渲染新函数。想彻底避免可以绕一下把数据放在>button>function Counter() { const [count, setCount] useState(0); const handleClick () setCount(count 1); return button onClick{handleClick}加一/button; }这里没有方法归属问题没有bind没有类字段箭头函数只有普通的闭包变量。函数组件的每次执行都有自己的作用域handleClick直接使用外层的count和setCount天然正确。当你理解了类组件里this为什么会丢再去看Hooks会更容易理解它想解决什么函数式编程里数据流和闭包替代了对象方法调用的宿主依赖心智负担大幅下降。这也是为什么很多团队迁移Hooks之后代码里的怎么确保this正确这类对话几乎消失。4.3 类组件与函数组件混用时的隐形坑虽然Hooks绕开了this但现实项目很少是纯函数组件。你把一个函数子组件接到类父组件上时仍然要小心this类的问题。举个例子class Parent extends React.Component { print() { console.log(from parent, this); } render() { return Child onPrint{this.print} /; } } function Child({ onPrint }) { // 点击按钮时onPrint() 裸调用Parent实例的this已丢失 return button onClick{onPrint}打印/button; }Parent的print是原型上的普通方法传给Child后如果在Child内部直接调用onPrint()this就没了。你可能会觉得我都传到子组件了父组件里没问题啊问题恰恰出在接收方怎么调用上。这种混用场景要求你随时能判断这个函数被调用时点号前面站着谁。如果是裸调用那就必须保证这个函数已经被绑定过了或者直接用箭头函数定义。类字段箭头函数在这种场景里是相对保险的因为它从一开始就锁死了this。5. 排查this问题的一套调试流程5.1 第一步在方法里直接打印this遇到this相关报错我建议第一反应就是打印它而不是猜handleClick() { console.log(this); // 先看是 undefined 还是组件实例 this.setState({ count: this.state.count 1 }); }结果无非两种。打印出来是undefined说明绑定铁定丢了从调用方式入手查打印出来是组件实例那问题不在this往setState、props、事件对象的方向查。这一步能快速定位方向避免在一堆代码里瞎猜。5.2 用调用栈找到真正的调用者打印只能判断有没有丢想搞清楚丢在哪一环要借助浏览器的调用栈。操作步骤很简单在方法第一行打断点点击按钮触发报错打开DevTools的Sources面板查看右侧的Call Stack调用栈会展示一层一层的调用关系你能看到到底是onClick内部直接裸调了这个函数还是中间经过了某个高阶函数、某个工具方法。栈里出现裸函数调用的那一层就是this脱轨的位置。这种排查方式比单纯加日志快得多尤其适合那种方法被传了三四层才被调用的复杂场景。我甚至见过有人排查this问题花了一下午最后发现是把函数传给第三方库做异步回调时丢的——调用栈一眼就能看出来。5.3 从代码习惯上预防ESLint与团队规范事后排查再熟练也不如提前约束。类组件里的方法绑定方式最好在团队里统一成一种风格。我的习惯是能写函数组件就写函数组件必须写类组件时事件方法一律使用类字段箭头函数避免bind和普通方法混用。ESLint的eslint-plugin-react里有相关规则比如jsx-no-bind它会直接警告JSX里出现内联bind或箭头函数传参。这类规则能挡住相当一部分每次都新建函数的写法。配合代码评审时重点盯方法被传出组件的地方基本能把这些this坑挡在发布之前。最后分享一点个人体会。我刚学React的时候面对this也走了不少弯路总想在React里找特殊规则后来才发现答案全在原生JavaScript里。把这个概念想通之后类组件、函数组件、Hooks之间的切换都顺了。如果你现在还在被this折磨不用急着背方案先回到函数调用规则这一层把点号调用、裸调用、bind、箭头函数这四件事想明白React里的所有this问题都会迎刃而解。
