为何next-intl不支持在组件内直接定义默认消息？

核心原因：架构设计与工作流优先，包体积是重要考量 #

next-intl这类工具不支持组件内直接写defaultMessage，本质是设计思路的差异，并非单纯为了包体积，不过包体积优化确实是关键因素之一：

1. 分离消息与组件，优化国际化协作
   next-intl采用集中式消息管理，所有翻译文案统一存放在JSON文件中，而非散落在组件代码里。这种设计的优势在于：

• 翻译人员无需接触组件代码，直接处理标准化的翻译文件，降低跨角色协作的门槛；
• 便于统一术语、批量检查缺失翻译，避免同一含义的文案在不同组件中出现不一致表述；
• 支持可靠的静态消息提取：工具可以自动扫描代码中的t('key')调用，一键生成翻译模板，相比从组件defaultMessage中提取，这种方式更稳定（组件内消息可能包含动态逻辑，提取难度高）。

2. 包体积优化：避免冗余代码
   如果允许组件内嵌defaultMessage，这些默认文案会被打包进生产代码——即便用户已经加载了对应语言的翻译文件，这会造成不必要的体积冗余。而集中管理模式下：

• 生产环境仅加载当前用户语言对应的翻译文件；
• 源语言文案（默认消息）可作为单独文件按需加载，或仅在开发环境提供，大幅减少生产包体积。

替代手动维护JSON的工具：自动消息提取 #

你觉得手动添加JSON键值对是“倒退”，其实next-intl本身就提供了解决方案——自动消息提取工具，可以帮你省去手动维护的麻烦：

开发时，你可以在调用t函数时传入默认消息：

const t = useTranslations();
const content = (
  <>
    <h1>{t('title', {defaultMessage: 'Hi there!'})}</h1>
    <p>{t('text', {defaultMessage: 'Since when is developing frontend such a pain?'})}</p>
  </>
);

然后通过next-intl extract命令（需要在package.json中配置对应的脚本），工具会自动扫描所有代码，提取defaultMessage并生成对应的翻译JSON文件。构建时，生产代码中的defaultMessage会被移除，只保留翻译键，既保证了开发体验，又不影响生产性能。

总结 #

这种设计并非“倒退”，而是为了适配更高效的多语言项目工作流——既满足翻译协作的需求，又能优化生产包体积，配合自动提取工具，完全可以兼顾开发便捷性与项目性能。

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