国际化面试题

本题库共收录 66 道面试题（基础 15 / 进阶 29 / 深入 14 / 架构 8）。本文件收录国际化相关面试题，目标题量 150 道。题型覆盖：概念题、场景设计题、系统设计题、工程化题、性能优化题、安全题、软技能题、综合开放题。难度覆盖：基础、进阶、深入、架构。每道题除标准参考答案外，另附口头回答版，便于面试时快速组织语言。

基础题（8 道）

FB-33-CO-B-001：i18n 与 l10n 有什么区别？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：33 国际化标签：i18n、l10n、国际化、本地化 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释国际化（i18n）与本地化（l10n）的区别，并举例说明。

参考答案：

i18n（Internationalization）：国际化，是产品具备支持多语言/多地区的能力。它发生在产品开发阶段，强调架构和代码层面的可扩展性。
- 例如：使用翻译 key 而非硬编码文案、支持 RTL、时区/数字格式化、分离文化与代码。
l10n（Localization）：本地化，是把产品适配到特定地区的过程。它发生在内容/运营阶段。
- 例如：把中文翻译成英文、把日期格式改为 MM/DD/YYYY、使用当地货币、调整图标颜色/图片以符合文化习惯。

关系：

i18n 是 l10n 的基础；没有好的国际化架构，本地化成本高、易出错。
l10n 不仅包括翻译，还包括法律、文化、UX 习惯等。

评分维度：

概念区分（50%）：i18n 能力 vs l10n 适配
举例能力（30%）：翻译、格式、文化
关系理解（20%）：基础与过程

常见错误：

把 i18n 简单等同于“做多语言翻译”。
认为先写死中文再改也来得及，忽视架构成本。

延伸追问：

全球化（g11n）与 i18n、l10n 的关系是什么？
本地化是否包括合规（如 GDPR、个保法）？

相关题目：

FB-33-CO-A-001 i18n 框架选型
FB-33-SD-R-001 设计全球化前端架构

参考资源：

W3C i18n

口头回答版：

i18n 国际化是产品具备支持多语言多地区的能力，比如用 key 而不是硬编码、支持 RTL；l10n 本地化是把它适配到具体地区，比如翻译、改日期格式、用当地货币。i18n 是 l10n 的基础。

FB-33-CO-B-002：locale 标识应该如何选择与管理？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：33 国际化标签：locale、BCP 47、语言标签、区域 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明 locale 的常见格式（如 zh-CN、en-US），并说明前端如何选择和切换 locale。

参考答案：

Locale 格式：

推荐遵循 BCP 47，如 language[-script][-region][-variant]。
常见示例：zh-CN、zh-Hans、en-US、en-GB、ja-JP。
区分语言与区域很重要：比如 en-US 和 en-GB 在日期、货币、拼写上不同。

选择与切换：

用户显式选择：优先级最高，保存到 Cookie/localStorage/账号偏好。
URL 路径/域名：如 /zh-CN/docs 或 zh.example.com，利于 SEO。
浏览器语言：navigator.language / navigator.languages 作为默认。
IP/账号区域：兜底策略，但需尊重用户选择。

管理要点：

统一 locale 解析函数，处理大小写、下划线转连字符（zh_CN -> zh-CN）。
维护支持的 locale 列表与回退链（如 zh-Hans-CN -> zh-Hans -> zh -> en）。
切换时重新加载语言包并刷新相关组件。

评分维度：

格式规范（40%）：BCP 47、语言-区域
选择策略（40%）：显式、URL、浏览器、IP
回退管理（20%）：解析、回退链

常见错误：

只根据 navigator.language 强制设定，不尊重用户选择。
locale 格式不统一，导致匹配失败。

延伸追问：

如何支持同一语言多地区（如西班牙语在西班牙和拉美）？
locale 切换后数字/日期格式如何同步更新？

相关题目：

FB-33-CO-B-005 日期/时间/数字/货币格式化
FB-33-CO-A-002 多语言路由与 SEO

参考资源：

BCP 47 Language Tags

口头回答版：

locale 推荐用 BCP 47 格式，比如 zh-CN、en-US。选择优先级：用户显式选择最高，然后是 URL、浏览器语言、IP 兜底。要统一解析、维护回退链，切换时重载语言包。

FB-33-CO-B-003：翻译文件应该如何组织？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：33 国际化标签：翻译文件、JSON、YAML、命名空间、目录结构 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明前端项目中翻译文件的组织方式，包括目录结构、命名空间和拆分策略。

参考答案：

组织方式：

locales/
  en/
    common.json
    home.json
    user.json
  zh-CN/
    common.json
    home.json
    user.json

设计要点：

按语言分目录：每个 locale 一个目录，便于打包和加载。
按页面/模块分命名空间：避免单个文件过大，支持按需加载。
通用与业务分离：common.json 放全局文案，user.json 放用户模块。
key 语义化：如 home.title、user.login.button，避免用英文句子作 key。
插值占位符：使用 {{name}} 或 {count}，避免硬编码拼接。
版本管理：翻译文件纳入版本控制或 TMS，方便 diff 和回滚。

加载策略：

首屏加载核心语言包，路由切换时懒加载对应命名空间。
构建时按 locale 拆分为独立 chunk。

评分维度：

目录结构（40%）：按语言、模块组织
key 设计（30%）：语义化、插值
加载策略（30%）：按需、懒加载、拆分

常见错误：

所有文案塞一个文件，导致首包过大。
key 用英文原文，修改后所有引用都要改。

延伸追问：

如何支持一个 key 在不同上下文有不同翻译？
翻译文件过大时如何分包？

相关题目：

FB-33-CO-A-001 i18n 框架选型
FB-33-PE-P-001 语言包体积优化

参考资源：

i18next Namespaces

口头回答版：

翻译文件按语言分目录、按模块分命名空间，比如 locales/zh-CN/common.json、home.json。key 要语义化，用插值占位符。首屏加载核心包，其他路由懒加载。避免一个文件过大。

FB-33-CO-B-004：如何处理复数、性别、占位符等复杂文案？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：33 国际化标签：复数、性别、占位符、ICU MessageFormat、插值 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明国际化中复数、性别、占位符的处理方式，并给出示例。

参考答案：

使用 ICU MessageFormat 或框架内置插值：

占位符：

Hello, {name}!

复数：

{count, plural, =0 {No messages} one {1 message} other {# messages&#125;&#125;

不同语言复数规则不同（如俄语有 one/few/many/other），不能简单用 count > 1 判断。

性别/人称：

{gender, select, male {He} female {She} other {They&#125;&#125; liked this.

嵌套：

占位符中可嵌套复数和选择，但避免过度复杂导致翻译困难。

前端实践：

使用 react-intl / vue-i18n / formatjs 等支持 ICU 的库。
不要把多个字符串拼接成句子，应使用带占位符的完整模板。
给翻译人员提供上下文注释（context）。

评分维度：

ICU/插值（40%）：占位符、复数、select
语言差异意识（30%）：不同语言复数规则
工程实践（30%）：避免拼接、提供上下文

常见错误：

用字符串拼接实现复数，导致翻译无法适配其他语言。
忽略阿拉伯语、俄语等复杂复数规则。

延伸追问：

中文没有复数变化，如何设计 key 以适应多语言？
如果占位符需要 HTML，如何安全渲染？

相关题目：

FB-33-CO-B-003 翻译文件组织
FB-33-CO-A-001 i18n 框架选型

参考资源：

ICU Message Format

口头回答版：

复杂文案用 ICU MessageFormat，比如 {count, plural, one {} other {}} 处理复数，用 {gender, select, ...} 处理性别。占位符用 {name}。不同语言复数规则不同，不能拼接字符串。要提供上下文注释。

FB-33-CO-B-005：日期、时间、数字、货币格式化要注意什么？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：33 国际化标签：日期格式化、数字格式化、货币、时区、Intl 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明国际化中日期、时间、数字、货币格式化的常见要求和前端实现方式。

参考答案：

使用浏览器原生 Intl API 或封装库（date-fns、dayjs、Numeral.js）：

日期时间：

使用 Intl.DateTimeFormat，避免手写格式字符串。
区分长/短格式、是否包含时区。
时区处理：存储 UTC，显示按用户时区转换。
注意 12 小时制/24 小时制差异。

数字：

千分位、小数点、百分号因地区而异（如 1,234.56 vs 1.234,56）。
使用 Intl.NumberFormat。

货币：

金额与币种分离，不要硬编码货币符号。
Intl.NumberFormat('zh-CN', { style: 'currency', currency: 'CNY' })。
注意汇率换算应在服务端完成。

注意：

服务端存储统一用 ISO 8601 / UTC。
避免在模板中硬编码格式串。
对 SSR 场景，Intl 需在服务端和客户端一致。

评分维度：

API 使用（40%）：Intl.DateTimeFormat、Intl.NumberFormat
时区/UTC（30%）：存储 UTC、显示转换
地区差异（30%）：小数点、12/24 小时制、货币

常见错误：

用 Date.prototype.toLocaleString() 默认行为，结果不稳定。
货币符号写死为 ¥ 或 $，未区分币种。

延伸追问：

SSR 中如何避免服务端和客户端 Intl 输出不一致导致 hydrate 错误？
相对时间（如“2 小时前”）如何国际化？

相关题目：

FB-33-CO-B-002 locale 管理
FB-33-CO-A-003 服务端渲染与国际化

参考资源：

MDN Intl

口头回答版：

日期数字货币用 Intl API，不要手写格式。时间存 UTC，显示按用户时区转。货币和金额分离，汇率服务端算。注意不同地区的小数点、12/24 小时制差异。SSR 要保持服务端客户端一致。

FB-33-CO-B-006：RTL（从右到左）布局如何支持？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：33 国际化标签：RTL、从右到左、CSS、双向文本、阿拉伯语、希伯来语 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明前端如何支持阿拉伯语、希伯来语等 RTL 语言，包括 CSS、图标和交互。

参考答案：

CSS 支持：

使用逻辑属性：margin-inline-start/end、padding-inline-start/end、border-inline-start/end。
避免固定 left/right，改用 inset-inline-start/end。
设置 dir="rtl" 或 CSS direction: rtl。
使用 CSS 变量或 postcss 插件做 LTR/RTL 转换（如 rtlcss）。

图标与镜像：

方向性图标（箭头、进度条、返回按钮）需要水平翻转。
使用 SVG 图标时可通过 CSS transform: scaleX(-1) 或准备 RTL 版本。

文本：

混合 LTR 与 RTL 文本时使用 <bdi> 或 dir="auto" 保证方向正确。
使用 Unicode 双向算法（UBA）。

交互：

轮播、滑块、手势方向需适配 RTL。
时间轴、步骤条从右向左排列。

测试：

用真实 RTL 语言测试布局，不要仅靠镜像工具。

评分维度：

CSS 逻辑属性（40%）：inline/start/end 替代 left/right
图标镜像（20%）：方向性图标翻转
文本方向（20%）：bdi、UBA
交互适配（20%）：轮播、手势、时间轴

常见错误：

只把文字右对齐，忽略图标和交互方向。
使用绝对定位的 left/right 导致 RTL 错位。

延伸追问：

如何在不重写样式的情况下支持 RTL？
图表、日历组件支持 RTL 有哪些特殊处理？

相关题目：

FB-33-CO-P-002 RTL 与复杂组件
FB-33-SD-R-001 设计全球化前端架构

参考资源：

MDN RTL

口头回答版：

支持 RTL 要用 CSS 逻辑属性如 margin-inline-start 替代 left/right，图标要镜像，混合文本用 bdi，轮播和手势方向也要反过来。最好用真实 RTL 语言测试。

FB-33-CO-B-007：如何动态加载语言包？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：33 国际化标签：动态加载、语言包、懒加载、代码分割 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明前端如何实现语言包的按需加载和切换，避免首屏加载所有语言资源。

参考答案：

实现方式：

Webpack/Vite 动态导入：

const messages = await import(`./locales/${locale}.json`);

i18next HTTP backend：运行时从 CDN/服务器加载对应命名空间。
按路由懒加载：进入某个路由时再加载该模块的翻译文件。

切换流程：

检测 locale 变化。
卸载旧语言包或保留作为回退。
异步加载新语言包。
更新 i18n 实例语言并触发 UI 刷新。
保存用户偏好。

优化：

预加载用户可能切换的邻近语言。
对语言包做 gzip/Brotli 压缩。
缓存到 localStorage/Service Worker，下次直接读取。
使用 CDN 加速语言包分发。

评分维度：

动态加载方式（40%）：import()、HTTP backend、路由懒加载
切换流程（30%）：加载、刷新、保存偏好
优化（30%）：预加载、压缩、缓存

常见错误：

打包所有语言到一个 bundle，导致首包过大。
切换语言时不显示 loading，用户以为卡顿。

延伸追问：

语言包加载失败如何回退？
SSR 场景下动态加载语言包要注意什么？

相关题目：

FB-33-PE-P-001 语言包体积优化
FB-33-CO-A-003 服务端渲染与国际化

参考资源：

i18next Lazy Loading

口头回答版：

语言包用动态 import 或 i18next HTTP backend 按需加载，按路由懒加载命名空间。切换时异步加载新包、刷新 UI、保存偏好。可以预加载邻近语言、压缩、缓存到 localStorage。避免打包所有语言到首包。

FB-33-CO-B-008：国际化测试应该覆盖哪些方面？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：33 国际化标签：国际化测试、伪本地化、布局、回归 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明国际化测试的常见类型和关键检查点。

参考答案：

国际化测试类型：

伪本地化（Pseudo-localization）：把字符串替换为加长版、含重音符号的版本，检查布局是否溢出。
功能测试：切换语言后页面功能是否正常。
布局测试：检查 RTL 语言、长文本、不同字体下的 UI 是否错位。
格式化测试：日期、数字、货币、复数在不同 locale 下是否正确。
内容测试：确保翻译完整，无遗漏 key 或英文残留。
回归测试：新增功能在多语言下验证。

关键检查点：

文案截断或重叠。
图标方向、镜像是否正确。
时区转换是否正确。
表单校验提示是否翻译。
路由、SEO 标签是否正确切换。
多语言下的性能（语言包加载、渲染）。

自动化：

使用 i18next-scanner 检查未翻译 key。
截图对比（Visual Regression）不同语言布局。
在 CI 中跑伪本地化构建。

评分维度：

测试类型（40%）：伪本地化、功能、布局、格式化、内容
检查点（40%）：溢出、图标、时区、表单、路由
自动化（20%）：扫描、截图、CI

常见错误：

只测试默认语言，上线后才发现多语言布局问题。
忽略表单校验、错误提示的翻译。

延伸追问：

伪本地化是否会影响自动化测试断言？
如何高效测试几十种语言？

相关题目：

FB-33-CO-B-006 RTL 布局支持
FB-33-CP-R-003 国际化度量与监控

参考资源：

i18next Pseudo Localization

口头回答版：

国际化测试要做伪本地化检查布局溢出、切换语言功能测试、RTL 布局、日期数字格式化、内容完整性。还要检查表单提示、路由 SEO。可用 i18next-scanner 找未翻译 key、视觉回归截图、CI 跑伪本地化构建。

进阶题（8 道）

FB-33-CO-A-001：前端 i18n 框架如何选型？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：33 国际化标签：i18n 框架、react-i18next、vue-i18n、FormatJS、Intl 出现频率：高频 预计回答时长：5-7 分钟

题目描述：请比较主流前端国际化框架（如 react-i18next、vue-i18n、FormatJS/ react-intl），并给出选型建议。

参考答案：

框架	生态	特点	适用
react-i18next	React	功能全面、插件丰富、SSR 友好	大中型 React 项目
vue-i18n	Vue	与 Vue 集成好、Composition API 支持	Vue 2/3 项目
FormatJS / react-intl	React	基于 ICU、提供底层 Intl 抽象	需要 ICU、自定义渲染
Lingui	React/Vue	编译时提取、类型安全、体积小	追求性能与类型安全

选型维度：

框架匹配：优先选择与前端框架深度集成的库。
ICU 支持：复杂复数、性别需要 ICU。
SSR/SSG：框架是否支持服务端渲染和 hydrate。
体积：运行时大小、是否支持 tree-shaking。
开发体验：TypeScript 支持、提取工具、IDE 插件。
生态：插件（HTTP backend、检测、伪本地化）、社区活跃度。

建议：

React 项目：react-i18next 或 Lingui。
Vue 项目：vue-i18n。
需要高度定制 ICU：FormatJS。

评分维度：

框架对比（40%）：功能、生态、体积
选型维度（40%）：ICU、SSR、TS、体积
建议合理性（20%）：结合场景推荐

常见错误：

选型只看流行度，忽略 ICU 和 SSR 需求。
多个项目各自引入不同框架，导致团队学习成本高。

延伸追问：

如果要在 React 和 Vue 两套项目中统一国际化方案，怎么做？
编译时提取与运行时提取各有什么优劣？

相关题目：

FB-33-CO-B-003 翻译文件组织
FB-33-SD-R-001 设计全球化前端架构

参考资源：

i18next Comparison

口头回答版：

React 常用 react-i18next 或 Lingui，Vue 用 vue-i18n，需要高度 ICU 用 FormatJS。选型看框架匹配、ICU 支持、SSR、体积、TypeScript 和生态。团队内尽量统一。

FB-33-CO-A-002：多语言路由与 SEO 如何设计？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：33 国际化标签：多语言路由、SEO、hreflang、SSR、子目录、子域名 出现频率：高频 预计回答时长：5-7 分钟

题目描述：请说明支持多语言的网站在 URL、SEO、服务端渲染方面的设计要点。

参考答案：

URL 策略：

子目录：/zh-CN/products、/en-US/products。推荐，权重集中，维护简单。
子域名：zh.example.com、en.example.com。适合多地区独立运营。
顶级域名：example.cn、example.com。成本高，适合大型本地化业务。
URL 参数：?lang=zh。不推荐 SEO。

SEO 要点：

每个页面添加 hreflang 标签，指明不同语言/地区版本。
HTML lang 属性与当前 locale 一致。
提供 x-default 默认版本。
避免不同语言内容混在同一 URL。
生成 sitemap 时包含各语言 URL。

SSR/SSG：

服务端根据 URL locale 渲染对应语言。
预渲染各语言版本页面，提升首屏和 SEO。
注意服务端与客户端 locale 一致，避免 hydrate 错位。

内容：

元信息（title、description、OG 标签）也要翻译。
图片 alt、JSON-LD 结构化数据也要本地化。

评分维度：

URL 策略（30%）：子目录、子域名、参数
SEO 实践（40%）：hreflang、lang 属性、sitemap
SSR/SSG（30%）：服务端渲染、hydrate 一致

常见错误：

只在前端切换语言，URL 不变，搜索引擎无法索引多语言。
hreflang 配置错误，导致搜索引擎混淆。

延伸追问：

如何让用户切换语言后 SEO 权重不分散？
动态路由的多语言参数如何管理？

相关题目：

FB-33-CO-B-002 locale 管理
FB-33-CO-A-003 服务端渲染与国际化

参考资源：

Google hreflang guidelines

口头回答版：

多语言 URL 推荐子目录如 /zh-CN/products，SEO 要加 hreflang、html lang 属性、sitemap。SSR 按 URL locale 渲染，元信息和图片 alt 也要本地化。不要只用前端切换导致 SEO 无法索引。

FB-33-CO-A-003：服务端渲染与国际化如何结合？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：33 国际化标签：SSR、国际化、hydrate、locale、翻译包 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请说明在 SSR/SSG 项目中实现国际化的关键点，以及如何避免 hydrate 不一致。

参考答案：

关键点：

locale 确定：服务端从 URL、Cookie、请求头 Accept-Language 解析 locale。
语言包加载：服务端同步加载对应 locale 的翻译资源，或提前注入到 HTML。
渲染：服务端使用确定的 locale 渲染完整 HTML，包括 lang 属性、dir、格式化输出。
客户端 hydrate：客户端读取服务端注入的 locale 和初始状态，避免二次请求或重新渲染。

避免 hydrate 不一致：

服务端和客户端使用同一份 locale 和翻译数据。
不要在服务端使用 navigator.language（服务端没有 navigator）。
日期/数字格式化使用相同 Intl 配置。
避免在 render 阶段读取随机数或时间等不稳定值。
对不支持 Intl 的环境做 polyfill。

SSG：

为每种 locale 生成独立页面（/en-US/about、/zh-CN/about）。
构建时加载所有语言包。

性能：

仅注入当前 locale 数据到 HTML，不要把所有语言包都打进去。
使用 CDN 缓存按 locale 分片的页面。

评分维度：

locale 解析（30%）：URL、Cookie、Accept-Language
SSR 渲染（30%）：同步加载、HTML 注入
hydrate 一致（40%）：同一份数据、避免不稳定值

常见错误：

服务端和客户端各自决定 locale，导致内容不一致。
把全部语言包注入 HTML，增大首包。

延伸追问：

如何在 SSR 中支持按用户偏好动态切换语言？
ISR 与多语言结合有哪些坑？

相关题目：

FB-33-CO-A-002 多语言路由与 SEO
FB-33-CO-B-007 动态加载语言包

参考资源：

Next.js i18n Routing

口头回答版：

SSR 国际化要在服务端从 URL/Cookie/Accept-Language 确定 locale，同步加载语言包渲染 HTML，并把 locale 和初始状态注入页面。客户端读取这些状态 hydrate，避免和服务端不一致。不要服务端用 navigator，也不要把所有语言包注入首屏。

FB-33-CO-A-004：翻译缺失与回退策略如何设计？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：33 国际化标签：翻译缺失、回退、fallback、key、开发体验 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请说明国际化中如何处理某个 key 在当前语言下没有翻译的情况，以及如何提升开发体验。

参考答案：

回退策略：

语言回退：zh-Hans-CN -> zh-Hans -> zh -> en。
key 回退：找不到翻译时显示 key 本身或默认语言文案，避免空白。
兜底显示：显示 [missing: key] 或带 emoji 提示，便于开发定位。

开发体验：

开发环境：缺失翻译用显眼占位符，甚至 throw warning。
生产环境：回退到默认语言，并上报缺失 key。
提取工具：i18next-scanner、babel-plugin-i18next-extract 自动从代码提取 key。
类型安全：TypeScript 类型约束可用 key，避免 typo。
翻译平台集成：缺失 key 自动进入 TMS 待翻译队列。

治理：

CI 中检查未翻译 key，阻断合并。
统计各语言覆盖率，低于阈值告警。

评分维度：

回退策略（40%）：语言回退、key 回退、兜底
开发体验（40%）：开发提示、提取、类型、TMS
治理（20%）：CI 检查、覆盖率

常见错误：

缺失时直接显示空白或报错，影响生产。
没有自动提取，导致代码和翻译文件不同步。

延伸追问：

如何在不阻塞发版的情况下处理临时缺失翻译？
翻译 key 的命名空间回退顺序如何设计？

相关题目：

FB-33-CO-B-003 翻译文件组织
FB-33-CO-A-001 i18n 框架选型

参考资源：

i18next Fallback

口头回答版：

翻译缺失时先语言回退，再 key 回退，生产环境显示默认语言并上报。开发环境用显眼占位符。用扫描工具自动提取 key，TypeScript 约束 key，CI 检查未翻译，统计覆盖率。

FB-33-CO-A-005：翻译工作流与 TMS 如何落地？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：33 国际化标签：TMS、翻译工作流、 Crowdin、Phrase、Lokalise 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请描述一个高效的前端翻译工作流，以及 TMS（翻译管理系统）在其中的作用。

参考答案：

工作流：

开发：开发者用 key 写代码，附带上下文注释。
提取：CI 自动扫描代码生成待翻译源文件（如 .pot、JSON）。
上传 TMS：源文件上传到 Crowdin/Phrase/Lokalise。
翻译：译者或机器翻译在 TMS 中翻译，术语库和记忆库保证一致。
审校：QA/本地专家审校。
下载：CI 从 TMS 拉取最新翻译文件。
构建/部署：语言包随应用发布或独立部署到 CDN。
监控：线上检查缺失、错误、用户反馈。

TMS 作用：

集中管理翻译资产。
支持术语库、翻译记忆、机器翻译、审校流程。
提供上下文截图、注释、角色权限。
与 Git/CI 集成，实现自动化同步。

最佳实践：

自动同步，避免人工导出导入。
关键文案人工审校，辅助文案可机翻。
翻译文件版本化，支持回滚。

评分维度：

工作流完整（40%）：提取、上传、翻译、审校、下载、部署
TMS 作用（30%）：资产管理、术语、审校、集成
自动化（30%）：CI 同步、机器翻译、回滚

常见错误：

手动复制 Excel 翻译，容易遗漏和版本不一致。
TMS 与代码不同步，上线后翻译缺失。

延伸追问：

如何处理紧急文案上线但翻译未完成？
机器翻译后如何评估质量？

相关题目：

FB-33-CO-A-004 翻译缺失与回退
FB-33-SD-R-002 设计翻译流水线

参考资源：

Crowdin Documentation

口头回答版：

翻译工作流是开发用 key 写代码，CI 扫描提取上传到 TMS，翻译审校后下载，再构建部署。TMS 管理术语、记忆库、审校流程和 CI 集成。要自动同步、关键文案人工审校、翻译文件版本化。

FB-33-CO-A-006：本地化的图片、文案和文化差异如何处理？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：33 国际化标签：本地化、文化差异、图片、文案、合规 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请说明国际化项目中，除了文字翻译，还需要处理哪些本地化元素。

参考答案：

本地化元素：

图片与图标：
- 避免使用只在特定文化中有意义的图标（如手势、动物、颜色）。
- 人物形象、场景要符合当地审美和法规。
- 图片中的文字要单独翻译或避免嵌入文字。
颜色与布局：
- 不同文化对颜色寓意不同（如红色在中国喜庆、在西方警示）。
- RTL 语言需要镜像布局。
文案与文化：
- 避免俚语、双关、宗教/政治敏感内容。
- 称呼、敬语、性别表达因语言而异。
法律合规：
- GDPR、个保法、COPPA、年龄 gate。
- Cookie 同意横幅、隐私政策链接。
支付方式与货币：
- 本地化支付渠道、税率、价格显示。
日期与度量：
- 公历/农历、英制/公制、温度单位。

实现方式：

把图片路径也放入翻译文件或配置中心。
使用本地化组件库，支持地区变体。
建立本地化审查清单。

评分维度：

本地化范围（50%）：图片、颜色、文案、法律、支付、度量
文化敏感性（30%）：避免敏感内容、符合习俗
实现方式（20%）：配置化、组件化、审查清单

常见错误：

只翻译文字，图片中仍含中文或特定文化元素。
忽略不同地区的法律合规要求。

延伸追问：

如何管理不同地区营销活动中的图片文案？
A/B 测试的文案是否需要本地化？

相关题目：

FB-33-CO-B-006 RTL 布局支持
FB-33-SD-R-001 设计全球化前端架构

参考资源：

W3C Localization vs Internationalization

口头回答版：

本地化不只是翻译文字，还包括图片图标、颜色、文案文化、法律合规、支付方式、日期度量。图片要配置化，避免嵌入文字；不同文化对颜色和手势理解不同；还要符合 GDPR、个保法等法规。

FB-33-CO-A-007：时区处理有哪些最佳实践？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：33 国际化标签：时区、UTC、夏令时、Intl、时间处理 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请说明国际化应用中处理日期和时区的最佳实践。

参考答案：

最佳实践：

存储 UTC：服务端数据库统一存储 UTC 时间戳，避免时区歧义。
显示转换：前端根据用户 locale 和时区转换为本地时间。
明确语义：区分“事件发生的绝对时间”和“用户本地显示时间”。
夏令时：使用 Intl.DateTimeFormat 或 moment-timezone/dayjs-timezone 处理 DST。
相对时间：使用 Intl.RelativeTimeFormat。
时区选择：
- 用户可手动选择时区，或从浏览器/账号偏好获取。
- 对预约、会议等场景，显示双方时区。
避免：
- 在数据库中存带时区字符串。
- 用客户端本地时间做业务计算。

技术实现：

推荐 dayjs + utc/timezone 插件或原生 Temporal API（未来）。
SSR 时服务端也要按用户时区渲染，可通过 cookie 传递时区。

评分维度：

存储原则（30%）：UTC 存储
显示原则（30%）：本地转换、相对时间
夏令时/语义（20%）：DST、绝对 vs 本地
工程实现（20%）：库选择、SSR

常见错误：

服务端返回已格式化的本地时间字符串，前端无法转换。
忽略夏令时导致时间差一小时。

延伸追问：

跨时区会议如何显示“我的时间”和“对方时间”？
服务端如何判断用户时区？

相关题目：

FB-33-CO-B-005 日期时间数字货币格式化
FB-33-CO-A-003 SSR 与国际化

参考资源：

Day.js Timezone

口头回答版：

时间统一存 UTC，显示时按用户时区转换。用 Intl API 或 dayjs timezone 处理夏令时。预约会议要显示双方时区。不要存带时区字符串，也不要用客户端本地时间做业务计算。

FB-33-CD-A-001：如何设计一个支持多语言的组件库？

题型：场景设计题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：33 国际化标签：组件库、国际化、locale、翻译、可配置 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请设计一个支持多语言的 UI 组件库，并说明文案、日期、数字、RTL 的处理方式。

参考答案：

设计要点：

文案内置：
- 组件库自带默认语言包（如中文、英文）。
- 提供 locale 配置，业务可注入其他语言或覆盖。
可覆盖：
- 支持运行时替换组件文案，如 locale.messages。
- 对单组件提供 props 覆盖默认文案。
日期/数字：
- 使用 Intl API，接收外部 locale 和 timeZone。
- 对 DatePicker、Calendar 等组件按 locale 切换第一周、节假日。
RTL：
- 组件内部使用逻辑属性。
- 提供 dir 配置或自动根据 locale 判断。
- 方向性组件（Slider、Carousel）需适配。
体积：
- 语言包按 locale 拆分，业务按需引入。
- 默认只打包一种语言，其余懒加载。
文档与示例：
- 提供不同 locale 和 RTL 的 Storybook 示例。

评分维度：

文案设计（30%）：内置、可覆盖、懒加载
格式处理（30%）：日期、数字、Intl
RTL 支持（20%）：逻辑属性、方向性组件
文档体积（20%）：按需加载、示例

常见错误：

组件库文案写死，业务无法覆盖。
组件库打包所有语言，体积过大。

延伸追问：

组件库与业务项目的 i18n 框架如何整合？
如何测试组件库在几十种语言下的布局？

相关题目：

FB-33-CO-A-001 i18n 框架选型
FB-33-SD-R-003 设计国际化组件库

参考资源：

Ant Design i18n

口头回答版：

组件库要内置默认语言包、允许业务注入和覆盖，用 Intl 处理日期数字，支持 dir 和 RTL，方向性组件要适配。语言包按 locale 拆分懒加载，文档提供多语言示例。

深入题（7 道）

FB-33-SD-P-001：如何设计大规模多语言前端平台？

题型：系统设计题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：33 国际化标签：多语言平台、TMS、CI/CD、治理、微前端 出现频率：高频 预计回答时长：7-10 分钟

题目描述：请设计一个支撑全公司多业务、多技术栈的大规模国际化平台，包括语言包管理、发布、治理。

参考答案：

平台目标：统一翻译资产、降低接入成本、保证质量和一致性。

核心模块：

翻译资产管理：
- 统一 TMS，集中管理所有项目 key、翻译、术语库、记忆库。
- key 命名空间与项目/业务域绑定。
代码集成：
- 提供各框架 SDK（React/Vue/小程序）和 CLI。
- 统一 key 提取、上传、下载脚本。
发布与 CDN：
- 语言包可独立发布到 CDN，应用运行时拉取。
- 支持按版本回滚和灰度。
质量与监控：
- 缺失翻译检测、占位符一致性、长度检查。
- 术语一致性扫描、机器翻译质量评估。
- 线上用户反馈入口。
治理：
- 语言包覆盖率、翻译及时率、Bug 数纳入团队考核。
- 公共文案共享，避免重复翻译。
微前端/组件库支持：
- 子应用可独立管理语言包，主应用统一 locale。
- 组件库提供 locale 配置和按需加载。

扩展性：

支持新语言快速接入（配置 + TMS 项目）。
与账号、权限、审计系统集成。

评分维度：

模块完整（40%）：资产、集成、发布、质量、治理、组件库
规模化能力（30%）：多业务、多技术栈、CDN
治理度量（30%）：覆盖率、术语、考核

常见错误：

各业务独立维护 TMS，术语不一致。
语言包随应用强耦合发布，无法热更新。

延伸追问：

如何处理业务之间文案冲突或重复？
语言包 CDN 更新后如何清理客户端缓存？

相关题目：

FB-33-CO-A-005 翻译工作流与 TMS
FB-33-SD-R-001 设计全球化前端架构

参考资源：

W3C Internationalization

口头回答版：

大规模多语言平台要统一 TMS 管理翻译资产，提供各框架 SDK 和 CLI，语言包独立发布到 CDN，做缺失检测、术语一致性、质量监控。还要纳入团队考核，支持微前端和组件库，保证术语一致和热更新。

FB-33-CO-P-001：微前端与组件库国际化如何协同？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：33 国际化标签：微前端、组件库、国际化、locale、语言包 出现频率：中频 预计回答时长：7-10 分钟

题目描述：在微前端架构中，主应用、子应用、组件库可能各自有国际化需求。请说明如何协同它们的 locale 和语言包。

参考答案：

协同策略：

统一 locale 上下文：
- 主应用决定当前 locale，通过全局状态或 props 下发给子应用和组件库。
- 子应用监听 locale 变化并切换语言包。
命名空间隔离：
- 主应用、各子应用、组件库使用独立的 i18n 命名空间。
- 避免 key 冲突，也便于独立发布语言包。
语言包加载：
- 公共语言包由主应用或组件库加载。
- 子应用进入时再懒加载自己的语言包。
组件库 locale：
- 组件库暴露 locale prop 或注入全局 locale。
- 组件库语言包可独立发布，业务按需引入。
切换同步：
- locale 切换时广播事件，所有子应用同步切换。
- 避免子应用仍显示旧语言。

边界：

子应用独立部署时，语言包版本要与组件版本匹配。
SSR 微前端需保证服务端注入的 locale 一致。

评分维度：

统一 locale（30%）：主应用决定、下发
命名空间（30%）：隔离、避免冲突
加载与切换（30%）：懒加载、同步广播
版本匹配（10%）：语言包与组件版本

常见错误：

各子应用各自决定 locale，导致界面语言不一致。
组件库文案写死，无法随业务 locale 切换。

延伸追问：

主子应用使用不同 i18n 框架怎么办？
如何测试微前端多语言切换的完整性？

相关题目：

FB-33-CD-A-001 设计多语言组件库
FB-26-SD-R-001 微前端架构设计

参考资源：

qiankun 微前端

口头回答版：

微前端里主应用定 locale 下发给子应用和组件库，各自用独立命名空间避免冲突。公共包主应用加载，子应用按需懒加载。切换时广播同步。组件库要暴露 locale。注意语言包版本和 SSR 一致。

FB-33-CO-P-002：RTL 与复杂组件（图表、日历）如何支持？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：33 国际化标签：RTL、图表、日历、复杂组件、双向文本 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请说明在 RTL 语言下，图表、日历、时间轴等复杂组件需要做哪些特殊处理。

参考答案：

通用原则：

检测 dir="rtl" 或 locale 方向，组件内部切换渲染方向。
使用 Canvas/SVG 时注意坐标系从右到左。

图表：

X 轴从右到左递增。
图例、提示框位置镜像。
堆叠顺序、饼图起始角度可能需要调整。
使用 ECharts/Highcharts 等支持 RTL 的配置。

日历：

周起始日因 locale 不同（如中东周六/周日开始，美国周日，欧洲周一）。
日期排列从右到左。
节假日、工作日按当地规则。

时间轴/步骤条：

起点在右侧，依次向左。
箭头、进度方向镜像。

表格/列表：

列顺序是否需要反转取决于内容语义（一般保持逻辑顺序，只调整对齐）。
操作按钮通常放在左侧。

实现方式：

组件库提供 direction 上下文。
对 Canvas/SVG 计算时根据方向调整坐标。
通过 Visual Regression 测试 RTL 效果。

评分维度：

RTL 原则（30%）：方向检测、坐标镜像
图表处理（30%）：轴方向、图例、起始角
日历/时间轴（20%）：周起始、排列方向
测试（20%）：视觉回归

常见错误：

只做 CSS 镜像，忽略 Canvas/SVG 内部坐标。
把所有列表列顺序都反转，破坏阅读逻辑。

延伸追问：

如何在 SVG 路径动画中支持 RTL？
地图组件支持 RTL 有哪些挑战？

相关题目：

FB-33-CO-B-006 RTL 布局支持
FB-33-CD-A-001 设计多语言组件库

参考资源：

ECharts RTL

口头回答版：

RTL 下复杂组件要检测方向并镜像。图表 X 轴从右到左、图例提示框镜像；日历注意周起始日和排列方向；时间轴起点在右。Canvas/SVG 要调整坐标。要用视觉回归测试。

FB-33-PE-P-001：语言包体积如何优化？

题型：性能优化题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：33 国际化标签：语言包体积、懒加载、压缩、tree-shaking、CDN 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请说明如何减少国际化带来的前端资源体积，并提升加载速度。

参考答案：

优化手段：

按需加载：首屏只加载当前 locale 的必需命名空间，其他懒加载。
代码分割：按 locale 拆分为独立 chunk，避免打包所有语言。
压缩：JSON 语言包 gzip/Brotli 压缩；构建时去除注释和空格。
复用公共文案：把公共文案抽到独立命名空间，避免重复。
减少 key 长度：key 语义化但不过长；构建时压缩 key（如 hash）。
使用 CDN：语言包部署到 CDN，利用缓存和就近访问。
Service Worker 缓存：语言包更新频率低，可长期缓存。
运行时合并：服务端把页面所需文案注入 HTML，减少一次请求。
剔除未使用 key：扫描代码，只打包被引用的 key。

监控：

统计各语言包大小、加载时间、缓存命中率。
设定语言包体积预算。

评分维度：

加载策略（30%）：按需、懒加载、代码分割
压缩缓存（30%）：gzip、CDN、Service Worker
体积治理（30%）：公共文案、key 长度、剔除未用
监控（10%）：体积预算、缓存命中

常见错误：

所有语言包打包到一个 bundle。
语言包不做缓存，每次页面都重新下载。

延伸追问：

如何在运行时动态精简语言包？
语言包体积预算如何落地到 CI？

相关题目：

FB-33-CO-B-007 动态加载语言包
FB-33-SD-P-001 大规模多语言平台

参考资源：

Webpack Code Splitting

口头回答版：

优化语言包体积要按需加载、按 locale 拆 chunk、压缩、CDN、Service Worker 缓存。公共文案抽离，key 不要过长，剔除未使用 key。还可以服务端注入首屏文案。监控各语言包大小和缓存命中率。

FB-33-CO-P-003：自动翻译与人工校对流程如何设计？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：33 国际化标签：机器翻译、人工校对、MTPE、翻译质量、TMS 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请设计一个结合机器翻译与人工校对的翻译流程，兼顾效率与质量。

参考答案：

流程：

机器翻译（MT）：新 key 自动调用翻译引擎（Google Translate、DeepL、Azure Translator）。
翻译后编辑（MTPE）：译者在 TMS 中基于机翻结果修改，保留记忆库。
术语与规则检查：
- 自动检查占位符、变量一致性。
- 术语库匹配，确保品牌词、专业词一致。
审校：QA 或本地专家抽检或全检。
上下文验证：在 UI 截图或 staging 环境中查看实际效果。
发布：通过 CI 自动下载并部署。
反馈闭环：线上用户可反馈翻译问题，回流到 TMS。

质量控制：

对高可见、高风险文案强制人工审校。
对辅助、低频文案可采用机翻直接发布。
使用 BLEU/COMET 等自动评分辅助判断机翻质量。
建立翻译质量 KPI（错误率、用户反馈数）。

评分维度：

流程设计（40%）：MT、MTPE、审校、上下文验证、反馈
质量控制（30%）：术语、自动评分、KPI
效率平衡（30%）：不同文案分级处理

常见错误：

所有文案直接机翻上线，导致质量和品牌受损。
人工审校流程过重，影响发布速度。

延伸追问：

如何让译者在 TMS 中理解文案上下文？
自动翻译 API 成本和延迟如何优化？

相关题目：

FB-33-CO-A-005 翻译工作流与 TMS
FB-33-SD-R-002 设计翻译流水线

参考资源：

DeepL API

口头回答版：

机器翻译加人工校对流程：新机翻、译者做 MTPE、术语和占位符检查、QA 审校、在 staging 看效果、CI 发布、线上反馈回流。高可见文案必须人工，辅助文案可机翻。用 BLEU/COMET 评估质量，建立 KPI。

FB-33-CO-P-004：设计文案与代码如何解耦？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：33 国际化标签：文案解耦、设计系统、文案管理、UI 文案 出现频率：低频 预计回答时长：7-10 分钟

题目描述：请说明如何把 UI 文案从产品逻辑中解耦，以支持快速迭代和多语言本地化。

参考答案：

解耦方式：

key 化：代码中只引用 key，不直接写文案。
统一管理：文案集中放在 TMS 或配置中心，产品/运营可直接修改。
组件化：
- 把常用文案模式封装成组件（如 EmptyState、ConfirmDialog）。
- 组件接收配置参数，文案由外部传入。
设计工具集成：
- Figma 插件与 TMS 同步，设计稿直接引用 key。
- 设计变更自动同步到代码和翻译流程。
A/B 测试支持：
- 文案作为配置，可快速替换做实验。
- 不同文案版本与翻译对应。
上下文注释：
- 每个 key 附带用途、最大长度、截图，帮助译者理解。

收益：

产品改文案无需发版（若语言包走 CDN）。
减少开发介入，提高本地化效率。

评分维度：

key 化与集中管理（40%）：代码引用 key、TMS 管理
组件化（20%）：通用组件、外部传文案
设计与 A/B（20%）：Figma 集成、文案实验
上下文（20%）：注释、截图

常见错误：

代码里大量拼接字符串，导致无法提取翻译。
文案和设计稿脱节，翻译后才发现布局问题。

延伸追问：

如何处理 UI 中需要加粗/链接的富文本文案？
文案配置化后如何做好版本控制？

相关题目：

FB-33-CO-A-005 翻译工作流与 TMS
FB-33-SD-R-002 设计翻译流水线

参考资源：

Figma Localization Plugins

口头回答版：

文案解耦要做到代码只引用 key，文案在 TMS 统一管理；通用组件外部传文案；Figma 与 TMS 同步；文案配置化支持 A/B。还要给译者上下文注释和截图。这样产品改文案可以不发版。

FB-33-CP-P-001：多语言 A/B 测试如何设计？

题型：综合开放题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：33 国际化标签：A/B 测试、文案实验、本地化、多语言 出现频率：低频 预计回答时长：7-10 分钟

题目描述：请说明在国际化场景下，如何对文案、布局、功能做 A/B 测试。

参考答案：

设计要点：

实验维度：
- 文案：同一功能不同措辞。
- 布局：不同 locale 下按钮位置、图片、颜色。
- 功能：某些地区开启/关闭特定功能。
分组策略：
- 按 userId 哈希分桶，保证同一用户稳定。
- 不同 locale 可独立实验，避免样本混杂。
配置化：
- 实验配置与文案 key 解耦，支持同一 key 多版本。
- 远程配置中心下发实验参数。
埋点：
- 上报实验组、locale、关键指标（CTR、转化率、留存）。
- 注意不同地区指标可比性。
合规：
- 用户同意、隐私政策声明。
- 某些地区对实验有法律限制。
分析：
- 分 locale 看效果，避免全局结论掩盖地区差异。
- 统计显著性、样本量计算。

评分维度：

实验维度（30%）：文案、布局、功能
分组与配置（30%）：userId 分桶、远程配置
埋点与分析（20%）：指标、locale 分层
合规（20%）：用户同意、法律

常见错误：

把不同 locale 用户混在一起看结果。
实验文案未进入翻译流程，导致多语言版本缺失。

延伸追问：

如何防止 A/B 实验影响 SEO？
多语言实验的样本量如何估算？

相关题目：

FB-33-CO-P-004 文案与代码解耦
FB-36-CD-A-001 前端埋点与 A/B 实验

参考资源：

Optimizely Localization

口头回答版：

多语言 A/B 测试要按 locale 独立分组，实验配置与文案 key 解耦，通过远程配置下发。埋点要带上实验组和 locale，分析时分地区看。注意用户同意和法律合规，不要把不同地区混在一起。

架构题（43 道）

FB-33-SD-R-001：如何设计全球化前端架构？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：33 国际化标签：全球化、国际化架构、SSR、CDN、多语言 出现频率：高频 预计回答时长：10-15 分钟

题目描述：请为一个面向全球用户的产品设计前端架构，涵盖路由、部署、性能、SEO、合规等方面。

参考答案：

架构要点：

多区域部署：
- 静态资源部署到全球 CDN，按 region 路由到最近节点。
- SSR/Edge Rendering 在靠近用户的边缘节点执行。
多语言路由：
- 子目录结构 /zh-CN/、/en-US/，子域名或独立域名作为补充。
- Edge 函数根据用户偏好重定向或改写请求。
语言包策略：
- 语言包按 locale 拆分为独立 chunk，CDN 分发。
- 关键路径文案可内联到 HTML。
SEO：
- 每个 locale 生成独立 HTML，hreflang、sitemap、OG 标签完整。
- 搜索引擎可索引每个语言版本。
合规：
- GDPR、个保法、Cookie 同意、数据本地化存储。
- 不同地区隐私政策、年龄 gate。
性能：
- 预加载用户可能切换的语言包。
- 字体子集化，只加载当前 locale 所需字符。
- 图片/视频按地区 CDN 分发。
监控：
- 分地区、分语言监控性能、错误、转化率。

治理：

统一国际化平台，TMS、组件库、设计系统协同。

评分维度：

部署与路由（30%）：CDN、Edge、子目录
性能（25%）：语言包拆分、字体子集、预加载
SEO/合规（25%）：hreflang、数据本地化
治理（20%）：统一平台、TMS

常见错误：

只翻译文字，未考虑部署和 SEO。
全球用户访问单一数据中心，延迟高。

延伸追问：

如何评估进入新国家/地区的技术成本？
数据本地化要求对前端架构有什么影响？

相关题目：

FB-33-CO-A-002 多语言路由与 SEO
FB-33-SD-P-001 大规模多语言平台

参考资源：

Google Internationalization

口头回答版：

全球化前端要全球 CDN 部署、子目录多语言路由、按 locale 拆分语言包、Edge 渲染、完整的 hreflang 和 sitemap。还要合规、数据本地化、字体子集、分地区监控。统一国际化平台和 TMS 协同。

FB-33-SD-R-002：如何设计一条翻译流水线？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：33 国际化标签：翻译流水线、CI/CD、TMS、自动化、质量门禁 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一条从代码提交到多语言上线的自动化翻译流水线。

参考答案：

流水线阶段：

代码提交：开发者新增/修改 key，附带上下文注释。
提取：CI 运行 i18next-scanner 等工具提取 key 到源文件。
差异检测：对比上一版本，识别新增/变更/废弃 key。
上传 TMS：自动上传到 Crowdin/Phrase，进入待翻译队列。
机器翻译（可选）：对低优先级 key 自动预翻译。
人工翻译/审校：译者在 TMS 工作，完成后标记完成。
质量门禁：
- 占位符一致、术语一致、长度检查。
- 缺失翻译拦截。
下载翻译：CI 从 TMS 拉取最新翻译文件。
构建与测试：
- 伪本地化构建、视觉回归、多语言功能测试。
部署：
- 语言包发布到 CDN，应用可选择独立发版或随应用发版。
监控与反馈：线上缺失/错误反馈回流 TMS。

关键设计：

分支策略：每个代码分支对应 TMS 分支，避免冲突。
回滚：语言包版本化，支持快速回滚。
灰度：新语言可先对部分地区用户灰度。

评分维度：

流水线完整（40%）：提取、上传、翻译、下载、构建、部署
质量门禁（30%）：占位符、术语、缺失、视觉回归
可回滚/灰度（30%）：版本化、分支策略

常见错误：

翻译流程与代码流程脱节，上线后才发现缺失。
没有质量门禁，错误翻译直接上线。

延伸追问：

如何处理紧急文案未翻译就需上线？
TMS 与 Git 分支如何映射？

相关题目：

FB-33-CO-A-005 翻译工作流与 TMS
FB-33-SD-P-001 大规模多语言平台

参考资源：

Phrase GitHub Sync

口头回答版：

翻译流水线从代码提取 key，上传到 TMS，差异检测，人工或机翻，审校后质量门禁检查占位符、术语、缺失。然后下载、构建、伪本地化测试、部署到 CDN，线上反馈回流。要分支映射、版本化、支持灰度回滚。

FB-33-SD-R-003：如何设计国际化组件库？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：33 国际化标签：国际化组件库、locale、RTL、设计系统 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一个面向多业务、多框架的国际化组件库，说明文案、格式、RTL、版本管理。

参考答案：

设计要点：

多框架支持：
- 核心逻辑与框架无关（纯 JS + Intl）。
- 提供 React/Vue/Angular 封装层。
文案管理：
- 组件库自带默认语言包，业务可注入或覆盖。
- key 命名空间隔离，如 @company/components/button。
格式化抽象：
- 封装 useLocale / LocaleProvider，统一处理日期、数字、相对时间。
- 接收外部 locale 和 timeZone。
RTL 支持：
- 内部使用逻辑属性。
- 方向性组件（Slider、Steps、Pagination）根据 dir 切换。
主题与本地化：
- 颜色、间距保持中性，避免文化特定默认。
- 允许地区主题覆盖。
版本管理：
- 语言包随组件版本发布，保持兼容。
- 提供迁移指南和废弃 key 处理。
文档与测试：
- Storybook 展示各 locale 和 RTL 效果。
- 视觉回归覆盖多语言。

评分维度：

框架无关（20%）：核心逻辑抽象
文案与格式（30%）：注入、覆盖、Intl
RTL（20%）：逻辑属性、方向组件
版本与文档（30%）：版本兼容、Storybook、视觉回归

常见错误：

组件库只支持一种框架，其他业务无法复用。
文案写死，业务无法覆盖。

延伸追问：

组件库语言包如何与业务项目合并？
如何保持组件库文案更新不影响业务？

相关题目：

FB-33-CD-A-001 设计多语言组件库
FB-33-CO-P-001 微前端与组件库国际化协同

参考资源：

Ant Design Internationalization

口头回答版：

国际化组件库要核心逻辑与框架无关，提供 React/Vue 封装；自带默认语言包允许覆盖；统一 locale 和 timeZone；内部用逻辑属性支持 RTL；方向性组件适配。语言包随版本发布，文档用 Storybook 展示多语言效果。

FB-33-SD-R-004：多语言内容管理系统（CMS）如何设计？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：33 国际化标签：CMS、多语言内容、本地化、内容管理 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一个支持多语言运营内容（文章、活动页、商品信息）的 CMS 前端方案。

参考答案：

CMS 设计要点：

内容模型：
- 每个内容实体有主语言版本和多个翻译版本。
- 字段级翻译 vs 整体翻译：对结构化内容按字段翻译；对富文本整体翻译。
翻译工作流：
- 编辑创建主语言内容后发起翻译任务。
- TMS/人工翻译完成后审校、发布。
内容版本：
- 支持草稿、审校中、已发布、归档状态。
- 不同语言版本可独立发布。
预览与对比：
- 编辑可预览各语言效果。
- 对比主语言与翻译差异。
前端渲染：
- 根据 URL locale 从 CMS API 拉取对应内容。
- 支持 ISR/SSG，预渲染多语言页面。
SEO：
- 多语言页面互链，hreflang 完整。
- slug 本地化（如 /zh-CN/产品、/en-US/product）。
合规：
- 不同地区内容审核、下架、年龄限制。

扩展：

内容个性化：按地区推荐不同内容。
A/B 测试：不同文案/图片实验。

评分维度：

内容模型（30%）：字段/整体翻译、版本状态
工作流（20%）：翻译任务、审校、发布
前端渲染（20%）：API、SSG/ISR
SEO/合规（30%）：hreflang、slug、审核

常见错误：

所有语言内容强耦合发布，无法独立上线。
slug 不本地化，影响 SEO 和用户体验。

延伸追问：

富文本内容中的图片/链接如何本地化？
如何实现内容的多地区审核流程？

相关题目：

FB-33-CO-A-002 多语言路由与 SEO
FB-33-SD-R-001 设计全球化前端架构

参考资源：

Contentful Localization

口头回答版：

多语言 CMS 内容实体有主语言和多个翻译版本，可按字段翻译。工作流是编辑创建后发起翻译、审校、发布，各语言独立发布。前端按 URL locale 拉内容，支持 SSG，SEO 要做 hreflang 和本地化 slug。还要考虑地区审核。

FB-33-CP-R-001：国际化度量与监控应该关注哪些指标？

题型：综合开放题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：33 国际化标签：国际化度量、监控、覆盖率、质量、性能 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一套国际化度量体系，用于持续评估多语言产品的质量、效率和用户体验。

参考答案：

度量指标：

覆盖度：
- 各语言翻译覆盖率。
- 页面/功能多语言适配覆盖率。
质量：
- 缺失翻译数量、占位符错误数。
- 术语不一致数。
- 用户反馈的翻译错误数。
- 视觉回归发现的布局问题数。
效率：
- 新文案从提交到上线平均时长。
- 译者人效（字数/天）。
- 机翻占比与人工审校占比。
体验：
- 分 locale 的首屏加载时间。
- 语言包加载失败率。
- 用户手动切换语言比例。
- 各地区转化率/留存差异。
合规：
- 隐私政策/用户同意覆盖率。
- 数据本地化符合率。

监控手段：

Dashboard 展示各语言健康度。
CI 门禁阻断未翻译、占位符错误。
线上监控语言包加载失败和缺失 key。
定期用户调研和本地化走查。

评分维度：

指标全面（40%）：覆盖、质量、效率、体验、合规
监控手段（30%）：Dashboard、CI、线上监控
持续改进（30%）：KPI、复盘、反馈闭环

常见错误：

只看翻译覆盖率，忽略质量和用户体验。
没有分 locale 的性能监控。

延伸追问：

如何量化国际化对业务增长的贡献？
各地区转化率差异大时如何判断是本地化问题还是产品问题？

相关题目：

FB-33-CO-A-005 翻译工作流与 TMS
FB-33-SD-R-001 设计全球化前端架构

参考资源：

W3C Internationalization

口头回答版：

国际化度量要看覆盖度、翻译质量、上线效率、用户体验和合规。监控包括 CI 门禁、Dashboard、线上语言包加载和缺失 key、用户反馈。要分 locale 看性能和转化，持续复盘改进。

FB-33-CP-R-002：跨团队国际化治理如何推进？

题型：综合开放题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：33 国际化标签：国际化治理、跨团队、规范、TMS、组件库 出现频率：中频 预计回答时长：10-15 分钟

题目描述：作为国际化负责人，你如何推动前端、产品、设计、运营等多个团队协同做好国际化？

参考答案：

治理框架：

统一规范：
- 制定国际化开发规范、key 命名规范、文案提交规范。
- 提供 ADR 模板记录重大决策。
统一平台：
- 统一 TMS、组件库、设计系统、翻译流水线。
- 避免各业务重复建设。
角色分工：
- 前端：技术框架、语言包加载、RTL 适配。
- 产品：定义多语言策略、优先级、合规要求。
- 设计：输出多语言/RTL 设计稿。
- 运营/本地化：翻译、审校、内容发布。
流程嵌入：
- 需求评审加入国际化 Checklist。
- 设计稿必须包含英文/RTL 版本。
- 代码评审检查硬编码文案和 RTL 问题。
培训与赋能：
- 定期培训国际化最佳实践。
- 建立 FAQ 和案例库。
度量与激励：
- 将覆盖率、质量、上线时效纳入团队 OKR。
- 对优秀实践进行表彰和推广。

推动策略：

先找痛点（如反复出现的翻译 Bug）建立信任。
从核心项目试点，再推广到全公司。
用数据说明国际化对业务的价值。

评分维度：

治理框架（40%）：规范、平台、角色、流程
跨团队协作（30%）：前端/产品/设计/运营分工
推动策略（30%）：试点、痛点、数据

常见错误：

只靠前端团队推动，产品和设计不参与。
规范过于繁琐，业务团队抵触。

延伸追问：

如何处理业务团队为赶进度跳过国际化？
如何建立国际化的“质量门禁”？

相关题目：

FB-33-SD-R-001 设计全球化前端架构
FB-33-CP-R-001 国际化度量与监控

参考资源：

W3C Internationalization

口头回答版：

跨团队国际化治理要统一规范、统一平台、明确分工：前端负责技术框架，产品定策略，设计出多语言稿，运营翻译审校。流程里需求评审、设计稿、代码评审都加国际化 Checklist。先试点核心项目，用数据证明价值，再推广。

FB-33-CP-R-003：合规与本地化法律要求如何影响前端架构？

题型：综合开放题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：33 国际化标签：合规、GDPR、个人信息保护法、数据本地化、Cookie 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请说明 GDPR、个人信息保护法、数据本地化等法律要求如何影响前端架构设计。

参考答案：

影响点：

数据采集：
- 采集前需明确告知并获得同意（Cookie 横幅、隐私政策）。
- 默认最小化，禁止默认开启非必要埋点和广告。
数据存储：
- 敏感数据本地化存储，某些国家要求数据不出境。
- 前端不持久化敏感个人信息。
Cookie 与追踪：
- 按类别（必要、分析、营销）管理 Cookie 同意。
- 未同意前不加载分析/广告脚本。
用户权利：
- 提供导出、删除、更正个人数据入口。
- 未成年人需额外保护（年龄 gate、监护人同意）。
内容合规：
- 不同地区的内容审核、下架、版权、语言政策。
架构调整：
- 部署到符合数据本地化要求的区域。
- 配置中心按地区下发合规策略（是否显示 Cookie 横幅、是否启用某些功能）。
- 埋点 SDK 支持同意状态开关。

前端实践：

Consent Management Platform（CMP）。
地区化配置中心。
隐私协议和同意记录持久化。

评分维度：

法律理解（30%）：GDPR、个保法、数据本地化
架构影响（40%）：采集、存储、Cookie、用户权利、部署
前端实践（30%）：CMP、配置中心、同意状态

常见错误：

认为合规只是法务工作，技术层不调整。
全球统一一套隐私策略和 Cookie 横幅。

延伸追问：

如何在不破坏业务埋点的情况下实现同意管理？
数据本地化要求对 CDN 和 API 部署有什么影响？

相关题目：

FB-31-CO-P-003 隐私合规技术要求
FB-33-SD-R-001 设计全球化前端架构

参考资源：

GDPR Official Text

口头回答版：

合规影响前端采集前告知同意、数据本地化、Cookie 分类管理、用户导出删除权利、内容审核等。架构上要用 Consent 管理平台、地区配置中心、按区域部署。埋点 SDK 按同意状态开关，不要全球统一一套策略。

FB-33-CP-B-001：什么是 i18n 和 l10n？有什么区别？

题型：综合开放题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：33 国际化标签：locale、TMS、国际化、本地化、Intl 出现频率：中频 预计回答时长：3-5 分钟

题目描述：什么是 i18n 和 l10n？有什么区别。

参考答案：

i18n（Internationalization）是国际化，使产品具备支持多语言和地区的能力。l10n（Localization）是本地化，针对特定地区进行适配，如翻译、RTL、货币、日期格式。

区别：i18n 是能力，l10n 是具体适配。

补充说明：

在实际落地 i18n 和 l10n有什么区别时，建议结合 locale、TMS、国际化的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

定义准确（50%）
区别说明（30%）
举例说明（20%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

i18n（Internationalization）是国际化，使产品具备支持多语言和地区的能力。 l10n（Localization）是本地化，针对特定地区进行适配，如翻译、RTL、货币、日期格式。区别：i18n 是能力，l10n 是具体适配。

FB-33-CO-B-009：前端 i18n 有哪些核心问题需要解决？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：33 国际化标签：locale、TMS、国际化、本地化、Intl 出现频率：中频 预计回答时长：3-5 分钟

题目描述：前端 i18n 有哪些核心问题需要解决。

参考答案：

文本翻译：key 管理、插值、复数。
格式化：日期、数字、货币、度量单位。
RTL 适配：布局镜像、图标、动画。
内容管理：翻译平台集成、版本控制。
地区路由：URL/域名切换语言。

补充说明：

在实际落地前端 i18n 有哪些核心问题需要解决时，建议结合 locale、TMS、国际化的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

文本翻译（25%）
格式化（25%）
RTL（25%）
内容管理（15%）
路由（10%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

文本翻译：key 管理、插值、复数。 - 格式化：日期、数字、货币、度量单位。 - RTL 适配：布局镜像、图标、动画。 - 内容管理：翻译平台集成、版本控制。

FB-33-CO-B-010：如何处理 RTL 布局？

题目描述：如何处理 RTL 布局。

参考答案：

使用 CSS 逻辑属性（margin-inline-start、text-align: start）。
设置 html dir="rtl"。
布局使用 flex/grid 时自动适配。
方向性图标需要镜像。
测试真实 RTL 语言。

补充说明：

在实际落地处理 RTL 布局时，建议结合 locale、TMS、国际化的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

逻辑属性（40%）
dir 属性（20%）
图标与动画（25%）
测试（15%）

二、进阶题

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

使用 CSS 逻辑属性（margin-inline-start、text-align: start）。 - 设置 html dir="rtl"。 - 布局使用 flex/grid 时自动适配。 - 方向性图标需要镜像。

FB-33-CO-A-008：ICU MessageFormat 有什么作用？

题型：概念题难度：🟡 进阶 岗位层级：高级 / 资深 面试知识域：33 国际化标签：locale、TMS、国际化、本地化、Intl 出现频率：中频 预计回答时长：5-8 分钟

题目描述： ICU MessageFormat 有什么作用。

参考答案：

ICU MessageFormat 用于处理复杂翻译场景，如插值、复数、选择、日期数字格式化。

示例：

{count, plural, =0 {无消息} one {1 条消息} other {# 条消息&#125;&#125;

补充说明：

在实际落地 ICU MessageFormat 有什么作用时，建议结合 locale、TMS、国际化的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

作用说明（40%）
复数示例（30%）
其他场景（30%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

ICU MessageFormat 用于处理复杂翻译场景，如插值、复数、选择、日期数字格式化。示例：（代码示例）

FB-33-SD-A-001：如何设计一个可扩展的翻译工作流？

题型：系统设计题难度：🟡 进阶 岗位层级：高级 / 资深 面试知识域：33 国际化标签：locale、TMS、国际化、本地化、Intl 出现频率：中频 预计回答时长：5-8 分钟

题目描述：如何设计一个可扩展的翻译工作流。

参考答案：

开发者使用 key，不手写翻译。
提取工具自动抽取 key 到翻译文件。
上传翻译平台（Crowdin/Lokalise）。
翻译人员翻译，审核人员审核。
CI 自动下载翻译并构建。
缺失翻译回退到默认语言。

补充说明：

在实际落地设计一个可扩展的翻译工作流时，建议结合 locale、TMS、国际化的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 补充说明：

在实际落地设计一个可扩展的翻译工作流时，建议结合 locale、TMS、国际化的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

角色分工（30%）
工具集成（30%）
CI/CD（25%）
兜底机制（15%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

开发者使用 key，不手写翻译。 - 提取工具自动抽取 key 到翻译文件。 - 上传翻译平台（Crowdin/Lokalise）。 - 翻译人员翻译，审核人员审核。

FB-33-EN-A-001：全球化部署需要考虑哪些合规问题？

题型：工程化题难度：🟡 进阶 岗位层级：高级 / 资深 面试知识域：33 国际化标签：locale、TMS、国际化、本地化、Intl 出现频率：中频 预计回答时长：5-8 分钟

题目描述：全球化部署需要考虑哪些合规问题。

参考答案：

数据本地化（中国个保法、GDPR）。
用户同意（Cookie、隐私政策）。
数据跨境传输。
内容合规（不同地区法律）。
未成年人保护。

补充说明：

在实际落地全球化部署需要考虑哪些合规问题时，建议结合 locale、TMS、国际化的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 补充说明：

在实际落地全球化部署需要考虑哪些合规问题时，建议结合 locale、TMS、国际化的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

数据本地化（30%）
用户同意（25%）
跨境传输（20%）
内容合规（15%）
其他（10%）

三、高级题

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

数据本地化（中国个保法、GDPR）。 - 用户同意（Cookie、隐私政策）。 - 内容合规（不同地区法律）。

FB-33-CO-B-011：前端国际化的核心问题有哪些

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：33 国际化标签：国际化、i18n、翻译、语言、本地化 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明前端国际化需要解决的主要问题。

参考答案：

核心思路如下：

文本翻译：提取、管理、加载多语言资源
复数、日期、数字、货币格式化
布局方向：RTL 语言支持
语言切换与状态保持
SEO 与路由
文化差异与本地化

需要避免的典型误区：

硬编码中文
只翻译文本忽略格式
忽略 RTL

补充说明：

在实际落地前端国际化的核心问题有哪些时，建议结合国际化、i18n、翻译的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：文本翻译、复数、日期、数字、货币格式化等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

硬编码中文
只翻译文本忽略格式
忽略 RTL

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

文本翻译；复数、日期、数字、货币格式化；布局方向；语言切换与状态保持；SEO 与路由；文化差异与本地化。同时要避免硬编码中文。

FB-33-CO-A-009：i18n 与 l10n 的区别

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：i18n、l10n、国际化、本地化、翻译 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释国际化与本地化的区别。

参考答案：

核心思路如下：

i18n：设计应用使其可适应不同语言和地区
l10n：针对具体地区进行翻译和文化适配
i18n 是能力，l10n 是内容
示例：i18n 框架支持，l10n 提供具体文案

需要避免的典型误区：

混用两个概念
只做翻译不做架构适配
忽略本地化文化

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：i18n、l10n 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

混用两个概念
只做翻译不做架构适配
忽略本地化文化

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

i18n；l10n；i18n 是能力，l10n 是内容；示例。同时要避免混用两个概念。

FB-33-SC-A-001：如何设计前端多语言资源管理

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：多语言、资源、JSON、命名空间、懒加载 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请设计前端多语言资源的组织、加载和维护方案。

参考答案：

核心思路如下：

按页面/模块拆分 namespace，避免全量加载
资源文件格式：JSON/YAML，键值结构
按需加载：切换语言或进入路由时加载对应资源
回退机制：找不到时回退默认语言
插值与组件：支持变量、HTML、组件替换
翻译管理平台：Crowdin、Lokalise

需要避免的典型误区：

所有语言一个文件
键名无规范导致冲突
不区分语言包版本

补充说明：

在实际落地设计前端多语言资源管理时，建议结合多语言、资源、JSON 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：按页面/模块拆分 namespace，避免全量加载、资源文件格式等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有语言一个文件
键名无规范导致冲突
不区分语言包版本

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

按页面/模块拆分 namespace，避免全量加载；资源文件格式；按需加载；回退机制；插值与组件；翻译管理平台。同时要避免所有语言一个文件。

FB-33-CO-A-010：React/Vue 中常见的 i18n 方案

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：React Intl、vue-i18n、FormatJS、i18next 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请比较主流前端 i18n 库及其特点。

参考答案：

核心思路如下：

i18next：跨框架、生态丰富、插件多
react-intl/FormatJS：React 官方推荐，ICU 消息格式
vue-i18n：Vue 生态，语法简洁
选型：团队栈、ICU 支持、SSR 需求
统一消息格式便于翻译平台对接

需要避免的典型误区：

每个项目用不同库
消息格式不统一
忽略 SSR

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：i18next、react-intl/FormatJS 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

每个项目用不同库
消息格式不统一
忽略 SSR

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

i18next；react-intl/FormatJS；vue-i18n；选型；统一消息格式便于翻译平台对接。同时要避免每个项目用不同库。

FB-33-PE-A-001：国际化对前端性能的影响及优化

题型：性能优化题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：i18n、性能、资源体积、懒加载、打包 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明多语言资源对性能的影响及优化手段。

参考答案：

核心思路如下：

按需加载语言包，避免打包所有语言
拆分 namespace，路由级加载
预加载默认语言，其他语言异步加载
服务端渲染时注入初始语言数据
压缩资源，使用 CDN

需要避免的典型误区：

打包 50 种语言
切换语言全量刷新
不做资源缓存

补充说明：

在实际落地国际化对前端性能的影响及优化时，建议结合 i18n、性能、资源体积的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：按需加载语言包，避免打包所有语言、拆分 namespace，路由级加载等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

打包 50 种语言
切换语言全量刷新
不做资源缓存

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

按需加载语言包，避免打包所有语言；拆分 namespace，路由级加载；预加载默认语言，其他语言异步加载；服务端渲染时注入初始语言数据；压缩资源，使用 CDN。同时要避免打包 50 种语言。

FB-33-SC-P-001：如何处理 ICU 复数与插值

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：33 国际化标签：ICU、复数、插值、国际化、格式化 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明 ICU 消息格式中的复数、选择、插值用法。

参考答案：

核心思路如下：

插值：{name} 替换变量
复数：{count, plural, one {# item} other {# items}}
选择：{gender, select, male {he} female {she}}
数字日期：{num, number}、
让翻译人员掌握 ICU 语法

需要避免的典型误区：

用代码拼接复数
不同语言复数规则不同硬编码
插值不转义导致 XSS

补充说明：

在实际落地处理 ICU 复数与插值时，建议结合 ICU、复数、插值的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：插值、复数等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

用代码拼接复数
不同语言复数规则不同硬编码
插值不转义导致 XSS

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

插值；复数；选择；数字日期；让翻译人员掌握 ICU 语法。同时要避免用代码拼接复数。

FB-33-CO-P-005：RTL 语言布局如何支持

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：33 国际化标签：RTL、国际化、布局、CSS、方向 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明支持阿拉伯语、希伯来语等 RTL 语言的方案。

参考答案：

核心思路如下：

HTML dir 属性设置为 rtl
CSS 逻辑属性：margin-inline-start 替代 margin-left
使用 CSS-in-JS 或 PostCSS 插件自动翻转
图标和动画方向适配
测试：镜像布局、文字对齐

需要避免的典型误区：

写死 left/right
只做文本翻译不改布局
忽略数字和标点方向

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：HTML dir 属性设置为 rtl、CSS 逻辑属性等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

写死 left/right
只做文本翻译不改布局
忽略数字和标点方向

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

HTML dir 属性设置为 rtl；CSS 逻辑属性；使用 CSS-in-JS 或 PostCSS 插件自动翻转；图标和动画方向适配；测试。同时要避免写死 left/right。

FB-33-SC-A-002：国际化与路由/SEO 的结合

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：i18n、路由、SEO、hreflang、SSR 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计支持多语言的 URL 和 SEO 方案。

参考答案：

核心思路如下：

URL 方案：子目录 /zh/ /en/ 或子域名
HTML lang 属性与 hreflang 标签
SSR 输出对应语言 HTML
默认语言重定向或 canonical
搜索引擎可索引各语言版本

需要避免的典型误区：

用 hash 或 cookie 切换语言无独立 URL
缺少 hreflang
SSR 语言数据不一致

补充说明：

在实际落地国际化与路由/SEO 的结合时，建议结合 i18n、路由、SEO 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：URL 方案、HTML lang 属性与 hreflang 标签等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

用 hash 或 cookie 切换语言无独立 URL
缺少 hreflang
SSR 语言数据不一致

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

URL 方案；HTML lang 属性与 hreflang 标签；SSR 输出对应语言 HTML；默认语言重定向或 canonical；搜索引擎可索引各语言版本。同时要避免用 hash 或 cookie 切换语言无独立 URL。

FB-33-CO-A-011：时区与日期时间处理

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：时区、日期、国际化、moment、dayjs 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明前端如何处理多时区、夏令时和日期格式化。

参考答案：

核心思路如下：

存储 UTC 时间，显示按用户时区
使用 Temporal 或 date-fns/dayjs 等现代库
避免手写时区转换
让用户选择时区或按浏览器时区
注意跨天时间边界

需要避免的典型误区：

用本地时间存储
手写时区逻辑
忽略夏令时

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：存储 UTC 时间，显示按用户时区、使用 Temporal 或 date-fns/dayjs 等现代库等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

用本地时间存储
手写时区逻辑
忽略夏令时

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

存储 UTC 时间，显示按用户时区；使用 Temporal 或 date-fns/dayjs 等现代库；避免手写时区转换；让用户选择时区或按浏览器时区；注意跨天时间边界。同时要避免用本地时间存储。

FB-33-SC-P-002：如何设计组件库的多语言支持

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：33 国际化标签：组件库、多语言、i18n、插槽、配置 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计一个支持多语言的通用组件库。

参考答案：

核心思路如下：

组件内部文案通过 i18n 配置注入
提供 locale 属性或全局 ConfigProvider
允许通过 slot/children 覆盖默认文案
默认语言包可替换
避免组件库与业务翻译冲突

需要避免的典型误区：

组件库硬编码中文
文案与组件强耦合
不支持覆盖默认文案

补充说明：

在实际落地设计组件库的多语言支持时，建议结合组件库、多语言、i18n 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：组件内部文案通过 i18n 配置注入、提供 locale 属性或全局 ConfigProvider 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

组件库硬编码中文
文案与组件强耦合
不支持覆盖默认文案

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

组件内部文案通过 i18n 配置注入；提供 locale 属性或全局 ConfigProvider；允许通过 slot/children 覆盖默认文案；默认语言包可替换；避免组件库与业务翻译冲突。同时要避免组件库硬编码中文。

FB-33-CO-P-006：翻译管理系统如何与前端集成

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：33 国际化标签：TMS、翻译、CI/CD、API、Crowdin 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明翻译管理平台与前端工程化的集成。

参考答案：

核心思路如下：

开发提交源语言 key-value
翻译人员在 TMS 翻译
CI 拉取最新翻译生成语言包
翻译进度与缺失检查
回退到源语言或默认语言

需要避免的典型误区：

手动复制翻译文件
翻译完成前无法发布
不同环境翻译不一致

补充说明：

在实际落地翻译管理系统如何与前端集成时，建议结合 TMS、翻译、CI/CD 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：开发提交源语言 key-value、翻译人员在 TMS 翻译等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

手动复制翻译文件
翻译完成前无法发布
不同环境翻译不一致

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

开发提交源语言 key-value；翻译人员在 TMS 翻译；CI 拉取最新翻译生成语言包；翻译进度与缺失检查；回退到源语言或默认语言。同时要避免手动复制翻译文件。

FB-33-SC-A-003：前端如何做语言切换体验

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：语言切换、i18n、状态、路由、刷新 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请设计流畅的语言切换体验。

参考答案：

核心思路如下：

切换时保存偏好到 localStorage/用户配置
异步加载新语言包并替换
必要时刷新页面或路由切换
图片、日期、数字同步更新
避免闪烁：先加载资源再切换

需要避免的典型误区：

切换后部分文案未更新
语言偏好未持久化
切换时白屏

补充说明：

在实际落地前端如何做语言切换体验时，建议结合语言切换、i18n、状态的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：切换时保存偏好到 localStorage/用户配置、异步加载新语言包并替换等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

切换后部分文案未更新
语言偏好未持久化
切换时白屏

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

切换时保存偏好到 localStorage/用户配置；异步加载新语言包并替换；必要时刷新页面或路由切换；图片、日期、数字同步更新；避免闪烁。同时要避免切换后部分文案未更新。

FB-33-CO-B-012：什么是伪本地化（Pseudolocalization）

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：33 国际化标签：伪本地化、i18n、测试、占位符 出现频率：低频 预计回答时长：3-5 分钟

题目描述：请解释伪本地化及其在国际化测试中的作用。

参考答案：

核心思路如下：

伪本地化：用模拟字符替换原文，测试布局扩展
帮助发现硬编码文本、布局截断、缺少翻译
常用：添加前缀、拉长文本、变音符号
可在开发/测试环境自动启用
不替代真实翻译测试

需要避免的典型误区：

未做伪本地化直接上线
认为伪本地化就是翻译
只在生产环境发现布局问题

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：伪本地化、帮助发现硬编码文本、布局截断、缺少翻译等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

未做伪本地化直接上线
认为伪本地化就是翻译
只在生产环境发现布局问题

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

伪本地化；帮助发现硬编码文本、布局截断、缺少翻译；常用；可在开发/测试环境自动启用；不替代真实翻译测试。同时要避免未做伪本地化直接上线。

FB-33-SC-P-003：国际化项目的测试策略

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：33 国际化标签：i18n、测试、RTL、截图、翻译 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明如何测试国际化前端应用。

参考答案：

核心思路如下：

功能测试：切换语言后所有文案正确
布局测试：长文本、RTL 不破坏布局
格式测试：日期、数字、货币、复数
截图测试：不同语言关键页面
缺失翻译检测：CI 扫描未翻译 key

需要避免的典型误区：

只测默认语言
忽略 RTL 测试
不测格式规则

补充说明：

在实际落地国际化项目的测试策略时，建议结合 i18n、测试、RTL 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：功能测试、布局测试等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只测默认语言
忽略 RTL 测试
不测格式规则

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

功能测试；布局测试；格式测试；截图测试；缺失翻译检测。同时要避免只测默认语言。

FB-33-PE-A-002：多语言包的体积优化

题型：性能优化题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：i18n、体积、按需加载、压缩、拆分 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明如何减小小语言包体积。

参考答案：

核心思路如下：

只打包默认语言，其他按需加载
按路由/页面拆分 namespace
移除未使用的 key
压缩 JSON 或转 JS 模块
服务端提供语言包 CDN

需要避免的典型误区：

全量语言包打包
语言包包含大量未用文案
不压缩传输

补充说明：

在实际落地多语言包的体积优化时，建议结合 i18n、体积、按需加载的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：只打包默认语言，其他按需加载、按路由/页面拆分 namespace 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

全量语言包打包
语言包包含大量未用文案
不压缩传输

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

只打包默认语言，其他按需加载；按路由/页面拆分 namespace；移除未使用的 key；压缩 JSON 或转 JS 模块；服务端提供语言包 CDN。同时要避免全量语言包打包。

FB-33-CO-P-007：货币与数字格式化

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：33 国际化标签：货币、数字、i18n、Intl、格式化 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明前端如何正确格式化货币和数字。

参考答案：

核心思路如下：

使用 Intl.NumberFormat
区分货币符号、小数位、千分位
注意不同地区小数点和千分位符号
货币单位与汇率由服务端提供
不要用字符串拼接货币

需要避免的典型误区：

硬编码 ¥/$
忽略小数位差异
用 toFixed 做货币格式化

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：使用 Intl.NumberFormat、区分货币符号、小数位、千分位等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

硬编码 ¥/$
忽略小数位差异
用 toFixed 做货币格式化

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

使用 Intl.NumberFormat；区分货币符号、小数位、千分位；注意不同地区小数点和千分位符号；货币单位与汇率由服务端提供；不要用字符串拼接货币。同时要避免硬编码 ¥/$。

FB-33-SC-A-004：如何处理翻译中的占位符和 HTML

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：i18n、占位符、HTML、XSS、转义 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明翻译文案中包含变量或 HTML 的安全渲染方案。

参考答案：

核心思路如下：

变量插值默认转义
需要 HTML 时使用库提供的富文本组件
限制允许的标签和属性
避免用户输入直接放入翻译
对富文本做 DOMPurify 过滤

需要避免的典型误区：

直接 v-html 翻译结果
不过滤用户输入
翻译人员插入脚本

补充说明：

在实际落地处理翻译中的占位符和 HTML 时，建议结合 i18n、占位符、HTML 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：变量插值默认转义、需要 HTML 时使用库提供的富文本组件等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

直接 v-html 翻译结果
不过滤用户输入
翻译人员插入脚本

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

变量插值默认转义；需要 HTML 时使用库提供的富文本组件；限制允许的标签和属性；避免用户输入直接放入翻译；对富文本做 DOMPurify 过滤。同时要避免直接 v-html 翻译结果。

FB-33-CO-A-012：国际化中的语言回退策略

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：回退、语言、方言、默认语言、i18n 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明多语言 fallback 策略。

参考答案：

核心思路如下：

用户选择 > 浏览器语言 > 默认语言
方言回退到基础语言：zh-CN -> zh -> en
回退链可配置
找不到翻译时显示 key 或默认语言
避免空字符串

需要避免的典型误区：

直接回退英文忽略地区
回退链无限循环
缺失翻译显示空

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：用户选择 > 浏览器语言 > 默认语言、方言回退到基础语言等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

直接回退英文忽略地区
回退链无限循环
缺失翻译显示空

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

用户选择 > 浏览器语言 > 默认语言；方言回退到基础语言；回退链可配置；找不到翻译时显示 key 或默认语言；避免空字符串。同时要避免直接回退英文忽略地区。

FB-33-SD-R-005：设计一个可扩展的国际化架构

题型：系统设计题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：33 国际化标签：i18n、架构、插件、多语言、SSR、组件库 出现频率：低频 预计回答时长：8-15 分钟

题目描述：请为公司级前端产品设计国际化架构。

参考答案：

核心思路如下：

统一技术选型：在公司级范围选择一套 i18n 库与消息格式（如 ICU MessageFormat），并封装成内部 SDK，统一 API 与配置。
语言资源分层治理：基础通用文案、业务模块文案、组件库文案分别维护；通过命名空间按需加载，避免打包全部语言包。
构建与运行时按需加载：按路由/模块拆分语言包，支持 SSR 时服务端注入初始语言、客户端懒加载其余语言；关键路径文案预加载。
集成翻译管理系统（TMS）：提供 Key 提取、翻译进度、审校工作流、缺失检测的自动化流水线；翻译变更触发 CI 自动发布。
RTL 与本地化：从设计系统开始支持 RTL 布局、双向文本、日期/数字/货币格式化；通过视觉回归测试捕获布局问题。
质量与治理：建立 Key 命名规范、禁用硬编码文案、添加 i18n ESLint 规则；设置翻译覆盖率与缺失 Key 告警。

需要避免的典型误区：

各项目各自为政
组件库与业务翻译不统一
上线前才发现 RTL 问题

补充说明：

在实际落地设计一个可扩展的国际化架构时，建议结合 i18n、架构、插件的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：统一 i18n 库和消息格式、语言资源分层等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

各项目各自为政
组件库与业务翻译不统一
上线前才发现 RTL 问题

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

统一 i18n 库和消息格式；语言资源分层；按需加载与 SSR 注入；翻译管理系统集成；RTL 与本地化适配；自动化测试与缺失检测。同时要避免各项目各自为政。

FB-33-CO-B-013：Intl API 在前端的使用

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：33 国际化标签：Intl、DateTimeFormat、RelativeTime、ListFormat 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明 Intl API 能解决哪些国际化问题。

参考答案：

核心思路如下：

Intl.DateTimeFormat 格式化日期时间
Intl.NumberFormat 格式化数字、货币、百分比
Intl.RelativeTimeFormat 相对时间
Intl.ListFormat 列表连接
Intl.Collator 字符串排序
现代浏览器支持，需 polyfill

需要避免的典型误区：

手写日期格式化
忽略浏览器兼容性
不考虑用户 locale

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：Intl.DateTimeFormat 格式化日期时间、Intl.NumberFormat 格式化数字、货币、百分比等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

手写日期格式化
忽略浏览器兼容性
不考虑用户 locale

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

Intl.DateTimeFormat 格式化日期时间；Intl.NumberFormat 格式化数字、货币、百分比；Intl.RelativeTimeFormat 相对时间；Intl.ListFormat 列表连接；Intl.Collator 字符串排序；现代浏览器支持，需 polyfill。同时要避免手写日期格式化。

FB-33-SC-P-004：如何处理多语言下的 SEO 与预渲染

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：33 国际化标签：i18n、SEO、SSR、预渲染、hreflang 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明多语言站点的 SEO 最佳实践。

参考答案：

核心思路如下：

每种语言有独立 URL
HTML lang 和 hreflang 标签
SSR/SSG 输出各语言版本
sitemap 包含各语言链接
避免自动重定向导致爬虫无法索引

需要避免的典型误区：

用 JS 切换语言无独立 URL
hreflang 与 URL 不一致
重定向所有爬虫到默认语言

补充说明：

在实际落地处理多语言下的 SEO 与预渲染时，建议结合 i18n、SEO、SSR 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：每种语言有独立 URL、HTML lang 和 hreflang 标签等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

用 JS 切换语言无独立 URL
hreflang 与 URL 不一致
重定向所有爬虫到默认语言

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

每种语言有独立 URL；HTML lang 和 hreflang 标签；SSR/SSG 输出各语言版本；sitemap 包含各语言链接；避免自动重定向导致爬虫无法索引。同时要避免用 JS 切换语言无独立 URL。

FB-33-PE-A-003：国际化对首屏性能的影响

题型：性能优化题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：i18n、首屏、SSR、语言包、加载 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明多语言对首屏性能的影响及优化。

参考答案：

核心思路如下：

语言包过大增加请求和解析时间
SSR 时注入当前语言数据减少请求
按需加载 namespace
语言包缓存和 CDN
默认语言内联，其他异步

需要避免的典型误区：

首屏加载所有语言
SSR 不注入语言数据
语言包阻塞渲染

补充说明：

在实际落地国际化对首屏性能的影响时，建议结合 i18n、首屏、SSR 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：语言包过大增加请求和解析时间、SSR 时注入当前语言数据减少请求等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

首屏加载所有语言
SSR 不注入语言数据
语言包阻塞渲染

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

语言包过大增加请求和解析时间；SSR 时注入当前语言数据减少请求；按需加载 namespace；语言包缓存和 CDN；默认语言内联，其他异步。同时要避免首屏加载所有语言。

FB-33-CO-A-013：文化本地化与简单翻译的区别

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：本地化、文化、颜色、图标、文案 出现频率：低频 预计回答时长：3-5 分钟

题目描述：请举例说明本地化不只是翻译。

参考答案：

核心思路如下：

颜色、图标、手势在不同文化含义不同
日期格式、地址格式、姓名顺序
支付方式、货币、税务规则
内容策略：节日、法律、合规
需要本地团队审核

需要避免的典型误区：

只做直译
使用有文化争议的图标
忽略本地法律法规

补充说明：

在实际落地文化本地化与简单翻译的区别时，建议结合本地化、文化、颜色的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：颜色、图标、手势在不同文化含义不同、日期格式、地址格式、姓名顺序等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只做直译
使用有文化争议的图标
忽略本地法律法规

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

颜色、图标、手势在不同文化含义不同；日期格式、地址格式、姓名顺序；支付方式、货币、税务规则；内容策略；需要本地团队审核。同时要避免只做直译。

FB-33-SC-A-005：如何在前端做翻译质量检查

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：翻译、质量、检查、CI、lint 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明如何在工程流程中保障翻译质量。

参考答案：

核心思路如下：

CI 检测未翻译 key 和占位符不匹配
伪本地化测试布局
翻译人员与开发协作平台
关键页面截图对比
用户反馈渠道与快速修正

需要避免的典型误区：

上线前才给翻译
不检查占位符
无用户反馈机制

补充说明：

在实际落地在前端做翻译质量检查时，建议结合翻译、质量、检查的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：CI 检测未翻译 key 和占位符不匹配、伪本地化测试布局等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

上线前才给翻译
不检查占位符
无用户反馈机制

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

CI 检测未翻译 key 和占位符不匹配；伪本地化测试布局；翻译人员与开发协作平台；关键页面截图对比；用户反馈渠道与快速修正。同时要避免上线前才给翻译。

FB-33-CO-B-014：Locale 与 Language Tag 的区别

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：33 国际化标签：Locale、Language Tag、i18n、地区、语言 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释 locale 和 language tag 的含义。

参考答案：

核心思路如下：

Language Tag 如 zh-CN、en-US，标识语言+地区
Locale 包含语言、地区、格式约定
Locale 影响日期、数字、货币格式
选择时应区分语言与地区
回退链基于 language tag

需要避免的典型误区：

只保存语言不保存地区
locale 与格式混用
忽略方言差异

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：Language Tag 如 zh-CN、en-US，标识语言+地区、Locale 包含语言、地区、格式约定等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只保存语言不保存地区
locale 与格式混用
忽略方言差异

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

Language Tag 如 zh-CN、en-US，标识语言+地区；Locale 包含语言、地区、格式约定；Locale 影响日期、数字、货币格式；选择时应区分语言与地区；回退链基于 language tag。同时要避免只保存语言不保存地区。

FB-33-SC-A-006：多语言下的日期格式化

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：日期、格式化、i18n、Intl、locale 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明前端如何按 locale 格式化日期。

参考答案：

核心思路如下：

使用 Intl.DateTimeFormat
根据用户 locale 选择格式
区分长、短、数字格式
存储 UTC，显示本地
考虑日历差异

需要避免的典型误区：

手写日期格式
忽略用户 locale
时区与 locale 混淆

补充说明：

在实际落地多语言下的日期格式化时，建议结合日期、格式化、i18n 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：使用 Intl.DateTimeFormat、根据用户 locale 选择格式等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

手写日期格式
忽略用户 locale
时区与 locale 混淆

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

使用 Intl.DateTimeFormat；根据用户 locale 选择格式；区分长、短、数字格式；存储 UTC，显示本地；考虑日历差异。同时要避免手写日期格式。

FB-33-CO-A-014：翻译中的上下文问题

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：翻译、上下文、一词多义、i18n 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明同一词汇在不同上下文中翻译不同的处理。

参考答案：

核心思路如下：

给翻译 key 添加上下文描述
同一词不同含义用不同 key
提供截图或使用场景
使用 ICU select 处理性别等
避免孤立字符串

需要避免的典型误区：

同一 key 用于多个含义
不提供上下文
直译导致歧义

补充说明：

在实际落地翻译中的上下文问题时，建议结合翻译、上下文、一词多义的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：给翻译 key 添加上下文描述、同一词不同含义用不同 key 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

同一 key 用于多个含义
不提供上下文
直译导致歧义

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

给翻译 key 添加上下文描述；同一词不同含义用不同 key；提供截图或使用场景；使用 ICU select 处理性别等；避免孤立字符串。同时要避免同一 key 用于多个含义。

FB-33-PE-A-004：多语言资源分包策略

题型：性能优化题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：i18n、资源分包、按需加载、性能 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明如何按页面拆分包多语言资源。

参考答案：

核心思路如下：

每个页面/模块独立语言包
进入路由时加载对应包
公共文案放基础包
预加载默认语言
按语言分包打包

需要避免的典型误区：

所有文案一个文件
不按需加载
分包过细请求过多

补充说明：

在实际落地多语言资源分包策略时，建议结合 i18n、资源分包、按需加载的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：每个页面/模块独立语言包、进入路由时加载对应包等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有文案一个文件
不按需加载
分包过细请求过多

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

每个页面/模块独立语言包；进入路由时加载对应包；公共文案放基础包；预加载默认语言；按语言分包打包。同时要避免所有文案一个文件。

FB-33-SC-A-007：RTL 测试要点

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：RTL、测试、布局、方向、i18n 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明 RTL 语言界面测试的关键点。

参考答案：

核心思路如下：

整体布局是否镜像
图标和箭头方向是否正确
文本对齐方式
表单输入框方向
数字和标点显示

需要避免的典型误区：

只翻译文本不测试布局
使用固定 left/right
忽略图标方向

补充说明：

在实际落地 RTL 测试要点时，建议结合 RTL、测试、布局的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：整体布局是否镜像、图标和箭头方向是否正确等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只翻译文本不测试布局
使用固定 left/right
忽略图标方向

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

整体布局是否镜像；图标和箭头方向是否正确；文本对齐方式；表单输入框方向；数字和标点显示。同时要避免只翻译文本不测试布局。

FB-33-CO-A-015：ICU Message Format 简介

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：33 国际化标签：ICU、message format、国际化、复数、插值 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明 ICU Message Format 解决了什么问题。

参考答案：

核心思路如下：

统一插值、复数、选择、数字日期格式
支持不同语言复数规则
便于翻译平台解析
如 {count, plural, one {# item}}
被 react-intl、FormatJS 使用

需要避免的典型误区：

不用 ICU 自己拼字符串
翻译人员不懂语法
未做语法校验

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：统一插值、复数、选择、数字日期格式、支持不同语言复数规则等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

不用 ICU 自己拼字符串
翻译人员不懂语法
未做语法校验

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

统一插值、复数、选择、数字日期格式；支持不同语言复数规则；便于翻译平台解析；如 {count, plural, one {# item}}；被 react-intl、FormatJS 使用。同时要避免不用 ICU 自己拼字符串。

国际化面试题 ​

目录 ​

基础题（8 道） ​

FB-33-CO-B-001：i18n 与 l10n 有什么区别？ ​

FB-33-CO-B-002：locale 标识应该如何选择与管理？ ​

FB-33-CO-B-003：翻译文件应该如何组织？ ​

FB-33-CO-B-004：如何处理复数、性别、占位符等复杂文案？ ​

FB-33-CO-B-005：日期、时间、数字、货币格式化要注意什么？ ​

FB-33-CO-B-006：RTL（从右到左）布局如何支持？ ​

FB-33-CO-B-007：如何动态加载语言包？ ​

FB-33-CO-B-008：国际化测试应该覆盖哪些方面？ ​

进阶题（8 道） ​

FB-33-CO-A-001：前端 i18n 框架如何选型？ ​

FB-33-CO-A-002：多语言路由与 SEO 如何设计？ ​

FB-33-CO-A-003：服务端渲染与国际化如何结合？ ​

FB-33-CO-A-004：翻译缺失与回退策略如何设计？ ​

FB-33-CO-A-005：翻译工作流与 TMS 如何落地？ ​

FB-33-CO-A-006：本地化的图片、文案和文化差异如何处理？ ​

FB-33-CO-A-007：时区处理有哪些最佳实践？ ​

FB-33-CD-A-001：如何设计一个支持多语言的组件库？ ​

深入题（7 道） ​

FB-33-SD-P-001：如何设计大规模多语言前端平台？ ​

FB-33-CO-P-001：微前端与组件库国际化如何协同？ ​

FB-33-CO-P-002：RTL 与复杂组件（图表、日历）如何支持？ ​

FB-33-PE-P-001：语言包体积如何优化？ ​

FB-33-CO-P-003：自动翻译与人工校对流程如何设计？ ​

FB-33-CO-P-004：设计文案与代码如何解耦？ ​

FB-33-CP-P-001：多语言 A/B 测试如何设计？ ​

架构题（43 道） ​

FB-33-SD-R-001：如何设计全球化前端架构？ ​

FB-33-SD-R-002：如何设计一条翻译流水线？ ​

FB-33-SD-R-003：如何设计国际化组件库？ ​

FB-33-SD-R-004：多语言内容管理系统（CMS）如何设计？ ​

FB-33-CP-R-001：国际化度量与监控应该关注哪些指标？ ​

FB-33-CP-R-002：跨团队国际化治理如何推进？ ​

FB-33-CP-R-003：合规与本地化法律要求如何影响前端架构？ ​

FB-33-CP-B-001：什么是 i18n 和 l10n？有什么区别？ ​

FB-33-CO-B-009：前端 i18n 有哪些核心问题需要解决？ ​

FB-33-CO-B-010：如何处理 RTL 布局？ ​

二、进阶题 ​

FB-33-CO-A-008：ICU MessageFormat 有什么作用？ ​

FB-33-SD-A-001：如何设计一个可扩展的翻译工作流？ ​

FB-33-EN-A-001：全球化部署需要考虑哪些合规问题？ ​

三、高级题 ​

FB-33-CO-B-011：前端国际化的核心问题有哪些 ​

FB-33-CO-A-009：i18n 与 l10n 的区别 ​

FB-33-SC-A-001：如何设计前端多语言资源管理 ​

FB-33-CO-A-010：React/Vue 中常见的 i18n 方案 ​

FB-33-PE-A-001：国际化对前端性能的影响及优化 ​

FB-33-SC-P-001：如何处理 ICU 复数与插值 ​

FB-33-CO-P-005：RTL 语言布局如何支持 ​

FB-33-SC-A-002：国际化与路由/SEO 的结合 ​

FB-33-CO-A-011：时区与日期时间处理 ​

FB-33-SC-P-002：如何设计组件库的多语言支持 ​

FB-33-CO-P-006：翻译管理系统如何与前端集成 ​

FB-33-SC-A-003：前端如何做语言切换体验 ​

FB-33-CO-B-012：什么是伪本地化（Pseudolocalization） ​

FB-33-SC-P-003：国际化项目的测试策略 ​

FB-33-PE-A-002：多语言包的体积优化 ​

FB-33-CO-P-007：货币与数字格式化 ​

FB-33-SC-A-004：如何处理翻译中的占位符和 HTML ​

FB-33-CO-A-012：国际化中的语言回退策略 ​

FB-33-SD-R-005：设计一个可扩展的国际化架构 ​

FB-33-CO-B-013：Intl API 在前端的使用 ​

FB-33-SC-P-004：如何处理多语言下的 SEO 与预渲染 ​

FB-33-PE-A-003：国际化对首屏性能的影响 ​

FB-33-CO-A-013：文化本地化与简单翻译的区别 ​

FB-33-SC-A-005：如何在前端做翻译质量检查 ​

FB-33-CO-B-014：Locale 与 Language Tag 的区别 ​

FB-33-SC-A-006：多语言下的日期格式化 ​

FB-33-CO-A-014：翻译中的上下文问题 ​

FB-33-PE-A-004：多语言资源分包策略 ​

FB-33-SC-A-007：RTL 测试要点 ​

FB-33-CO-A-015：ICU Message Format 简介 ​

国际化面试题

目录

基础题（8 道）

FB-33-CO-B-001：i18n 与 l10n 有什么区别？

FB-33-CO-B-002：locale 标识应该如何选择与管理？

FB-33-CO-B-003：翻译文件应该如何组织？

FB-33-CO-B-004：如何处理复数、性别、占位符等复杂文案？

FB-33-CO-B-005：日期、时间、数字、货币格式化要注意什么？

FB-33-CO-B-006：RTL（从右到左）布局如何支持？

FB-33-CO-B-007：如何动态加载语言包？

FB-33-CO-B-008：国际化测试应该覆盖哪些方面？

进阶题（8 道）

FB-33-CO-A-001：前端 i18n 框架如何选型？

FB-33-CO-A-002：多语言路由与 SEO 如何设计？

FB-33-CO-A-003：服务端渲染与国际化如何结合？

FB-33-CO-A-004：翻译缺失与回退策略如何设计？

FB-33-CO-A-005：翻译工作流与 TMS 如何落地？

FB-33-CO-A-006：本地化的图片、文案和文化差异如何处理？

FB-33-CO-A-007：时区处理有哪些最佳实践？

FB-33-CD-A-001：如何设计一个支持多语言的组件库？

深入题（7 道）

FB-33-SD-P-001：如何设计大规模多语言前端平台？

FB-33-CO-P-001：微前端与组件库国际化如何协同？

FB-33-CO-P-002：RTL 与复杂组件（图表、日历）如何支持？

FB-33-PE-P-001：语言包体积如何优化？

FB-33-CO-P-003：自动翻译与人工校对流程如何设计？

FB-33-CO-P-004：设计文案与代码如何解耦？

FB-33-CP-P-001：多语言 A/B 测试如何设计？

架构题（43 道）

FB-33-SD-R-001：如何设计全球化前端架构？

FB-33-SD-R-002：如何设计一条翻译流水线？

FB-33-SD-R-003：如何设计国际化组件库？

FB-33-SD-R-004：多语言内容管理系统（CMS）如何设计？

FB-33-CP-R-001：国际化度量与监控应该关注哪些指标？

FB-33-CP-R-002：跨团队国际化治理如何推进？

FB-33-CP-R-003：合规与本地化法律要求如何影响前端架构？

FB-33-CP-B-001：什么是 i18n 和 l10n？有什么区别？

FB-33-CO-B-009：前端 i18n 有哪些核心问题需要解决？

FB-33-CO-B-010：如何处理 RTL 布局？

二、进阶题

FB-33-CO-A-008：ICU MessageFormat 有什么作用？

FB-33-SD-A-001：如何设计一个可扩展的翻译工作流？

FB-33-EN-A-001：全球化部署需要考虑哪些合规问题？

三、高级题

FB-33-CO-B-011：前端国际化的核心问题有哪些

FB-33-CO-A-009：i18n 与 l10n 的区别

FB-33-SC-A-001：如何设计前端多语言资源管理

FB-33-CO-A-010：React/Vue 中常见的 i18n 方案

FB-33-PE-A-001：国际化对前端性能的影响及优化

FB-33-SC-P-001：如何处理 ICU 复数与插值

FB-33-CO-P-005：RTL 语言布局如何支持

FB-33-SC-A-002：国际化与路由/SEO 的结合

FB-33-CO-A-011：时区与日期时间处理

FB-33-SC-P-002：如何设计组件库的多语言支持

FB-33-CO-P-006：翻译管理系统如何与前端集成

FB-33-SC-A-003：前端如何做语言切换体验

FB-33-CO-B-012：什么是伪本地化（Pseudolocalization）

FB-33-SC-P-003：国际化项目的测试策略

FB-33-PE-A-002：多语言包的体积优化

FB-33-CO-P-007：货币与数字格式化

FB-33-SC-A-004：如何处理翻译中的占位符和 HTML

FB-33-CO-A-012：国际化中的语言回退策略

FB-33-SD-R-005：设计一个可扩展的国际化架构

FB-33-CO-B-013：Intl API 在前端的使用

FB-33-SC-P-004：如何处理多语言下的 SEO 与预渲染

FB-33-PE-A-003：国际化对首屏性能的影响

FB-33-CO-A-013：文化本地化与简单翻译的区别

FB-33-SC-A-005：如何在前端做翻译质量检查

FB-33-CO-B-014：Locale 与 Language Tag 的区别

FB-33-SC-A-006：多语言下的日期格式化

FB-33-CO-A-014：翻译中的上下文问题

FB-33-PE-A-004：多语言资源分包策略

FB-33-SC-A-007：RTL 测试要点

FB-33-CO-A-015：ICU Message Format 简介