在我们自己的送审里，Guideline 2.3.8（准确的元数据） 拒审最常见的形态不是关键词堆砌，而是两处名称对不上：上架页面展示的名字，和装进设备后主屏图标下的名字。两边各自合法，构建全绿，拼在一起却通不过人工审核。对齐到一个规范拼写后重提，通过了。
为什么看不见
同一个名字活在好几处互不校验的地方：每个语言的商店名、每个本地化的显示名键、App 内的关于页、文案里的提法，甚至内购商品的显示名。构建对每一处都亮绿灯，因为每一处单看都成立。没有任何本地检查会去比对“页面承诺的身份”和“安装后实际的身份”，这个 join 只有审核会做，而且可能在提交几周之后才暴露。
还有两个细节让它更隐蔽：
- 按语言漂移。 英文一致、中文漂移，只有设备语言恰好落在漂移的那个语言上才会被撞破。单语言的检查对此天生是盲的。
- 只差一个字。 我们发现过两个表面的名字只差一个近义词。人工校对时大脑会把两个读成同一个词，自动抹平。
修复顺序
- 先定唯一的规范拼写， 标点、空格、大小写都算。一切以它为前提。
- 列全每个落点： 各语言的显示名、各语言的商店名字段、官网、App 内字符串、内购显示名。用 grep 找，不要靠回忆，第一遍 grep 总是漏。
- 从来源向所有表面传播。 只改一边让它“看起来像”另一边不行，你对齐的目标可能本身就是猜测。
- 提交前双向对照。 每个用户可见表面都等于规范值，并且在构建产物里搜旧拼写，结果为零。比对必须精确相等；模糊匹配正是那一个字能溜过去的原因。
顺序不能反：先写检查再统一来源，只会把今天的漂移固化成基线。
一分钟自检
从构建产物里读出每个本地化的显示名（各 .lproj 里的 InfoPlist 字符串），和对应语言的商店名逐字符比对，标点、空格、每个在售语言都算。这一分钟不花的话，执行它的将是几周后的一位审核员。
以上来自 Obelisk Club 自己的送审记录。Apple 的措辞会变，请以当前 App Review 指南和你收到的消息为准。