平台要清理一类存量应用，先动的不是开发而是台账｜洹拓科技
一、判定线在平台手里，所以受影响方第一步是台账
一条平台规则的更新被公开讨论：某应用商店准备移除长期未更新、或无法吸引用户的某几类应用，举例是手电筒、壁纸、音效、简单计时器这一类。这里要先分清，规则针对的不是新应用的提交审核，而是已经躺在商店里的存量资产，两者是完全不同的两件事，也是完全不同的一套工程。这类清理真正的难点在判定线：什么算“长期未更新”、什么算“无法吸引用户”，用的都是平台侧的指标而不是开发侧的指标，阈值和执行节奏也不由我们掌握。既然判定线在别人手里，受影响方要做的第一件事就不是改代码去迎合，而是先把自己的存量摸清楚，也就是建台账。这里有个常被忽视的错位：开发侧习惯盯的是崩溃率、启动时长这类自己说了算的指标，而清理用的却是平台侧的活跃度与更新时点，两套口径根本不是一回事，拿开发仪表盘去推断自己会不会被清理，几乎必然误判。我们不去评论这条规则本身，要处理的是它落到我们账上的后果。
二、受影响方要立刻建的四张表
台账不是一张表列个应用名就完事，至少要拆成四张，各自回答一个不同的问题。
| 表 | 关键字段 | 回答的问题 |
|---|---|---|
| 存量清单 | 应用、上架时间、末次更新、当前可下载状态、依赖的账号与证书 | 我们到底还有多少个挂着的壳子 |
| 责任人表 | 每个应用对应的在职责任人 | 通知来了有没有人能接得住 |
| 资产关联表 | 牵连的内购、订阅、广告位、后端服务与推送凭据 | 动一个会不会牵出一串 |
| 退出成本表 | 数据能否导出、用户如何迁移、剩下的合同与合规义务 | 真要下架时退得起吗 |
四张里最容易被漏的是责任人表：一个应用如果没有明确的在职责任人，平台的通知发过来就没人处理，等到被清理了才发现它是某个人离职前顺手挂上去的。资产关联表则决定了后面所有动作的风险半径，因为一个应用从来不是孤立存在的，它背后连着账号、证书和一堆服务。这四张表也不是建一次就放着：存量清单和责任人表要随人员与包的变动更新，资产关联表尤其要在每次接入或关停后端时回写，否则关键一栏一旦过期，后面所有判断都建立在一张旧关系图上。
三、两条判定线各自怎么守
对“长期未更新”这一条，我们分三层应对。
- 技术上，主动做一次最小维护提交：把目标系统版本和安全补丁升上去，让末次更新时间刷新过去。要说清楚，这不是绕过规则，而是维持可用性的正常动作，一个还在给用户提供服务的壳子本来就该保持维护。这次提交本身要尽量小、可回滚，只动编译目标、依赖版本和安全修补，不夹带功能改动，免得为了刷新一个时间反而引入新的稳定性风险。
- 内容上，把已经停运的入口清理干净：内嵌的活动页、指向已下线服务的按钮、失效的登录方式，这些留着既误导用户，也会在复核时变成扣分项。
- 策略上，把不再投入的应用明确转入“仅维护”档，对外不再推荐，只在内部登记它处于维护状态。
对“无法吸引用户”这一条，有两条底线不能破。
- 不要把活跃度指标当成唯一理由，而要把应用的价值场景说清楚：商店描述、截图和首次启动引导，都在实打实地影响转化，这些是开发侧能改、也该改的部分。
- 不要为了留存去做诱导点击和强制通知：这类行为在这条规则之外的别处同样受约束，靠它把活跃度拉上去，是按了葫芦起了瓢。
四、下架不是删除，要交付六件事
如果某个应用确实要退出，请记住下架不等于把它从商店撤掉就结束，它是一次有对象的交付。下面六件事要成文、要有时间点。
- 用户数据处置说明：这些数据结构怎么处理，用户还能不能拿回。
- 订阅与自动续费的提前退订安排：谁在扣费、什么时候停、怎么提前通知。
- 后端服务关停顺序与时间：先关哪个、后关哪个，不能一刀切把还在被调用的接口先停掉。
- 已收集个人信息的留存与删除：留多久、到期怎么删、由谁负责执行。
- 可导出的历史记录格式：给用户留一个能把数据带走的口子。
- 一个持续可达的客服或申诉入口：下架之后一段时间内还得找得到人。
这六件里第四件和第六件最容易在事后变成纠纷，因为用户不问规则、只问我的东西去哪了、我遇事找谁说。补一句，时间点不必写死到某一天，但顺序不能乱：先给用户留出退订和导出的窗口，再谈后端关停，最后才是把入口撤下，反过来就会把还在用的人晾在半路。
五、两类连坐事故，靠变更影响图来防
存量清理最容易出的不是单个应用下架，而是连带事故，常见的有两类。一类是共享账号被一起注销，导致挂在同一账号下的其余应用连坐，一夜之间全部无法更新。另一类是旧版本依赖的接口先被关停，结果在线的老版本用户打开就报错。这两类的共同根源，是把应用当成孤立个体来处置，而没有看见它们之间共享的账号、证书和后端。防法是把前面那张资产关联表往前再推一步，画成一张变更影响图，并为每一次关停单独排一张顺序表：先确认哪些东西被别人依赖，再决定停不停、什么时候停。有了影响图和顺序表，才不至于为了清一个僵尸应用，误伤一批还在服务真实用户的应用。
六、形态越多，越要像管依赖一样管形态清单
给做 SaaS 与小程序的团队一条迁移启发：你的上架形态越多，原生应用、小程序、桌面快捷方式、浏览器插件各算一种，平台规则变更时的影响面就越难预判，因为每一种形态各受一套规则约束。所以形态清单要像代码里的依赖清单那样维护：登记每一种形态挂在哪个平台、由哪个主体提交、绑了哪些凭据，规则一变就能按图排查，而不是临时翻箱倒柜。清单里每一种形态都要记上提交主体与所绑凭据，这样当某个主体或凭据出问题时，能立刻反查它牵连了哪些形态，而不是等通知来了才一家家去翻。
最后是一条制度建议，也是洹拓自己每年都做的一件事：给全部存量做一次体检，按“继续投入、仅维护、准备退出”三档归类，并给每一档定清楚动作和时间。留在投入档的走正常发布，落到仅维护档的只做安全更新、不再对外推荐，进了准备退出档的提前把第四节那六件交付备好。把这件事做成一年一次的固定动作，比等着平台替你分类要主动得多；分类权一旦不在你手里，节奏就只能跟着别人的判定线走。