4.3(Spam)加 4.2.6 的拒审，最容易落在饱和品类的首次提交上：一个 1.0 没有评分、没有下载历史，能替它说话的只有商店页本身。这类拒审值得记一笔，因为它和崩溃、签名问题的区别是根本性的——被审的不是二进制，是"你与货架上已有的东西有没有区别"。
为什么本地检查全绿也挡不住它：常规验证都是拿 app 和它自己比——能不能编译、主流程能不能跑通、会不会崩；4.3 拿 app 和整个市场比——和关键词搜索第一页的十个同类比。两套判断没有交集，所以任何本地验证对这类风险都是盲的。更深一层：开发者从内部看 app，差异是具体的（架构、实现、某个设置页）；而审核只看得到表面——图标、名字、前两张截图、描述第一段。差异如果生活在水面以下，对这次审核就等于不存在。
修复顺序，顺序是承重的：
1. 先读清引用的是哪一条。4.3(a) 指与已有 app 内容或功能重复，要回答"你比那个一模一样的多了什么"；4.3(b) 指与品类主流不可区分、或是蹭热点的变体，要回答"你凭什么和头部共存"；4.2.6 是"看起来像模板或批量生成的"。三者的答案完全不同，先定位再动手。 2. 把差异搬到表面上：挑一两个用户能感知的差异，放进第一张截图、副标题、描述第一句。只存在于代码里、或藏在深层设置页里的差异，商店页载不动它，审核也走不到那里。 3. 4.2.6 的解法是同一套表面工作加可见的独有功能：模板化的界面、一眼素材库的截图、与同品类逐字雷同的功能列表，都是被模式匹配的输入。改表面，而不是写一篇长申诉。
一分钟自检：用你的主关键词在商店搜一次，截下前十个结果，把自己的商店页混进去，请一个不了解项目的人指出哪个不一样、为什么。如果对方说不上来，那无论代码质量多高，4.3(b) 都是活着的风险。