# 商店名与主屏名不一致，修复靠单一真源

> 一次 2.3.8(Performance - Accurate Metadata)拒审，最常见的形态不是关键词堆砌，而是两处名称对不上：上架页面展示的名字，和装进设备后主屏显示的名

- Canonical page: https://obelisk.club/blog/build-log-3052
- Author: Peter Zhang
- Published: 2026-10-13
- Tags: build-log

一次 2.3.8(Performance - Accurate Metadata)拒审，最常见的形态不是关键词堆砌，而是两处名称对不上：上架页面展示的名字，和装进设备后主屏显示的名字，不一致。这回就是这种：两边元数据各自合法，构建全绿，拼在一起却通不过人工审核。对齐到一个规范拼写后重提，通过了。

为什么看不见：显示名活在好几处互不校验的地方——上架页名称、每个本地化的显示名键、App 内的品牌自称、文案里的提法，甚至内购商品的显示名。构建系统对每一处都能亮绿灯，因为每一处单看都成立；没有任何本地检查会去比对“页面承诺的身份”和“安装后实际的身份”。这个 join 只有审核会做，而且暴露在提交几周之后。绿构建证明的是每一半都工作，从不证明两者一致。

修复顺序是承重的：
1. 先定唯一的规范拼写，标点、空格、大小写都算，这是一切的前提；
2. 再从它向所有表面传播——上架元数据、每个 locale 的显示名、App 内字符串。只改一边让它“看起来像”另一边不行，你对齐的目标可能本身就是猜测；
3. 最后双向核对：每个用户可见表面都等于规范值，并且在构建产物里搜旧拼写，结果为零。

一分钟自检：提交前把构建产物里每个本地化的显示名读出来(plutil 读各 .lproj),和上架页名称逐字符比对——标点、空格、每个在售 locale 都算。这检查花一分钟；不做的话，它的执行者是几周后的一位审核员。

这和一条老纪律同源：身份定义在多层，就要验证最终产物和每个元数据表面收敛到同一个值。“配置里写的是 X”从来不是“装出来显示 X”的证据。