Phaser 可访问性与 CJK 本地化：中文排版、字号和辅助输入

可访问性不是最后加一个选项

很多 Phaser 小游戏把可访问性和本地化当成上线前检查项：中文能显示，按钮能点，英文不溢出就算完成。实际玩家设备、视力、语言、输入习惯差异很大。字号太小、红绿区分、按钮热区不足、中文断行奇怪、音效没有字幕，这些都会让一部分玩家直接流失。

我处理过一个竖屏解谜 H5，中文版正常，繁中和英文上线后问题很多：英文按钮溢出，日文没有正确换行，中文标点挤在行首，色弱玩家分不清红蓝机关，低视力玩家看不清倒计时。代码没有崩，但体验对很多玩家不可用。

Phaser 的 Canvas/WebGL 渲染不天然具备浏览器 DOM 的可访问性能力，所以更要主动设计。文本渲染、布局、颜色、输入、音频提示和设置项，都要从一开始留出空间。

flowchart TD
    A[本地化文本资源] --> B[文本测量和换行]
    B --> C[响应式 UI 布局]
    D[可访问性设置] --> E[字号/对比度/色弱/字幕]
    C --> F[Phaser UI 渲染]
    E --> F
    G[键盘/触控/辅助输入] --> H[统一输入意图]
    H --> F

CJK 换行不能照搬英文

中文、日文、韩文的换行和英文不同。英文有空格，单词不应随便断；中文没有空格，但标点不能随意出现在行首；日文也有禁则处理。Phaser Text 的自动换行能解决一部分问题，但复杂 UI 仍需要自己测量和处理。

中文文本最好避免固定像素宽度下硬塞。按钮文案要有最大字数或动态缩放策略，长标题允许两行，说明文字使用固定宽度换行。不要让运营随便改一段长文案进按钮。内容检查可以提前发现超长文案。

字体也要谨慎。CJK 字体体积大，Web 游戏不可能随便打包完整字体。可以使用系统字体栈，或只为标题使用子集字体。若使用 WebFont，要处理加载前后的布局变化。字体没加载时，按钮宽度可能变化，导致点击区域和视觉不一致。

字号和对比度要按场景设计

游戏 UI 经常为了视觉风格使用小字、低对比、发光背景。移动端上，这些都会变成可读性问题。正文说明、任务目标、倒计时、奖励数量、错误提示都应该有最低字号和对比度要求。

不要用 viewport 宽度随意缩放字体。小屏上过小，大屏上过大。更稳的是定义几档字号：正文、辅助、标题、数字，按 UI 容器和语言调整。玩家设置大字号时，布局要能容纳，而不是文字互相覆盖。

对比度不仅是黑白。彩色背景上的黄色字、半透明弹窗上的灰字、红色警告叠在橙色火焰上，都可能不可读。开发时可以准备几张高噪声背景测试 UI，不要只在干净背景上看。

色弱模式要改变编码方式

很多游戏用红色表示敌方、绿色表示友方，红色表示危险、绿色表示安全。对色弱玩家来说，这可能完全不可分。解决方式不是简单换一套颜色，还要增加形状、图案、边框和图标。

比如危险格用红色加斜线纹理，安全格用蓝色加圆点，敌方单位用尖角边框，友方用圆角边框。状态图标也要形状不同，不只靠颜色。Phaser 里可以用不同纹理、Graphics 图案或 shader 实现，但核心是信息编码不能只有颜色。

色弱模式应该在设置里可切换，并能即时刷新 UI。不要只在启动时读取。玩家进入某个关卡发现看不清，应该能马上打开设置调整。

输入辅助要统一成意图

可访问性也包括输入。PC 玩家可能用鼠标，移动端用触控，部分玩家需要键盘操作或外接手柄。Phaser 输入系统支持多种输入，但业务层最好接收统一意图：confirm、cancel、move、openMenu、selectNext。

不要让按钮只支持 pointerdown。重要操作应该能通过键盘焦点或快捷键触发。菜单应支持方向键切换和确认。移动端按钮热区要足够大，连续点击要有防抖，但不能让操作感觉迟钝。

对动作游戏，可以提供自动瞄准、长按连发、降低连点要求、震动开关。可访问性不是降低游戏价值，而是让更多玩家能完成同样意图。

字幕和音频提示

如果游戏依赖音频提示，例如敌人出现、倒计时、机关启动，就要提供视觉替代。字幕、图标闪烁、屏幕边缘提示都可以。玩家可能静音游玩，也可能听不清某些频率。

字幕要可读：足够字号、背景遮罩、显示时间、说话人标识。剧情配音、战斗提示、系统播报可以分不同字幕样式。不要把字幕放在操作按钮上方遮挡输入。

音量设置也要分组：背景音乐、音效、语音。很多玩家想关音乐但保留提示音。移动浏览器音频解锁失败时，也要有视觉提示，不要让玩家以为游戏卡了。

一个文本布局接口

下面示例展示文本测量和截断的入口。真实项目可以接入更复杂的换行库，但 UI 不应该散落手写截断。

type TextFitOptions = { maxWidth: number; maxLines: number; minFontSize: number };

function fitText(label: Phaser.GameObjects.Text, content: string, options: TextFitOptions) {
  label.setText(content);
  while ((label.width > options.maxWidth || label.getWrappedText(content).length > options.maxLines) &&
    Number(label.style.fontSize) > options.minFontSize) {
    label.setFontSize(Number(label.style.fontSize) - 1);
  }
}

重点不是这段代码完美，而是让文本适配成为统一能力。按钮、弹窗、任务追踪、奖励说明都调用同一套策略，后续优化 CJK 换行时不用全项目找。

本地化流程要早接入

本地化不应该等所有 UI 完成后再翻译。开发阶段就要用伪本地化测试：把文本加长、加入特殊字符、改变方向或标点，看看布局是否崩。中文项目也要测试英文长词和日文假名，不要只看简体中文。

文本 key 要稳定，不要用中文原文当 key。文案变化时 key 不变，翻译表更新即可。动态文本要使用参数，例如 {count}，不要拼接半句。不同语言语序不同，拼接会出错。

内容检查可以扫描缺失 key、未使用 key、超长文本和非法换行。Phaser 项目虽然不是传统网页，也需要本地化质量门槛。

上线前检查清单

上线前检查：CJK 换行是否合理，按钮长文案是否不溢出，字号是否有最低值，色弱模式是否不只换颜色，键盘是否能操作菜单，字幕是否覆盖音频提示，伪本地化是否跑过，字体加载失败是否有回退。

还要在真实手机上看：低亮度、户外强光、静音、单手操作、大字号设置、不同语言包、长昵称和长奖励名。可访问性问题往往不是功能不可用，而是玩家用起来很累。

数字、单位和时间也要本地化

本地化不只是翻译句子。数字格式、日期、倒计时、货币、百分比、单位都需要一致。中文里可以写“剩余 3 天”，英文可能是“3 days left”，日文和韩文又有不同语序。不要用字符串拼接，把数字插进半句话里。

奖励数量也要注意。1000、1,000、1 000 在不同地区习惯不同。百分比概率显示要和商店规则一致，小数位也要统一。倒计时如果涉及活动结束，应以服务端时间为准，本地只做展示。

玩家昵称和自定义文本也会影响布局。中文昵称可能很短，英文昵称可能很长，还有 emoji 和特殊符号。Phaser Text 对 emoji 和组合字符支持不一定稳定，输入前最好限制长度和字符集，显示时提供截断和 tooltip 或详情弹窗。

可访问性设置要能持久保存

玩家打开大字号、关闭震动、启用色弱模式、打开字幕后，下次进入应该保留。设置属于用户偏好，适合本地保存，也可以随账号同步。不要只在当前 Scene 内有效。

设置改变后，当前 UI 要能刷新。字号变大后，弹窗需要重新布局；色弱模式开启后，范围高亮要换纹理；字幕开启后，音频提示要显示文字。若设置只对下次启动生效，要明确提示。

设置界面本身也要可访问。不能把“大字号”选项做成很小的字，不能只靠颜色表示开关状态。可访问性功能如果本身难以使用，就失去意义。

面向测试的检查工具

可以做一个 UI 文本检查 Scene，列出所有按钮、弹窗、任务条、奖励卡片，在不同语言和字号下预览。测试不需要逐个进入功能，就能看到溢出和重叠。这个工具对内容密集的 Phaser 游戏非常实用。

还可以提供色弱模拟和对比度检查。即使不做到专业级自动化，至少让团队能快速切换几种配色，看危险区、友方、敌方和可交互对象是否仍然可分。可访问性越早可视化，越不会在上线前变成返工。

Canvas 游戏也要考虑屏幕阅读器边界

Phaser 主要通过 Canvas/WebGL 渲染，屏幕阅读器无法天然理解里面的按钮和文本。如果目标用户明确需要辅助技术支持，可以在关键 UI 外层配合 DOM 节点，提供可聚焦按钮、aria-label 和状态描述。不是所有游戏都要做到完整无障碍，但关键支付、登录、设置和帮助入口应该尽量可达。

混合 DOM 和 Phaser UI 要谨慎。DOM 元素的位置要跟随 canvas 缩放，弹窗打开时焦点要进入弹窗，关闭后焦点回到触发按钮。否则屏幕阅读器用户会迷失。对轻量小游戏，至少可以提供 DOM 版设置入口和帮助说明。

如果游戏依赖实时动作，屏幕阅读器支持可能有限，但仍可以改善菜单、剧情、商店和设置。可访问性不是全有或全无，每改善一个关键流程，就减少一部分玩家的障碍。

团队流程要给可访问性留时间

可访问性问题很难在最后一天修。字号变大可能导致布局重做，色弱模式可能需要新图标，字幕可能影响演出节奏，本地化可能要求 UI 重新排版。项目排期里要给这些检查留时间，而不是等翻译回来再发现按钮都放不下。

可以把检查项放进 PR 或内容验收：新增 UI 是否支持长文本，新增颜色是否有非颜色编码，新增音频提示是否有视觉替代，新增设置是否持久保存。流程化以后，可访问性才不会依赖某个人临时想起。

数据也能帮助判断。设置里有多少玩家开启大字号、字幕、色弱模式，哪些语言下按钮点击率异常低，都可能提示问题。尊重这些数据，比主观判断“应该看得清”更可靠。

本地化问题也要有反馈入口。玩家看到错译、溢出或乱码时，最好能复制页面 key 和语言版本。工程拿到 key，比拿到一张截图更容易定位到具体文本和 UI 容器。

翻译修复也要能快速验证。文本检查 Scene 支持按 key 搜索，能让本地化同学直接看到修复后的实际 UI，而不是只看表格。

还要注意图片里的文字。很多游戏把“开始”“胜利”“限时”做进贴图，本地化时这些文字无法自动替换。能用 Phaser Text 渲染的尽量不要烘进图片；必须烘进图片时，要把图片也纳入语言资源和缺失检查。

这类图片文字还要考虑高清屏和不同语言长度，不能只替换同尺寸贴图。

资源命名也要带语言标识，否则 CDN 缓存和 Phaser key 很容易串用旧语言图片。

语言切换时要清理旧语言资源引用，或者使用不同 key 并重新布局。只替换文本不重排 UI，很多溢出问题仍然会存在。

切换完成后最好回到同一界面，让玩家立刻确认语言效果。

如果必须重启，也要提前说明原因，并确保设置已经保存成功。

结语

Phaser 可访问性和本地化不是额外装饰，而是 UI 工程的一部分。文本、颜色、输入和音频提示都要有可调整空间。尤其是中文和多语言项目，CJK 换行、字号和字体策略要尽早设计。

让更多玩家能看清、听懂、点到、理解，就是提升游戏质量。小团队也可以从统一文本适配、色弱模式、字幕和输入意图开始，把可访问性变成可执行的工程约束。