eslint-plugin-react 中关于对象类型默认属性的检测问题分析

问题背景

在 React 开发中，我们经常使用 eslint-plugin-react 来保证代码质量和一致性。其中 react/no-object-type-as-default-prop 规则用于检测组件中是否使用了对象类型作为默认属性值，因为这样做可能导致意外的共享状态和性能问题。

问题现象

最近发现该规则存在一个特殊情况下的检测缺陷：当组件函数接收第二个参数时（无论是 ref 还是 context），规则会跳过检测。这意味着以下两种写法中，只有第一种会被正确检测：

// 会被检测（正确报错）
const ComponentA = ({ foo = {} }) => null;

// 不会被检测（应该报错但实际跳过）
const ComponentB = ({ foo = {} }, ref) => null;

技术分析

这个问题的根源在于规则的实现逻辑。当前规则在处理函数参数时，只检查第一个参数（props）的情况，当函数有多个参数时就会跳过检测。这种设计存在两个问题：

1. React 组件确实可以接收第二个参数（context），但这不应该影响对默认 props 的检测
2. 使用 forwardRef 时，ref 作为第二个参数传入，同样需要被检测

影响范围

这个缺陷会影响以下常见场景：

1. 使用 React.forwardRef 创建的可转发 ref 组件
2. 使用 contextType 或 useContext 的传统类组件
3. 任何接收 context 作为第二个参数的函数组件

解决方案

正确的实现应该：

1. 无论函数有多少个参数，都应该检查第一个参数（props）的默认值
2. 特别处理 forwardRef 的情况，确保其回调函数中的 props 也被检查
3. 保持对常规函数组件和箭头函数组件的检测能力

最佳实践建议

在等待官方修复的同时，开发者可以：

1. 手动检查所有使用 forwardRef 的组件
2. 避免在任何组件中使用对象字面量作为默认值
3. 对于必须的对象默认值，使用 useMemo 或类静态属性替代

总结

这个 eslint 规则的缺陷提醒我们，即使是成熟的工具链也可能存在边界情况的问题。作为开发者，我们应当理解工具背后的原理，而不仅仅依赖其表面行为。对于 React 组件设计，始终避免使用可变对象作为默认属性值是一个值得坚持的好习惯。