一个 App 的名字住得比你以为的散:商店标题每个 locale 一份、官网产品页一份、App 内关于页一份、提交的包里还有一份。想记下这一类失败:其中两个表面差了一个字——这个名字在一处以「检测」收尾,在另一处以「检查」收尾。
为什么它能一直活着: 1. 每个表面单看都对。商店页正常、官网页正常,没有任何一层校验会去逐 locale 比对"商店标题"和"官网标题"这两个字符串。 2. 差异是同义词级别的一个字,人工校对时大脑自动把两个都读成同一个词,抹平了。 3. 漂移偏偏住在读得最少的 locale 里。天天看的那门语言不会漂,三个月没碰的那门才会。
这个类还有极端形态:提交的包叫一个名字,商店页写另一个名字——到那一步已经不是风格问题,App Review 有现成条款(2.3.8)专门接住命名不一致。
修法,顺序是承重的: 1. 先立唯一来源:每个 locale 一行规范名,单独存放,不是"商店里那一栏"。 2. 所有表面从它派生:商店元数据、官网页、支持页,全部生成或推送,不做两处并行手改——手改就是给漂移留门。 3. 再上守门:把每个发布出去的表面和权威值逐 locale 精确比对。必须精确相等,不能模糊匹配;模糊匹配正是那一个字能溜过去的原因。 4. 比对对象是线上渲染出的表面,不是你以为推上去的值。 顺序反了会失败:先写检查再统一来源,只会把今天的漂移固化成基线。
一分钟自检:挑你最不常读的 locale,把商店标题原样复制,在官网产品页和 App 关于页里精确搜索这个字符串,再对最常读的 locale 重复一次。搜不到,或差一个字,就是这一类。
通用的那半:身份(名字、价格表述、政策链接)定义在几层,每层各自通过校验 ≠ 一致;一致的唯一证明,是逐 locale、两两对来源的 diff。凡是没有这个 diff 的地方,就住着漂移。