iOS审核4.3(a)全解析：全新代码策略与上架自救指南

1. 4.3(a) 到底是什么：被拒的瞬间，你可能根本没看懂苹果在说什么

收到 4.3(a) 的邮件大概是 iOS 开发者最不想面对的噩梦。标题里写着“iOS 上架 审核 4.3(a)【全新代码】”，这个“全新代码”就是当前很多团队用来翻盘的唯一突破口。先说清楚，4.3(a) 这条审核条款在开发者社区里通常被叫做“重复应用”或者“垃圾应用”条款。苹果的定义是：你的 App 和其他 App 在功能、内容、界面或代码上存在高度相似性，或者你提审的 App 本身没有足够的差异化价值，就会被判定为“垃圾”或“重复”。翻译成大白话就是——苹果审核人员觉得你上传了一个“差不多”的应用，而这个应用没有为 App Store 生态带来任何新的东西。

我见过很多开发者在第一次收到 4.3(a) 时，第一反应是“我的代码明明是重新写的啊，为什么还说重复？”这个困惑特别典型。因为 4.3(a) 这个条款的判定依据并不是单纯的代码层面，它是一套综合维度的评估机制。苹果审核团队会对比你当前提交的 App 与 App Store 上已有的 App、你自己账号下的其他 App、甚至你之前提交过的被拒版本，从多个维度抽象出“相似度”这个概念。代码、UI 界面、功能模块、交互逻辑、元数据、图标风格，甚至服务器配置都可能进入评估范围。很多时候你以为你改掉了核心代码，但审核人员看到你的界面布局和操作流程，第一印象仍然是“这怎么又来了一个一样的？”

更扎心的是，4.3(a) 的拒审通知往往非常简短，通常只有一句“Your app is similar to other apps you have submitted, which is considered a form of spam”或者“This app duplicates the content and functionality of other apps”。没有具体说明到底哪里重复了。这就让开发者陷入一个困境：明明想改，却不知道该从哪下手。而“全新代码”这个策略，正是在这样的困境下被验证有效的方法——但前提是，你不能真的只做到“代码全新”。

2. 为什么“全新代码”是解除 4.3(a) 的核心，但不是全部

标题里的“全新代码”四个字看起来很简单，但实际操作中，很多团队把“全新代码”理解成“把之前项目里的代码全部删掉重写一遍”，然后兴冲冲去提审，结果又被 4.3(a) 打回来，然后就开始怀疑人生。问题出在哪？出在对“全新”这个概念的理解太狭隘了。

2.1 代码相似度是 4.3(a) 判定的第一道关卡

苹果审核系统确实会有自动化的代码相似度检测机制。如果你提交的二进制包和之前拒绝过的包、或者和自己账号下其他已上架的 App 的二进制包在 class 名称、方法名称、字符串常量、资源文件结构上有大量重合，那么大概率会被标记。这个维度上，“全新代码”确实是最直接的反制手段。你不能继续用原来的工程目录结构，不能继续用同样的 pod 库组合方式，不能继续用同样的业务类命名规则。说白了，你要让代码在静态扫描层面完全“不像”你以前的 App。

但这只是第一道关卡。你以为苹果只靠机器扫描判断吗？不是的，4.3(a) 的最终判断由人工审核员完成。自动化系统会先筛掉一批明显重复的，然后把剩余的可能重复的应用提交给人工审核员。人工审核员会看什么？他们会安装你的 App，打开它，点几个页面，感受一下这个 App 的“气质”。如果你全新的代码写出来的 App，打开界面之后还是一副旧世界的面孔——同样颜色的导航栏，同样排列的按钮，同样的底部 tab 栏风格，同样的功能说明文案，那么审核员就会在报告里备注：该 App 在功能与体验上与另一款 App 高度相似。然后 4.3(a) 再次降临。

2.2 功能与内容差异性：苹果定义的“重复”核心

“全新代码”更像是必要条件，而不是充分条件。真正的充分条件是你必须让审核人员看到一款“不一样”的 App。苹果在 4.3(a) 条款的官方解释中强调，App 应该提供“unique functionality or content”。如果你的 App 和另一个版本的功能几乎一样，比如都是“今日热榜”、都是“天气时钟”、都是“视频剪辑助手”，那么即使你用了一百种编程语言重写，也不见得能通过。因为代码只是皮囊，功能才是灵魂。

举个例子：我此前协助过一个团队，他们的产品是一个“极简待办清单”应用。第一次被 4.3(a) 拒是因为他们有一个同类的已上线 App，两者功能几乎一致。他们狠下心来把所有的代码用另一种语言全部重写，UI 全部重画，甚至连数据结构都换了。结果呢？还是被拒了。原因是什么？审核员对比后说：这两款 App 的功能都是“记录待办事项、设置提醒、按标签分类”，核心使用场景相同。最后是调整了功能侧重点，把“极简待办”改成“语音快速记录待办+自动拆解任务”，新增了完整的语音交互流程，让核心功能从“手动输入”变成了“语音输入”，这才通过了。

所以，如果你的目标仅仅是“换个代码重新提交”，那么我直接劝你省点力气。“全新代码”应该是整个“产品翻新”策略中不可分割的一部分，而不是单独的一个动作。换句话说，你要把你的 App 包装成一个“新产品”，而不仅仅是“旧产品的新代码实现”。

2.3 元数据与截图：审核员的第一印象同样决定生死

很多人有一个误区，觉得审核员一定会认认真真跑完所有功能流程。实际上，审核员时间有限，很多时候他们先是快速扫一眼提交到 App Store Connect 的截图预览、应用名称、副标题、描述，如果这些信息跟之前的版本几乎一样，那基本就在心理上给你打了一个“重复”的标签。所以“全新代码”策略一定要延伸到元数据层面：应用名称、副标题、关键词、简介、截图、预览视频、图标，甚至技术支持网址、隐私政策网址，这些都要做相应的改变。

我见过一个最极端的案例：某个开发者把功能、代码、UI 都改得面目全非了，结果忘了改隐私政策里的公司名称和开发者名称关联的网页商标。审核员打开隐私政策一看，发现里面赫然写着一款同名旧产品，于是又退了。这种小细节经常被忽略，但偏偏会被抓出来。所以你记住：任何在 App Store Connect 中描述 App 身份的信息，都应该服务于“这是一款全新产品”这一叙事。

3. “全新代码”的完整实操方案：从零到上架的翻新流程

这一节里，我直接给出一个可复用的实操框架。这个框架不是空想出来的，是我处理多种 4.3(a) 拒审案例后总结出来的流程。标题里既然点名了“全新代码”，这里就从工程层面开始，一步步把整个翻新过程说清楚。

3.1 工程架构：必须抛弃旧的“骨架”

第一步，不要在你原来的 Xcode 工程文件基础上清理。很多人的“全新代码”是在一个老工程里把.m文件删除，重新添加新文件。这种做法就是自欺欺人。因为“工程文件本身”也是代码相似度的一部分——.xcodeproj/project.pbxproj里的文件引用记录、Build Settings 里的自定义配置、Infoplist 的某个自定义键，这些都会保留你旧工程的特征。

你需要做的是：新建一个 Xcode 工程，从零配置。或者更激进一点，放弃 Xcode 自动生成的模板，用命令行工具自己生成一个工程描述文件。总之，目标是让工程文件本身的“指纹”完全不同于之前的任何一个工程。

我建议使用不同的项目命名规则。如果你的旧 App 内部项目名叫TodoApp，新的就不要叫TodoAppNew，也别叫NewTodoApp。这种“旧名字加后缀”的方式简直是掩耳盗铃。最好用一种完全无关的产品性代称，比如你的新待办应用定位是“语音快速记录”，那内部项目就叫VoiceDraft。工程内的 bundle id 也要严格区分，不要复用你旧账号下任何一个 App 的 bundle id——你可以申请一个新的唯一 bundle id，比如com.example.voicedraft，而不是com.example.todoapp。

特别提醒一点，不要在工程配置里写入任何注释文本，说明这是“旧项目改造”之类的信息。哪怕只是注释，在某些情况下也会被自动检测刻意抓取。我甚至建议你把提交到 Git 仓库的历史记录也清理掉，重新初始化一个仓库。虽然苹果并不会看你的 Git 历史，但这种习惯会让你在心态上更干净，不会有意无意地引用旧代码逻辑。

3.2 代码层面：从语言、命名、架构到资源完全重塑

现在说代码本身。最有效的“全新代码”是更换编程语言。如果你的旧代码是 Swift 写的，新版本就用 Objective-C 写；如果你的旧代码是 OC，新版本尝试用 Swift + SwiftUI。这样一个翻转，自动化代码相似度检测基本失效。但前提是你的团队真的熟练这两种语言，别为了规避审核牺牲开发效率。不过我要说的是，大多数情况下，一个产品如果要“重做”，其实完全可以接受语言切换带来的成本，毕竟这是最稳妥的一招。

其次是类名与方法名。不要用任何业务相关词汇的直译，也别用缩写。比如旧代码里有TaskManager、NotificationHandler、DataStore，新代码里就不要出现TaskManager的任何变体。你用RecordScheduler、AudioNoteProcessor、LocalSnapshotStorage这样完全从新产品角度出发的命名方式。命名不要“像”，而要到“另一个产品”的程度。

架构层面同样要变。之前在 MVC 模式下，Controller 负责所有业务；新项目推荐转向 MVVM 或 Coordinator 框架。这不只是流行趋势，而是会让整个代码的组织方式彻底不同，各种类之间的依赖关系、初始化顺序、方法调用链都产生了新的结构。自动化检测不可能识别出“他们其实业务相同”这种深层语义，他们就是通过表面结构来判断相似度的。

资源文件也要全面替换。不要直接复制旧 UI 的切图资源，哪怕颜色一样，也要重新生成新的 1x/2x/3x 文件。图标要重绘，启动图要重做，音效素材也不能复用。为什么这么严格？因为图片资源的哈希值是可以直接比对的。如果你的旧 App 某个按钮的图片，在新 App 里分析出的哈希值一模一样，那么系统会自动把这两处标记为同一个资源。一旦这种同资源数量达到一定阈值，4.3(a) 的警报就会响起。

3.3 UI 与交互：让用户一眼就觉得不一样

这里说的“不一样”，不是把蓝色换成紫色，也不是把圆角加大一点。因为这类表面改动，审核员人工抽查的时候一眼就能看出来“还是那个东西”。UI 差异性要做到“结构级的变化”。如果原来的主界面是底部三个 Tab，新版本可以改成顶部悬浮标签或侧滑抽屉。如果原来的列表是传统的全屏分区，新版本可以尝试瀑布流或卡片堆叠。如果原来的详情页是上方面图、下方文字，新版本就改成全屏交互、横向翻页或弹层展示。

当然，我说这些不是让你为了“不一样”而乱改设计，导致可用性变差。核心原则是：重新从用户需求出发设计一遍交互，而不是从旧 UI 上做微调。站在审核人员的角度，他只想知道“你在 App Store 上又放了一个什么样的新东西”。如果你展示给他的是一个拥有全新视觉语言和交互模式的产品，他会很自然地承认“这是一个不同的 App”。

我亲自试过的一个技巧是，把整个 App 的“第一屏”重写。因为审核员打开 App 的前几秒，只会盯着第一屏。你可以在第一屏增加一个引导流程，或者直接把核心功能入口前置。比如你的旧版本同意用户一进来就看到待办列表，新版本可以一进来就要求用户尝试“语音输入待办”的示例流程，用完之后才进入列表。这样的交互不仅强化了新产品定位，也让审核员在最短时间内感受到两代产品之间的巨大距离感。

菜单结构、设置页面、关于页面，这些“边角料”也不要忽略。很多开发者改了半天主流程，结果设置页面还满屏旧版文字。审核员不是瞎子，他会点开设置页。所以边缘界面的文案、布局、功能选项也要完全重做一遍，并且确保没有任何旧版术语残留。

3.4 服务端与账号：别让后端出卖你

如果你的 App 需要联网，那么服务端接口也要处理。最明显的就是域名和路径。你不能继续使用旧产品相同的 API 域名，哪怕换个路径也行，但最好是全新的子域名或全新的 API 根路径。有些开发者的 App 代码明明是全新的，但启动时发了一个api.oldproduct.com/v1/user/info的请求，审核员用抓包工具一看，直接就明白了——你换个壳而已。所以，如果你没有能力在这时候重新部署一套新后端，至少也应该使用一个独立的 API 网关，给新版 App 一套独立的接口域名、独立的路径前缀、独立的鉴权 token 体系。

另外一个容易忽视的点是第三方服务的 App 标识。比如说你在新版 App 里仍然使用旧的推送证书、旧的统计 SDK 的 appkey，并且这些 key 在服务端日志中对应着同一个应用名称，这种数据层面的关联在深度审核时也可能被察觉。再有，如果你新版 App 需要支付功能，不要使用旧的 IAP 产品 ID。应该创建一套全新的 IAP 产品 ID，不要因为有历史订单就复用旧 ID。对于 IAP 审核，苹果的审核团队能看到这些 ID 所对应的历史购买记录，如果 ID 下的购买历史和旧版完全一致，也会加强重复判定。

我在处理一次 4.3(a) 拒审时发现一个很有意思的细节：审核反馈邮件里提到“new features are minimal”，但当时我们的新功能其实加了五个。后来排查发现，是因为新版 App 登录后，从服务端拉取的个人资料里的头像地址居然用的是旧版 CDN 路径。这不是核心功能，但审核员可能觉得你的产品数据比例和旧版完全一样，进一步确认了他们的判断。所以说后端数据关联度，往往是被很多人忽略的“暗病”。

3.5 元数据与提交材料：用“新身份”做最后一道保险

刚刚已经说过元数据的重要性，这里再具体展开一遍。当你准备提审时，请把 App Store Connect 里的所有信息当成“简历”来写。应用名称一定要和旧版有区分度，不要只是加个“Pro”后缀。副标题尤其重要，它是苹果审核团队第一眼读取的文本。你可以用副标题直接明确新产品的差异化特色。

截图和预览也要全面重置。旧版的历史截图不要再用了，哪怕你的新界面还没全部画完，也要临时做一套新的 UI 样机图，确保和最终版本差距不要过大。另外把截图上的设备状态栏也处理一下，避免显示旧版本的名称或者旧图标，这个细节看似不重要，但实际上是审核员心里判断的依据之一。

技术支持网址、隐私政策网址、营销网址，这些域名也最好换成新的或者至少调整页面内容。如果你继续使用旧版支持网页，网页上写着旧版 App 的功能介绍和下载链接，那审核员就知道你们的“新产品”仍然和旧版有关系，这会削弱翻新策略的说服力。

在备注信息（Review Notes）里，主动向审核团队说明“这是一个与原产品完全独立的新应用，拥有不同的代码库、不同的产品定位”等描述，是有用的。但措辞要真诚，不要千篇一律。我一般建议在 Review Notes 中重点写出 3 个区别于已有 App 的功能亮点，以及对应的测试账号，让审核员可以快速验证这些差异。注意测试账号要提前准备好，不要审核员点登录的时候才发现临时密码不对。

3.6 排期与团队管理：翻新不是一个人的事

最后补一个团队层面的实操经验。“全新代码”策略的落地，往往需要在功能和体验上做一次重塑，如果不提前规划好开发排期，很容易变成一头扎进去然后无限延期。我建议在动手前先花一周时间做“翻新设计文档”，重点不是代码设计，而是“产品设计翻新表”，把旧版 App 的每个页面、每个功能、每段文案都列出来。然后对照新产品定位，逐行标注“保留 / 修改 /删除 /新增”。只有这张表里的“保留”比例低于 20%，你才真正算走上了“全新代码”的正确路线。

另外一个容易在多人协作里踩的坑：负责写新代码的同事，如果开发的时候经常旧代码和新代码来回切换，容易无意中复制一段旧逻辑，哪怕变量名变了，注释还是旧注释。这会让代码里的注释语言风格、工具链标识等隐性特征暴露。所以尽量让担任新版开发的成员不要接触旧项目文件，只保留产品需求层面的讨论交流。这么做也许有点严格，但面对 4.3(a)，谨慎就是最高优先级。

4. 被 4.3(a) 拒绝后的应对：回复策略与二次提审要点

万一你已经提交了“全新代码”版本，结果还是收到 4.3(a) 拒审，不要慌。这种情况见过很多，通常还有一个更深的坑：审核团队可能依然在你的二进制包里发现了某些旧的痕迹。这个时候你需要一套精准的排查和回复方法。

4.1 优先自查“相似痕迹”清单

收到拒信后，先不要急着去申诉，而是先做一轮自查回顾。我每次处理这种拒审都会按下面这张表格来走一遍：

完成自查后，把每一项结果写成一个文档。重点不是写“我们改了”，而是写“我们旧版是 A，新版是 B，以下是证据”，证据可以是代码片段、截图、资源哈希对比、域名配置等。这个文档就是申诉材料的基础。

4.2 申诉回复的结构与话术

如果你自查后发现确实还有残留风险，那就先修正代码再申诉。如果觉得已经彻底翻新了，但审核还是拒绝，你可以通过 App Store Connect 的“App 审核信息”页面中进行回复。回复内容不要客套，要直接给出你的差异化证明。

我的建议回复结构是：

第一段：明确说明本应用相对于你拒绝过的旧版是完全独立的新代码应用，不是修改版。这里要强调“独立开发的新代码库”和“全新的产品设计”，并列出核心功能上的最大不同。

第二段：列举 3 个最有区分度的功能点，对应到截图或审核备注里的可操作路径。比如你新增了语音拆解任务功能，就说“进入主界面后点击麦克风按钮，说出‘买菜、洗车、写邮件’，应用会自动拆分为三个独立任务”。这种描述能让审核员主动去验证。

第三段：提供测试账号和测试指引，降低审核员的操作成本。如果存在需要登录才能看到的内容，一定要给一个有完整权限的 VIP 测试账号，不要给一个只能看首页的普通账号。

第四段：简要说明你尊重 App Store 的审核政策，未来会持续维护和迭代这款完全独立的产品。这一句可以加，但别写成空话，放在最后表示诚意就好。

整个回复语气要心平气和，不卑不亢。不要用“如果我们哪里违反了规定，请明确指出”这类话，这会让审核员觉得你明知道哪里有问题却在装傻。相反，你应该表现出对审核规则的理解和自己做出的努力。

4.3 二次提审时，不要再犯技术性错误

在回复申诉后，如果审核团队要求你更新二进制后再次提交，那么你需要保证你二次提审的包和第一次申诉时的包，除了修复问题外，不要有任何结构上的“回跳”。最忌的就是：为了修复某个 UI 小问题，把旧工程的某个某个类直接粗暴地拖进新工程，然后这个名字一模一样的类就出现在新包中。这在自动检测看来，就像是你偷偷塞回了旧代码的一部分。

另外，二次提审的构建版本号要保持一致或递增。不要突然间出现一个完全不同的 Build Number，这会让审核系统产生不必要的怀疑。同时，提交前的“版本更新说明”要如实填写本次变更的内容，如果写着“修复了某个旧版遗留问题”，等于自己承认了新版与旧版有某种继承关系。请使用“优化了语音识别的准确度”这样的独立产品更新描述。

5. 常见问题与避坑心得：关于“全新代码”的五个残酷真相

5.1 真相一：共享代码库的复用，在 4.3(a) 面前就是失效的护身符

很多团队喜欢建立一个公共组件库，在几个 App 之间共享网络层、工具类、UI 基础组件。这种工程结构在普通开发中非常高效，但在 4.3(a) 审核中就是致命毒药。如果你被拒的旧版和提交的新版都使用了同一个公共库，哪怕你只改了业务层，公共库的代码也会被自动检测抓住，从而判定为“两个 App 存在共同代码”。解决方案是：在新版中，不要链接任何旧版依赖的本地私有库。对第三方公开库（如网络框架、图片加载库）的使用，这种风险相对较低，因为 App Store 上的几十万应用都在用，不会成为判定重复的依据。可一旦是你自己写的、只有自己用的公共库，一定要在“全新代码”阶段重写或者抽离成完全不同的接口实现。

5.2 真相二：全新代码不能解决“换皮上架”的主观印象

只要你的产品逻辑还是旧思路，哪怕代码是全新的，审核员依然觉得你是“换皮”。最简单一个判断点：如果你自己把新旧两个 App 安装在同一台手机上，盯着用十分钟，你会不会发自内心觉得“这是两个不同的产品”？如果你自己都觉得还是一个东西，那就别指望审核员会用放大镜去发现你的代码有多新鲜。我之前见过一个开发者，在自己账号下已经有了一款“照片处理”App，然后又开发了一款新的“照片处理”App，区别只是滤镜数量不同。被 4.3(a) 拒了三次后，他跑来问我怎么办。我告诉他：最核心的出路不是再换代码，而是换赛道。后来他把新的版本整个改成了“照片转手绘插画”的方向，用户进入后的核心流程完全改变了，滤镜变成辅助工具，产品的核心价值和用户心智都不一样了，这才上了架。

所以，当你决定走“全新代码”路线时，一定要同时决定：我的新应用到底给用户提供了哪些旧应用完全提供不了的价值？如果答案含糊，那后面的一切都会很艰难。

5.3 真相三：相似的语言风格和文案，会暴露你的“老底”

审核人员不一定懂代码，但他能看懂文字。你的 App 内的文案如果和旧版如出一辙，比如同样的欢迎语“欢迎使用某某助手”，同样的空状态提示“暂无数据，下拉刷新”，这样的“企业级套话”在旧版里出现过，在新版又来一遍，就会强化重复认知。新版产品应该形成自己的语气词和提示风格。我见过一个新版的待办应用，把空状态写成了“今天还没有捕捉到任何任务，试试点击右下角的麦克风吧”，这样的文案不仅更贴新产品定位，还和旧版“暂无数据”彻底区分开来。

5.4 真相四：不要同时提交多款“全新代码”的相似 App

“全新代码”只适用于你已经确定要上线的一款独立产品。如果你同时提交了三款类似的 App，每款都是“全新代码”，那在苹果看来这就是大规模垃圾应用发布行为。4.3(a) 的打击范围不仅限于同一产品，还适用于一个开发者账号下的所有产品矩阵。当苹果发现你的账号整体呈现“高频、高相似度提交”的模式，你的账号权重会大幅降低，后续所有的提审都会面临更严格的审查。因此，我建议一个账号下尽量保持产品线的多样性，同类产品最多保留两到三款，且每一款都要有明确的渠道差异或用户细分。

5.5 真相五：被拒后不要频繁修改提审，以免触发更严格的人工审核

有些团队拿到 4.3(a) 后就疯狂修改、疯狂重新提交，一天提审三次。这样做只会让账号被标记为“高风险”。正确的做法是：每次提审都一定要比上一次有“实质性的差异化升级”。慢就是快，认真打磨一个真正独立的版本，好过硬着头皮反复用相同策略试探。

根据我的经验，4.3(a) 的拒审并不是不可逆的。关键是你能否展现出“这个产品值得出现在 App Store”的态度。代码的全新是基础，而产品的独特价值是灵魂。不要只做表面功夫，也不要只在被拒之后才临时抱佛脚。最好是在项目规划之初，就把“独立产品”这个概念放进产品设计当中，这样你自然就不会再畏惧 4.3(a)。

6. 从被拒到上架：我亲眼见证过的最佳翻新案例

最后分享一个比较完整的模拟项目X案例，这次经历让我对“全新代码”有了更深的理解。当时某开发者（这里称呼他为A同学）的产品是一款“壁纸应用”，已经在 App Store 上架两年，后来因为更新不及时被苹果清退过一次。当他重新上传时，连续两次收到 4.3(a)。第一次是因为他把旧版代码换个包名传上去，被秒拒。第二次他确实重写了所有代码，但功能和界面还是“壁纸列表 - 点击预览 - 保存”，依然被拒。

后来我们一起进行了完整的翻新。首先，在产品定位上，把“壁纸应用”改成“根据音乐节奏推荐壁纸的动态壁纸工具”。用户不再需要自己翻找分类，而是选定一首歌，App 通过分析歌曲的 BPM 和情绪特征，推荐出符合氛围的壁纸，并以轻交互的预览方式展示。这个变化让产品的功能内核发生了根本性变化——从“静态内容浏览工具”变成了“音乐视觉化的创作工具”。

在工程实现上，我们用 Swift 重新制作了全部代码，底层音频分析部分用 Objective-C 实现，搭配一段 C++ 的 DSP 模块。整个工程和旧代码没有任何文件级别的重复。UI 保留了“先选择音乐、再生成推荐”的核心流程，没有出现任何旧版壁纸分类列表的影子。元数据里，主标题改为“音乐壁纸生成器”，副标题突出“节拍驱动视觉画面”，截图改为最能体现音乐分析的界面。同时，我们建立了全新的品牌识别：从图标、引导页到设置页的加载动画都重新绘制了，让用户（和审核员）打开 App 的每一秒都能感受到这是一个“初来乍到”的新面孔。

这次提审前，我们在 Review Notes 里提供了两个测试账号：一个是普通用户账号，用于体验音乐推荐功能；另一个是带了完整离线素材的 VIP 账号，用于验证壁纸下载和导出功能。审核在三天后通过了。没有附带任何条件，也没有进一步询问。A同学后来跟我说，他最大的体会就是：“我是在做一款新产品，而不是在救一个旧产品。”这句话，我觉得值得每一个被 4.3(a) 困扰的开发者刻在工位上。

老实讲，我仍然不建议每个人都采用“全新代码”这种高成本方案去对抗审核。但如果你的产品真的被判定为重复，你又坚信自己的产品有价值，那“全新代码”配合产品差异化改造，就是目前最可靠的一条路。只是要记住，代码是沉默的，审核员是直观的。你要用最终呈现出来的“产品状态”说服他们，而不是用 Git 提交记录里成千上万行的新增代码去辩论。