React自定义Hook为何要以use为前缀？是命名约定还是内部机制？

核心结论 #

use前缀不是无意义的命名约定，是整个React生态识别Hook函数的统一静态标识。React运行时本身虽然不会在生产环境强制校验函数名，但ESLint规则、开发调试工具、编译优化链路全靠这个前缀判定函数性质。

ESLint报错的触发逻辑 #

你遇到的报错来自eslint-plugin-react-hooks的rules-of-hooks核心规则，这个规则的校验逻辑非常明确，只有两类函数允许在内部调用useState、useEffect这类内置Hook：

• 首字母大写、返回JSX结构的React函数组件
• 函数名以use开头的自定义Hook
  你编写的customHook既不符合组件命名要求，又没有use前缀，ESLint会直接将其判定为普通工具函数。而普通函数的执行时机不受React渲染周期管控，在内部调用Hook极容易破坏「Hook调用顺序在每次渲染中必须完全一致」的核心要求，因此会直接抛出校验错误。

这里需要澄清对官方文档的常见误解：文档提到“自定义Hook和普通函数完全一样”，仅指自定义Hook没有强制的函数签名要求——你可以自由定义入参、返回值格式，不代表它和普通函数没有识别边界，这个边界就是use前缀。

强制使用use前缀的工程价值 #

很多人会疑惑既然运行时不校验，为什么非要强制加前缀，核心价值有两点：

• 降低认知成本，避免规则破坏：所有开发者看到use开头的函数，能立刻意识到这是一个Hook，必须遵守Hook调用规则——只能在组件或其他自定义Hook的顶层调用，不能放在条件判断、循环、普通回调里执行。如果没有这个统一前缀，你无法快速区分普通工具函数和包含React状态逻辑的Hook，团队协作时非常容易写出违反Hook规则的代码，引发状态错乱、渲染异常等极难排查的问题。
• 适配全链路工具支持：除了ESLint校验，React DevTools、React编译优化工具、测试工具、周边生态库的Hook相关能力，全都是基于use前缀识别自定义Hook的。比如React DevTools会在调试面板中单独展示自定义Hook的内部状态，不加前缀的函数会被直接判定为普通逻辑，无法享受对应的调试能力；React 18+的自动批处理、服务端组件边界校验等特性，在做静态代码分析时也会参考这个前缀做逻辑判断。

两个示例函数的实际差异 #

你写的useCustomHook和customHook虽然内部逻辑完全一致，但工具链对二者的判定完全不同：

• useCustomHook会被识别为合法自定义Hook，所有Hook相关的校验、调试、优化逻辑都会正常生效
• customHook会被判定为普通函数，只要内部调用Hook就会触发ESLint报错，即使强行关闭校验规则使用，也会丢失生态工具的所有Hook相关支持，后续迭代时很容易引入隐蔽Bug

内容的提问来源于stack exchange，提问作者DecPK