不止一次有出海团队拿着被驳回的订阅页截图来找我看，第一反应几乎都是同一句：这页面不是挺清楚的吗？点进去价格写着了，试用也写了，怎么会不过。真把订阅流程从用户第一次看到入口，到点下购买、到期扣费、想取消为止，逐帧拆一遍，问题通常一大把：价格只写了月付金额没写计费周期，试用期结束后的价格被折叠在二级页面里，取消入口在应用内根本找不到，促销价的"仅限首期"藏在很小的灰字里。这些都不是审美问题，而是Google Play 订阅透明度要求直接对应的审核判定点。这篇内容想讲清楚三件事：这套透明度要求究竟在管哪些信息、每个信息该用什么样的口径展示、以及在工程上怎么保证展示出去的内容和实际扣费完全一致。适合正在做订阅变现的出海产品负责人、客户端开发、以及要签字过审的合规同学看，基础版和进阶版的内容我都会拆开写。
1. 透明度条款到底在管什么：从"用户知情"到"可核验的界面证据"
很多人对订阅透明度的理解停留在"别骗用户"这个层面，觉得只要没写假话就没事。实际执行下来，这套要求的落点比"不撒谎"要硬得多——它要求你在用户做出付费决策的那一刻，把影响他钱包走向的所有变量摆在明面上，并且这些变量必须能被审核方在不需要注册、不需要付费的前提下看到。理解这一点，后面的所有设计取舍才有依据。
1.1 判定逻辑：审核看的是"决策前的可见性"，不是"事后的可查性"
这是最容易踩偏的地方。团队经常说：用户付完钱在账户里能看到详细账单，邮件里也有收据，怎么会不透明。问题在于审核关注的时点是购买按钮被点击之前的那几秒。收据、账单、账户页属于事后信息，不能替代购买前的披露。
我一般会用一个简单的检验方法：把订阅页截一张图，假设自己是一个从没听说过这个产品的人，只看这张图，能不能回答下面五个问题——多少钱、多久扣一次、什么时候开始扣、怎么取消、取消后还剩多少权益。五个问题里任何一个答不上来，这张图就不合格。这个方法看起来很土，但它对应的正是审核员的实际视角：他们看的就是你的商店素材截图和应用内首屏，而不是你的后端数据库。
顺带说一个反直觉的点：披露的完整性要求和你把页面做得多漂亮没有关系。我见过把订阅页做成杂志封面的设计，视觉上极精致，但价格被放在最底部的小字区，一样被打回。信息的显著性与信息的完整性是两个独立维度，前者决定了它会不会被看到，后者决定了它是否说得全，两个都得过。
1.2 三类被重点盯防的"信息隐藏"手法
从实际驳回反馈里归纳，被判定为不透明的手法集中在三类，值得单独拿出来对照自查。
第一类是层级下压。把关键条款放到"服务条款""用户协议"的外链里，或者藏在一个默认折叠的"更多说明"下面。政策的判断标准很朴素：如果这条信息会影响用户是否掏钱，它就不能比价格本身低一个层级。计费周期、自动续订、试用期结束后的价格，这三条属于必须和价格同层级展示的信息。
第二类是视觉弱化。用极低对比度的字体颜色、小于正文两号的字号、在深色背景上用深灰字，或者在价格旁边堆大量装饰元素做干扰。这类做法在 A/B 测试里往往能提升转化，因为用户确实更容易忽略条款，但这正是它被禁止的原因。
第三类是路径阻断。包括取消入口只在应用外的商店页面提供、应用内的取消按钮被埋到四层设置里、点击取消后弹出连环挽留弹窗且关闭按钮做成难以识别的图标。用户能取消和用户能轻松找到取消入口，在这套要求里是两码事。
提示：做设计评审时，把"这条信息如果被用户忽略，他会不会多付钱"作为判断标准。答案是"会"的，就必须做到和价格同层级、同字号量级、足够对比度的展示。
1.3 透明度要求和转化率之间的真实冲突有多大
聊这个是因为大多数团队的抵触情绪其实来自业务指标：把条款写清楚，转化率会掉。这个担心不是没有依据，但幅度被高估了。
我自己跟过的几次改版里，把试用期结束价格从折叠区提到按钮正下方、把计费周期写进价格行内，短期转化确实有下滑，但退订率和首期扣费后的差评率同时下降，净留存反而是改善的。原因不复杂：信息不全带来的付费用户，很多会在第一次扣费时就流失，并且留下差评，这个成本比少几个转化要高得多。透明度不是单纯的成本项，它在过滤低质量用户。
真正会大幅砸转化的不是"披露"，而是"披露的方式"。把条款做成一大段灰色小字堆在按钮下面，用户会感到压迫；把"首期 ¥XX，之后 ¥YY/月，可随时取消"压成一行清晰的副标题，用户的感受是专业和可信。同样的信息量，排版方式不同，转化差距可以很大。
2. 订阅页面的六类必披露信息与各自的展示口径
信息清单本身不算长，难的是每类信息的"口径"——同一个事实有多种写法，哪种写法算合格，直接决定了会不会被驳回。这一节我按自己梳理的自查顺序展开，从最容易出错的价格类信息开始。
2.1 价格、周期与自动续订：三个必须同框的元素
价格、计费周期、自动续订属性，这三者在政策视角里是一个不可拆分的组合。只写"¥28"不写周期，等于什么都没说；写了"¥28/月"但不说明这是自动续订，用户会以为是一次性购买。
合格的写法通常是这种形态：¥28.00 / 月，自动续订，可随时取消。注意几个细节：
- 货币符号和金额必须来自商店返回的格式化价格，不能自己拼接。不同地区的货币符号位置、小数位数、千分位规则都不一样，手拼一定会错。
- 周期要用用户的语言写，不要写"30 天计费周期"这种技术表述，写"每月"。
- 自动续订要用明确的动词性表述，"自动续订"比"订阅服务"清楚得多。
还有一个容易被忽略的点：如果你的产品提供多个周期档位（周、月、年），每个档位都必须自带完整的三元组信息。不能只在默认选中的档位上写周期，其他档位靠用户自己推断。
2.2 免费试用：必须写清"何时开始扣费"和"扣多少"
免费试用是透明度问题的高发区，因为它天然包含一个时间差和一个金额跳变。合规的试用披露至少要包含四个元素：试用时长、试用结束后的准确价格、试用转付费是自动发生的、以及取消的截止时点。
我见过最典型的错误写法是按钮上只写"免费试用"，页面上没有任何"7 天后自动按 ¥28/月 续订"的说明。这种写法在转化数据上确实好看，但驳回率极高。
另一种隐蔽的错误是把试用期和首个计费周期混为一谈。比如"3 天免费，然后 ¥28/月"，如果实际实现是第 3 天扣 ¥28 并进入一个完整月周期，那没问题；但如果实际实现是第 3 天扣 ¥28 且该月周期从第 1 天开始算（也就是用户实际只享受了 3 天却付了整月），这就是实质性差异，必须如实披露。
注意：试用期的取消截止时点建议写具体，比如"在试用期结束前 24 小时取消可避免扣费"。写具体时间点比写"及时取消"要稳妥，也更能减少后续的退款申诉。
2.3 优惠与促销价：标注"仅限首期"是硬要求
促销价的透明度核心在于边界。用户看到 ¥9.9 的时候，脑子里默认的是"每月 9.9"，如果实际只有第一期是 9.9、第二期恢复 ¥28，这个差额必须被明确标注。
合格的形态是把两段价格同时呈现：首期 ¥9.9，之后 ¥28.00/月，并且两段的价格来源都应该是商店返回的分期价格数据，而不是硬编码。分期价格数据在商品详情里是按 pricing phases 组织的，直接按顺序渲染就能保证展示和实际扣费一致。
这里有个工程上的坑值得提前说：促销活动结束、价格恢复的那一刻，如果应用内缓存了旧的商品信息而没有刷新，页面上可能还显示着 ¥9.9。这种情况在有服务端下发配置的架构里尤其容易出现。我的建议是价格信息永远以商店查询结果为准，配置中心只下发"展示哪几个 SKU"，不下发"多少钱"。
2.4 取消方式与订阅管理入口：必须能在应用内到达
这一条被误判的概率很高，因为很多团队认为"商店里本来就能取消，为什么还要在应用内做入口"。政策的落点不是"用户能不能取消"，而是"用户在订阅关系存续期间，能不能在应用内找到通往订阅管理的路径"。
实现上不复杂：在应用的账户页或会员页放一个"管理订阅"的入口，点击后跳转到商店的订阅管理页面。跳转失败（比如设备上没有商店客户端）时要有兜底文案，告诉用户可以去哪里操作，而不是点了没反应。
同时，取消流程里不要设置强制性障碍。可以有挽留，但不能是"必须看完三段视频才能取消"或者"关闭按钮做成 1 像素"这种。挽留弹窗本身是允许的，前提是关闭路径清晰、一步可达。
2.5 权益范围与有效期：说清"买了能得到什么、多久"
价格说得再清楚，如果用户不知道自己买的是什么，一样算不透明。这部分要求披露的是订阅包含的权益内容、权益的有效期、以及订阅到期或取消后权益如何处理。
具体到写法上，建议在价格区块下方用短句列出核心权益，2 到 4 条即可，不要写成产品说明书。同时明确一句"取消后权益保留至当前计费周期结束"，这句话能挡掉大量关于"取消就立刻断权益"的误解和差评。
2.6 隐私与条款链接：位置比内容更容易出问题
服务条款和隐私政策的链接属于基础设施，但位置有讲究。常见的不合格做法是把它们放在页面最底部、需要滚动才能看到的位置，或者做成纯文字不可点击。合格做法是在购买按钮附近的固定区域提供可点击的链接，点击后能正常打开（不能是空白页或者 404）。
这里有个细节：链接打开后如果是应用内 WebView，要确保这个 WebView 里的页面是真实可访问的、加载完成的。我遇到过因为域名配置错误导致审核时打开是空白页的情况，这种问题在自己测试时很容易漏掉，因为开发者本机的网络环境和审核环境不一定一致。
3. 把商品数据接对：Billing 查询链路里的价格披露实现
前面讲的都是"该展示什么"，这一节讲"数据从哪来"。透明度要求能落地的前提是：你展示的每一个价格数字，都必须可以追溯到商店返回的权威数据。这一节的代码示例以 Kotlin 为主，同时会讲服务端侧的配合点。
3.1 查询商品详情时最容易丢掉的字段
订阅商品的价格不是单一字段，而是一个分期结构。很多实现只取了第一期的格式化价格，结果在促销场景下展示成了"¥9.9/月"，和实际扣费完全不符。
正确的做法是把所有的 pricing phase 都取出来，按顺序渲染。下面的示例演示了从商品详情里提取分期信息的思路：
// 伪代码式的结构说明，具体 API 名称以所用版本为准 val details = productDetailsList.firstOrNull { it.productId == "sub_premium_monthly" } val offer = details?.subscriptionOfferDetails?.firstOrNull() offer?.pricingPhases?.pricingPhaseList?.forEachIndexed { index, phase -> // phase.formattedPrice 是商店已经本地化好的价格字符串 // phase.billingPeriod 形如 P1M / P1Y / P1W // phase.billingCycleCount 表示该分期重复次数 val label = when { phase.priceAmountMicros == 0L -> "免费试用 ${humanizePeriod(phase.billingPeriod)}" index == 0 && offer.pricingPhaseList.size > 1 -> "首期 ${phase.formattedPrice}" else -> "${phase.formattedPrice} / ${humanizePeriod(phase.billingPeriod)}" } priceLines.add(label) }这里的关键点有三个。formattedPrice必须直接用，不要自己拿priceAmountMicros除以一百万再拼货币符号，否则会被税、货币格式、地区差异坑到。billingPeriod是 ISO 8601 时长格式，需要自己映射成用户能懂的中文表述。priceAmountMicros为 0 且排在第一位的分期，就是免费试用期，要单独识别出来做文案。
一个常见失误是在免费的试用期出现在分期列表里时，直接把它渲染成"¥0.00"，用户体验很怪，也容易被判定为披露不清。要把它转成明确的"免费试用 X 天"。
3.2 版本升级带来的 API 差异，别在发版前才发现
Billing 客户端库在近几个大版本里对查询接口做了调整，返回结构有变化。这意味着你在旧版本上写得很好的一段查询代码，升到新版本后可能编译不过或者取不到字段。
我在升级时踩过的坑主要集中在两处：一是查询商品详情的返回从"直接给列表"变成了"包一层结果对象"，如果在回调里直接解构列表就会出错；二是档位选择相关的接口从"传入旧版档位参数"改成"传入带标签的档位对象"，优惠信息的获取路径也跟着变了。
处理办法很直接：把商品查询封装在一个薄适配层里，对外只暴露一个统一的数据结构（包含价格行、周期、试用天数、优惠标识），上层 UI 只依赖这个结构。这样库版本升级时只需要改适配层，不会波及整个订阅页。这个封装多花半天时间，后面每次升级能省掉好几天的排查。
3.3 服务端校验与通知：让"展示的价格"和"实际扣费"可对账
客户端展示是一侧，服务端拿到的实际交易是另一侧，两侧必须能对上。具体做法是在用户完成购买后，把购买凭证送到服务端做校验，服务端从权威渠道取回交易详情后再决定是否发货。这一步的意义不只是防作弊，也是透明度要求的技术兜底——如果客户端展示有 bug，服务端的实际扣费数据可以帮助你发现问题。
更进一步，建议接入订阅状态的实时通知机制。用户取消、续订失败、进入宽限期、账户保留等状态变化，都会通过通知推到你的服务端。这些状态直接决定了你在应用内该怎么展示用户的订阅状态。如果用户已经取消了，你的应用里还显示"订阅中，将于下月续费"，这就属于状态披露错误，同样是透明度问题。
一个简化的处理流程可以是：
收到通知 -> 从通知里取购买令牌 -> 调权威接口查当前状态 -> 更新本地订阅表（状态、到期时间、是否自动续订） -> 记录事件用于后续对账和退款处理这里我特别想强调宽限期和账户保留这两个状态。宽限期是指扣费失败但用户仍保留权益的缓冲期，账户保留是指更长时间扣费失败后的状态。这两个状态下用户看到什么、能不能继续用、界面怎么提示，都必须和实际状态一致。很多团队只处理"成功"和"取消"两种状态，中间态全部当作成功，结果用户以为还在订阅，实际已经被扣费失败进入保留了。
3.4 本地化：不只是翻译，是货币和格式的重新计算
出海产品的订阅页一定涉及本地化，而本地化最容易出错的地方就是价格。商店返回的formattedPrice本身就是按用户所在地区格式化好的，直接显示即可，但有几件事需要自己处理。
货币符号的位置和是否使用小数点，各地区的习惯不同，这是格式化层帮你解决的。需要自己确认的是价格是否含税的表述。部分地区要求标价必须含税，部分地区允许标价不含税但必须注明税费在结算时另计。这个差异不是技术问题，是法务问题，我的建议是找目标市场的本地合规顾问确认一遍，不要靠自己推断。
另一个是周期表述的本地化。"每月"在中文语境里很清楚，但翻成某些语言时，"per month"和"monthly"在合同语境下的严谨程度不同。这类文案最好交给本地母语者过一遍，机器翻译出来的条款文案在审核时经常被判为"表述不清"。
4. 试用、优惠价、升降级：三条最容易翻车的特殊计费路径
基础订阅的披露相对简单，真正出问题的是这三条特殊路径。它们的共同特征是"价格在时间轴上会变"，而用户看到的往往是某一个时间点的静态价格。
4.1 免费试用的取消时点与扣费预告
试用期最核心的矛盾是：用户以为自己在"白嫖"，而系统在倒计时。透明度要求解决的就是这个信息不对称。
合格的实现应该做到三件事。第一，在试用期开始时就明确告诉用户到期时间，最好精确到日期。第二，在试用期即将结束前主动提醒，这个提醒不是政策强制要求的（各平台要求不同，以官方最新文档为准），但对降低退款率非常有效。第三，提供随时可查的"我的订阅"页面，显示当前处于试用期、剩余天数、到期后价格。
一个技术细节：试用期的起算时间是按服务端确认的交易时间，不是客户端点击购买的时间。中间的网络延迟、支付确认延迟都会造成偏差。展示给用户的日期建议从服务端返回的数据计算，不要用本地时间加天数硬算。
4.2 促销价的分期展示与"优惠结束后"提示
促销的披露难点在于分期结构可能在客户端被简化掉。前面代码部分提到过按分期渲染，这里补充业务侧的注意事项。
促销活动通常是有时效的，活动结束后新用户看到的就是原价。这里有一个容易被忽略的合规点：如果用户在促销期内订阅，后续续费恢复原价，这个恢复动作要在订阅页和后续的通知里都说清楚。不能只在购买前说一次，然后就再也不提。
另一个坑是促销叠加。如果产品同时有"首期折扣"和"推荐好友得优惠"这类机制，两个优惠同时生效时的实际扣费金额可能和订阅页展示的不一致。这种情况我建议在订阅页明确说明"其他优惠可能导致实际扣费金额不同，以结算页为准"，把不确定性交代出去，而不是假装它不存在。
4.3 升降级的差价计算与即时生效问题
多档位订阅的产品一定会遇到升降级。用户在"基础版"想升到"高级版"，这里涉及两个披露点：差价怎么算、什么时候生效。
不同的升级策略会导致完全不同的扣费结果。有的是立即升级并按剩余时间折算差价，有的是立即升级并全额收取新周期费用，还有的是等到下个周期才生效。这三种策略都合规，但必须在界面上说清楚是哪一种。用户点下"升级"按钮前，应该能看到"本次将立即扣费 ¥XX，新周期自今日起算"这样的明确提示。
降级则更敏感，因为涉及权益减少的时点。多数实现是"降级在当前周期结束后生效，当前周期内保留高级权益"，这个逻辑对用户是友好的，但如果不写清楚，用户会以为点了降级就立刻失去权益，反而不敢操作。
下面这张表可以贴在订阅页设计评审的会议室里，作为特殊路径的对照清单：
| 计费路径 | 必须披露的内容 | 常见错误 |
|---|---|---|
| 免费试用 | 试用时长、结束日期、结束后价格、取消截止时点 | 只写"免费试用"，按钮上无后续价格 |
| 首期优惠 | 首期价格、恢复价格、恢复时点 | 只展示首期价格，恢复价藏在折叠区 |
| 升级 | 差价金额、生效时点、新周期起算日 | 只写"升级"，不写扣费和生效规则 |
| 降级 | 生效时点、当前周期权益是否保留 | 未说明权益保留，用户误以为立即失效 |
| 周期切换 | 新旧周期的折算方式、下次扣费日期 | 折算规则不透明，扣费金额与预期不符 |
5. 驳回复盘：五类真实高频问题与逐层排查顺序
收到驳回通知的时候，最没效率的做法是凭感觉改。有效的做法是建立一套固定的排查顺序，从最外层开始往内收。这一节我按自己常用的顺序讲，同时把每类问题背后的成因说清楚。
5.1 第一层：商店素材与实际应用是否一致
很多团队把精力全放在应用内的订阅页，忽略了商店商品页的截图和描述。审核的第一眼其实是商店页面，如果商店截图里写的是"全部功能免费"，而应用内是订阅制，这就直接构成不一致。
排查动作很具体：把商店页的每一张截图、每一段描述文案、每一行短描述都拿出来，问一句"这句话会不会让用户以为某个付费功能是免费的"。有歧义的一律改掉。特别是那些用"免费下载""免费使用"做卖点的文案，要补上"含应用内订阅"的说明。
5.2 第二层：订阅页首屏能否独立回答问题
第二层是应用内的订阅页首屏。前面提到的"五个问题"检验法在这一层用。具体操作是把首屏截图打印出来，让一个不了解产品的人看，看他能不能说出价格、周期、何时扣费、怎么取消。
这一层出问题的典型表现是信息分散：价格在顶部、周期在中间、取消说明在底部、试用条款在弹窗里。信息都在，但不在同一个视野内。解决办法是做信息聚合，把核心四要素压到价格区块内，其余说明可以放在下方，但核心四要素必须同屏。
5.3 第三层：点击路径上的每一个节点是否有死路
这一层是纯工程排查，需要真的走一遍完整流程。我建议用一台干净的设备，装一个没有测试账号的普通账号，从下载安装开始，完整走一遍：浏览、点订阅、进结算页、完成购买、查看订阅状态、找到管理入口、执行取消、确认取消结果。
每一步都可能藏问题。我遇到过的情况包括：管理订阅的入口点击后跳转到一个不存在的页面、取消后应用内状态没有刷新还是显示"订阅中"、试用期用户点取消后弹出"取消将立即失去权益"的错误提示。这些都属于披露或状态错误。
排查时建议做一个路径清单，逐项打勾：
- 订阅页价格、周期、自动续订三项是否同屏可见
- 试用相关文案是否包含结束日期与后续价格
- 购买按钮文案是否与实际行为一致（不能写"继续"但实际是扣费）
- 购买完成后应用内状态是否立即更新
- 管理订阅入口是否可达、跳转是否成功
- 取消流程是否一步可达、无强制阻断
- 取消后应用内权益展示是否与剩余周期一致
- 网络异常、支付失败等情况的兜底文案是否清晰
5.4 第四层：数据一致性，展示的和扣费的是不是同一个数
前三层都是"看得见"的问题，第四层是"看不见"的。做法是对着商店后台配置的商品价格，逐条和你应用内展示的价格做比对。特别注意促销配置：后台配了首期折扣，应用内是不是也展示了分期；后台的促销活动结束了，应用内的缓存是不是也更新了。
这一层最容易出的问题是缓存。客户端为了减少查询次数，经常把商品详情缓存一段时间，结果促销结束后仍然展示旧价格。解决办法是设置合理的缓存过期时间，并且在进入订阅页时强制刷新一次。
5.5 第五层：本地化市场的一致性抽查
最后一层是针对出海产品的。不同地区的审核团队看到的界面不一样，可能出现"英文版没问题、某个小语种版本有问题"的情况。抽查方法是至少选三个主要目标市场，切换语言和地区后各走一遍订阅流程，重点看价格格式、周期表述、条款文案。
小语种版本出问题很常见，因为文案通常是最后才补的，翻译质量参差不齐。我建议把订阅相关的所有文案单独抽成一份清单，交付翻译时附上上下文说明，避免出现"Monthly"被翻成名词形式、在句子里读起来像"月度"这种让用户困惑的表述。
6. 面向 2026 的版本节奏与长期合规机制
订阅透明度的要求不是一次性通过的考试，它是持续生效的。平台的计费库版本、政策条款、目标系统的适配要求都在按节奏更新，靠每次驳回再救火的团队，成本会越来越高。这一节讲怎么把它变成常态机制。
6.1 把版本升级排进季度节奏，而不是等强制截止
计费库的版本要求通常会有一个明确的截止时间，过了时间就无法提交更新。真正麻烦的不是升级本身，而是升级带来的连锁改动：查询接口变了、优惠信息的获取方式变了、某些旧字段被移除。
我的建议是提前一到两个季度开始升级，而不是卡在截止前一个月。原因是订阅相关的改动测试成本高，需要覆盖真实支付、试用、取消、续订、退款等多条路径，而这些路径在测试环境里的复现并不总是稳定。留出充足的测试窗口比赶工重要。
升级的推进顺序可以是：先在分支上升级依赖、修编译错误、跑通基础购买流程，再逐条覆盖特殊路径（试用、促销、升降级），最后做一轮完整的价格展示比对。这个顺序能保证每一步的问题范围是可控的。
6.2 建立"订阅条款单一事实源"
透明度问题的根源往往是信息分散：文案在运营手里、价格在商品后台、逻辑在客户端代码里、条款在法务文档里。四处各改各的，迟早对不上。
比较有效的做法是建立一个订阅配置的单一事实源，把所有和订阅有关的关键信息集中管理：SKU 标识、展示名称、周期、权益列表、试用配置、条款链接、取消说明文案。客户端和服务端都从这里读取，商品价格仍然以商店返回为准，但"展示哪几个 SKU、每个 SKU 配哪段权益文案"由这个源决定。
这样做的好处是，当你要改一句取消说明的文案时，不需要在三个地方分别改，也不会出现某些页面改了、某些页面没改的情况。评审时也可以直接对着这个源做清单式核对。
6.3 用自动化测试守住价格展示的底线
价格展示的正确性是可以被自动化验证的。做法是把"商品详情查询结果"和"最终渲染出来的文案"之间的映射逻辑抽出来，做成纯函数，然后用固定的输入做单元测试。
比如输入一个包含免费试用期和一期折扣的分期结构，期望输出是"免费试用 7 天，之后 ¥28.00/月"这样的固定文案。这样一来，任何改动渲染逻辑的代码提交都会被测试拦住。这类测试写起来不复杂，但能挡掉相当一部分回归问题。
下面是一个测试用例的组织思路：
用例1：单期原价 -> 期望 "¥28.00 / 月，自动续订" 用例2：免费试用 + 单期原价 -> 期望 "免费试用 7 天，之后 ¥28.00 / 月" 用例3：首期折扣 + 单期原价 -> 期望 "首期 ¥9.90，之后 ¥28.00 / 月" 用例4：多年期 -> 期望 "¥288.00 / 年，自动续订" 用例5：价格字段为空 -> 期望 展示兜底文案而非崩溃用例 5 特别值得加上。商品配置错误、查询失败、网络异常的情况下，订阅页不能白屏或者显示"¥0.00"，必须有明确的兜底文案并把购买按钮置灰。这类兜底在审核环境里出现的概率比在自己测试环境高，因为审核账号可能无法正常拉取到你配置的全部商品。
提示：所有和钱相关的界面元素，都按"最坏情况"设计兜底。查不到价格时不能默认显示一个数字，宁可不显示购买按钮。
6.4 保留可追溯的版本记录
最后一点偏管理，但对持续合规很有用：把每次订阅页的变更、每次条款文案的调整、每次商品价格的修改都记录下来，保留截图和配置快照。原因有两个，一是出现争议时可以回溯当时展示的是什么，二是团队人员变动时，后来者能快速知道当前版本为什么长这样。
这个东西不需要什么复杂工具，一个共享文档按月记录就够用。真正麻烦的是完全不做记录，等到某次驳回时，没人说得清半年前上线时页面到底是什么样。
我在实际操作中的几点体会
订阅合规这件事最耗人的地方在于它的琐碎——不是难，是杂。价格、周期、试用、优惠、取消、状态、本地化，每一项单独看都不复杂，但要在同一个页面上同时讲清楚、在同一个数据链路上同时保证一致，就需要有人从头到尾把这件事当成一个完整的模块来管，而不是当成运营改文案的一个附带动作。
如果只能给一条建议，我会说：先把订阅页的每个数字都变成"可追溯"的。你展示的每一个价格、每一个日期、每一个天数，都能说清楚它是从哪个接口的哪个字段来的、经过了什么换算。做到这一点，大部分透明度问题会自动消失，因为模糊的地方本来就是不一致的地方。剩下的才是排版和文案的功夫，而这部分恰恰是最容易打磨好的。
