企业官网建设流程全解析

• 开发工具
• 代码质量
• 静态分析

react/no-this-in-sfc是 eslint-plugin-react 提供的一条"可能错误（Possible Errors）"类检查规则，专门用于在无状态函数组件（Stateless Functional Component，简称 SFC）中拦截对this的误用。React 存在类组件与函数组件两种编写风格，二者获取 props、context、state 的方式截然不同，混用极易在"类组件转函数组件"或初学者不熟悉差异时埋下隐性 bug。读完本文，你将理解该规则检测的误用场景、合法与非法代码的边界、正确的改写方式，以及其底层基于 AST 与作用域分析的实现原理。

规则背景：两种组件风格的本质差异

在 React 中组件分为两类：

• 类组件：class Foo extends React.Component {...}，通过this访问实例属性，例如this.props.foo、this.state、this.context；
• 无状态函数组件（SFC）：function Foo(props, context) {...}，props 与 context 以两个函数参数形式传入，函数体内没有state——即使引入 Hooks 也不会改变这一点，SFC 中的局部状态通常应交给React.useState()这类 Hook 管理。

由于两者访问数据的方式完全不同，在函数组件里试图访问this上的属性有时虽然"恰好能运行"，但绝大多数情况下都是错误：要么是开发者不熟悉两种组件风格的差异，要么是把类组件改写成 SFC 时漏改了某处this引用。这条规则的价值就在于把这类"看起来能跑、实则指向错误对象"的代码在编译期揪出来。

从源码注释（lib/rules/no-this-in-sfc.js）可以看出，规则的作用对象就是 "stateless functional components"，并在命中时报告消息Stateless functional components should not use \this``。

Rule Details：规则检测什么

规则监听成员表达式（MemberExpression），当表达式主体是ThisExpression（即this.xxx）且该this位于某个无状态函数组件内部时，即判定为违规。该规则没有可配置项（schema: []），不提供自动修复（无fixable），属于非 recommended规则（README 规则总表 中该行未在 recommended 列勾选），需要开发者按需显式启用。

错误代码示例

以下代码均会触发react/no-this-in-sfc报告：

function Foo(props) { return ( <div>{this.props.bar}</div> ); }

function Foo(props) { const { bar } = this.props; return ( <div>{bar}</div> ); }

function Foo(props, context) { return ( <div> {this.context.foo ? this.props.bar : ''} </div> ); }

function Foo(props, context) { const { foo } = this.context; const { bar } = this.props; return ( <div> {foo ? bar : ''} </div> ); }

function Foo(props) { if (this.state.loading) { return <Loader />; } return ( <div> {this.props.bar} </div> ); }

function Foo(props) { const { loading } = this.state; const { bar } = this.props; if (loading) { return <Loader />; } return ( <div> {bar} </div> ); }

注意最后两个示例中出现的this.state.loading：SFC 本身没有 state，这种写法在运行时几乎必然出错，属于规则重点拦截的高危模式。

正确代码示例

改写方式很简单：把this.props/this.context换成函数参数props/context，或直接对参数解构：

function Foo(props) { return ( <div>{props.bar}</div> ); }

function Foo(props) { const { bar } = props; return ( <div>{bar}</div> ); }

function Foo({ bar }) { return ( <div>{bar}</div> ); }

function Foo(props, context) { return ( <div> {context.foo ? props.bar : ''} </div> ); }

function Foo(props, context) { const { foo } = context; const { bar } = props; return ( <div> {foo ? bar : ''} </div> ); }

function Foo({ bar }, { foo }) { return ( <div> {foo ? bar : ''} </div> ); }

如何在 ESLint 中启用

该规则不在react/recommended、react/all预设配置中（configs 目录下的 recommended.js 与 all.js 均未包含此规则），需要自行显式配置。在传统.eslintrc中：

{ "plugins": ["react"], "rules": { "react/no-this-in-sfc": "error" } }

在 ESLint 9 的 flat config 中：

import react from 'eslint-plugin-react'; export default [ { files: ['**/*.{js,jsx}'], plugins: { react }, languageOptions: { parserOptions: { ecmaFeatures: { jsx: true } }, }, rules: { 'react/no-this-in-sfc': 'error', }, }, ];

规则插件在 lib/rules/index.js 中注册，键名为no-this-in-sfc。

源码实现原理

命中判定链路

规则主体（lib/rules/no-this-in-sfc.js）通过Components.detect(...)包裹，其核心逻辑如下：

MemberExpression(node) { if (node.object.type === 'ThisExpression') { const component = components.get(utils.getParentStatelessComponent(node)); if (!component || (component.node && component.node.parent && component.node.parent.type === 'Property')) { return; } report(context, messages.noThisInSFC, 'noThisInSFC', { node }); } }

判定分三步：

1. AST 形态匹配：只关心MemberExpression，且其object必须是ThisExpression（即形如this.xxx）。直接裸写this（不跟随属性访问）不会被命中；
2. 组件归属判断：通过utils.getParentStatelessComponent(node)沿作用域向上查找当前代码位于哪个无状态组件内（见 lib/util/Components.js）；
3. 例外放行：若找不到组件，或组件节点的父节点是Property（对象字面量属性），则跳过不报错。

无状态组件识别

getParentStatelessComponent（lib/util/Components.js 第 637 行起）的实现是：从当前作用域scope开始，逐级向scope.upper回溯，对每一层调用getStatelessComponent(scope.block)，找到第一个无状态组件即返回，遍历到顶层仍未命中则返回null。

而getStatelessComponent的判定相当严格（同文件第 600 行附近）：

• 函数体必须返回 JSX 或null（isReturningJSXOrNull），且位于允许出现组件的位置；
• 非"父组件不是无状态组件"的嵌套场景；
• 具名函数要求首字母大写（isFirstLetterCapitalized），例如Foo会被识别、foo不会——这也是普通小写函数内使用this不会被误报的原因。

关键的例外场景

规则特意放行了Property父节点场景。这对应createReactClass这类对象字面量风格组件：

const Foo = React.createClass({ render: function() { return <div>{this.props.foo}</div>; } });

此处this.props是 createClass 组件实例的合法访问，测试明确将其列为valid（tests/lib/rules/no-this-in-sfc.js）。同理，普通对象的方法（如obj.notAComponent = function () { return this.a || null; }）因为不返回 JSX 而不被视为组件，使用this同样不报错；MeteorValidatedMethod的run方法内部使用this.connection.id也属于合法边界，均被测试覆盖为通过用例。

测试验证：规则的边界行为

规则测试文件 tests/lib/rules/no-this-in-sfc.js 从正反两面验证了规则行为，可以总结出以下边界规则：

• 函数组件内的this.props/this.state/this.context：无论出现在 JSX 表达式、解构赋值还是条件判断中，一律报错（invalid）；
• 箭头函数组件：const Foo = (props) => <span>{this.props.foo}</span>同样报错，说明规则对箭头函数定义的 SFC 同样生效；
• 嵌套函数也逃不掉：组件内嵌套的function onClick(bar) { this.props.onClick(); }同样会被命中，一次代码里出现两处this就会报告两个错误；
• 类组件、createClass 组件、普通函数、对象方法：均不受影响（valid）；
• 类内部的方法与类字段箭头函数：class Foo { bar() { () => { this.something(); } } }中this指向类实例，属于合法用法，不报错。

使用建议

• 该规则适合在全量迁移类组件到函数组件、或团队内同时存在两种组件风格的代码库中启用，能在编译期快速定位遗漏的this引用；
• 由于它只检查"函数组件中的this"，与react/no-deprecated、react/prefer-stateless-function等规则可形成互补，前者负责清理过时写法，后者鼓励将纯展示类组件改造成 SFC——配合no-this-in-sfc即可把迁移过程中的常见错误一并拦截；
• 规则无配置项、无自动修复，报告的错误需要开发者手动把this.props替换为参数props、this.context替换为context，或将 state 迁移到useState等 Hook 中，改写方式可对照上文"正确代码示例"。

• 开发工具
• 代码质量
• 静态分析