react-i18next：向子组件传t函数还是在每个子组件用useTranslation？

你当前实现的合理性 #

你目前“主页面调用useTranslation获取t、通过props向子组件透传”的开发模式功能上完全可行，不属于错误实现，但从长期工程维护、React性能模型匹配度的角度看，在需要翻译的组件内部直接调用useTranslation获取t函数，是社区公认的更优实践，具体差异和适用场景可以拆解为以下几点：

两种实现方案的优劣对比 #

手动透传t的固有问题 #

• 不可避免的Props钻取成本：当组件嵌套层级较深时，中间层级的组件哪怕完全不需要用到t函数，也必须被动接收、再向下传递t参数，时间久了会让各层组件的props定义变得冗余杂乱，排查props传递逻辑时的认知成本会持续升高
• 额外的重渲染风险：如果没有给透传的t函数做严格的引用稳定处理，只要父组件触发重渲染，就可能连带导致所有接收t的子组件无意义重渲染；如果要手动维护t的引用稳定，又会额外增加和业务逻辑无关的维护工作量
• 组件复用性受限：一旦将子组件设计为必须从props接收t才能运行，后期想把这类组件抽成全局公共组件、或者迁移到其他路由页面时，就需要额外补充传t的适配逻辑，无法实现开箱即用

组件内直接调用useTranslation的核心优势 #

• 彻底消除Props钻取：任何有翻译需求的组件，都可以通过钩子直接获取t函数，不需要依赖上层组件的传递，组件的边界定义更清晰
• 性能表现更可控：react-i18next对useTranslation钩子做了底层优化，t函数的引用本身是稳定的，语言切换时只会精准触发“订阅了对应翻译内容、且实际用到的翻译key发生变更”的组件重渲染，不会带来无差别的全链路重渲染问题
• 维护成本更低：不需要在每一层组件的类型定义中重复声明t的props类型，写组件时不需要额外思考“t需要从哪里来”，只需要在需要翻译的位置加一行const { t } = useTranslation()即可

透传t的合理适用场景 #

透传t的模式并不是完全没有价值，在以下特定场景下反而比直接调用钩子更合适：

• 当你需要给某个局部组件自定义翻译上下文（比如临时切换专属翻译命名空间、覆写翻译取值规则）时，直接通过props传入自定义的t实例是最简洁的实现方式
• 当你需要锁定组件内的翻译快照（比如复杂表单场景下，不希望用户切换语言时表单内的提示文本动态跳变）时，透传固定引用的t实例，可以避免动态订阅带来的状态不一致问题
• 当你处理的是无法调用React钩子的非React逻辑、或者纯函数类辅助组件时，从父层获取t后透传是可落地的实现路径

常见认知误区澄清 #

很多开发者会误以为“每个组件都调用useTranslation会造成大量重复的上下文订阅、拖慢应用性能”，这个判断已经不符合当前react-i18next的实现逻辑：

新版本的react-i18next中，所有调用useTranslation的组件共享同一个全局订阅源，不会因为钩子调用次数的增加带来线性的性能损耗；同时钩子内部做了细粒度的翻译key匹配，语言切换时的重渲染范围比手动透传方案更精准，实际性能表现更优。

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