不想取消，能不能先暂停？vibe 项目的订阅暂停与恢复实战

一张“先停两个月”的纸条，值多少钱？先讲一个虚构的教训

先讲一个虚构的教学例子。阿远一个人用 AI 搭了个笔记应用“云杉笔记”，分三个档：免费档、30 元一个月的基础档、90 元一个月的专业档。上线第四个月，他收到一封用户来信：“最近手头紧，能不能先停两个月？我不是不用了，就是这俩月实在顾不上。”阿远去后台看了一眼：取消订阅的按钮明晃晃地摆在那儿，暂停的入口根本不存在。他只好回信说：那你先取消吧，想回来的时候再订阅。

用户取消了。两个月后他真回来了，却发现三件事全变了：第一，旧账号里存的 200 多条笔记只剩免费档能看的 50 条，剩下的被锁住了；第二，重新订阅要按新价 110 元算，他原来 90 元的老价格没了；第三，他得重新绑卡、重新设置、重新找回原来的工作区，折腾了半小时才回到起点。他在群里吐槽了一句：“想歇两个月，结果跟注销了差不多。”

这封信暴露的不是一个按钮缺失，而是一整条链路没想清楚：用户说“暂停”的时候，他真正想要的是三件事——这俩月别扣我的钱、我的东西别动、回来的时候一切照旧。而阿远给的“取消”三件全反着来：钱是不扣了，可东西锁了、价格涨了、回来还得从头再来。用户不是流失了，他是被亲手推出去的。

本文讲的就是怎么把“暂停”这条路修好：暂停、降级、取消三条路怎么分、什么用户值得给暂停入口；计费到底怎么停才不算错账；暂停那几个月用户还能干什么、数据怎么办；恢复那一刻最容易翻车的三个点；最后是一套从原因收集到恢复触达的挽留漏斗，和一份上线前逐项打钩的检查清单。本文所有例子里的人名、产品名和数字都是虚构的教学例子，只用来把道理讲清楚；文中的天数、金额和比例都是工程经验建议，不是哪个官方标准，照着用之前先按你自己的定价表和支付平台的最新文档验算一遍。

先划界：这篇只管“暂停”，不管另外五件事

动手之前先把范围划清楚，全站订阅类指南已经有两篇写在前面了，本文是第三块拼图，不重复它们讲过的事。第一篇是 cycle162 的《订阅续费失败挽回》，讲的是扣款已经失败之后怎么办：卡里没钱、银行拒付、重试几次、什么时候发提醒，那是用户想留、钱没扣成的被动局面。第二篇是 cycle163 的《订阅升降级按比例计费》，讲的是用户在一个计费周期没走完的时候换档，这期剩下的钱按天怎么算。本文讲的是第三种局面：用户主动说“我想歇一阵”，钱还没出问题，人也没想走，只是要按一下暂停键。

还有四件看着像、其实不是这篇的事。第一，取消流程与挽留：用户已经决定走，取消页上怎么留人、怎么给最后一次优惠，那是取消挽留的活，本文只管用户还没走到取消那一步。第二，试用到期降级：14 天试用结束自动回到免费档，涉及的是试用到期提醒和降级时机，另一篇指南讲过。第三，流失召回：用户已经走了三个月，怎么发邮件把他请回来，那是召回的活；暂停是流失之前的主动留存，时间点完全不一样。第四，积分账本：用户账户里剩的点数、充值余额怎么抵扣，那是余额的算法，与暂停期间收不收钱是两回事。

划界的意义很实际：暂停、取消、降级、召回，四个动作在数据库里可能只差一个状态字段，但在用户心里是四种完全不同的意思。混在一起写，代码里一个 if 分支都写不清楚，用户在界面上也分不清自己到底点了什么。先把“暂停”这一个场景想透、做对，再去管边上的事。

一、暂停不是取消：三选一，先问用户到底想干什么

用户点开“管理订阅”的时候，心里通常只有一句话：“这个月不想交钱了。”但这句话背后至少有三种完全不同的意思，产品要做的第一件事，是把这三种意思分开，而不是一股脑全推向取消。

第一种是“暂时不用”。出差三个月、项目告一段落、暑假带孩子，手头的事停了，订阅跟着停。这类用户最典型的一句话是“过两个月就回来”。第二种是“暂时付不起”。手头紧、预算被砍、等下个月发工资，东西还想用，钱想缓一缓。第三种才是“真的不想用了”：功能不对路、找到了替代品、需求本身消失了。这三种人走进同一个取消页，结局应该完全不一样：第一种给暂停，第二种给暂停或者降档，第三种才走取消流程。

所以暂停入口不应该藏在取消流程的最末尾当“挽留彩蛋”，也不应该对所有人敞开。判断值不值得给暂停入口，有三个硬标准。第一，用户还在用吗？过去 30 天登录过、产生过内容、数据还在增长的用户，暂停的价值最大——他回来是迟早的事，拦住他别走就是赚的。已经 90 天没登录的用户，给暂停也没用，他不是要歇一歇，他是已经走了。第二，暂停期有明确的头吗？“出差三个月”“等下个季度预算”这种有明确回头时间的，暂停最划算；“不知道什么时候回来”也行，但要设一个最长暂停期，不能无限期挂着。第三，这次暂停会不会亏？月付 30 元的用户停三个月，你少收 90 元；但他如果取消后再也不回来，你丢的是他未来一年的 360 元。这笔账一算就清楚：暂停的成本是确定的、有限的，取消的损失是不确定的、无上限的。

入口长什么样也有讲究。最顺的做法是三选一放在同一页：用户点“取消订阅”，先看到三个并排的选项——暂停 1 个月、暂停 3 个月、降到免费档、取消订阅。暂停的选项要写清三句话：停多久、停的这段时间收不收钱、回来那天自动恢复还是手动恢复。别学某些产品把暂停藏在“取消原因”选完之后的第五步，用户点到第三步就烦了，直接选取消走人。暂停的选项越靠前，挽回率越高，这不是话术，是路径长短决定的。

还有两个细节容易被忽略。一是暂停时长要给选择，不要只给一个固定值。1 个月、2 个月、3 个月三个档最常见，再加一个“自定义，最长 6 个月”。时长太短用户觉得不够用，太长你自己的收入预测就没法做。二是暂停次数要设上限，比如 12 个月内最多暂停两次、累计不超过 6 个月。没有上限的暂停会被当成免费试用的续命手段：有人每三个月暂停一次，等于常年只付一半的钱。规则写在暂停页上，用户点暂停之前就看得到，事后扯皮就少一半。

二、计费怎么停才不算错账：先分清两种“暂停”

这是全文最容易写错、也最容易出事故的一节。Stripe 现在有两种暂停，名字很像，干的事完全不一样。第一种叫暂停收款（pause_collection），老办法：订阅状态还是 active，账单照常生成，只是 Stripe 不扣钱。你可以把它理解成“宽限期”——东西照常用，钱先欠着或者先免了。第二种是新版的暂停订阅（Pause subscriptions，2026 年 9 月底才正式开放）：订阅状态直接变成 paused，Stripe 停止生成账单，服务也随之停掉，恢复时再重新算账。

选哪一种，先看你想让用户在暂停期干什么。想让用户继续用、只是先不收钱，选暂停收款；想让用户停下来、连服务一起冻住，选暂停订阅。阿远的“云杉笔记”最后选了暂停订阅当默认方案，因为他的专业档是按用量计费的 AI 功能，用户停着不用还继续扣 token 额度，账根本算不清。但如果你的产品是内容库、课程、素材站，用户暂停期间看看旧内容没什么成本，暂停收款反而更体面：用户不断粮，你不断情。

先说暂停收款的三个模式，这是最容易选错的地方。Stripe 给每个暂停期生成的账单提供三种处理方式：keep_as_draft（留作草稿）、mark_uncollectible（记为无法收回）、void（作废）。keep_as_draft 的意思是账单先生成、不扣款，等恢复的时候再一张张拿出来收——用户欠你的钱还在账上，恢复那天要连本带利补上。mark_uncollectible 的意思是这期的钱你不要了，账单记为收不回来；如果用户账户里还有余额，Stripe 会先拿余额抵，抵完剩下的才记为无法收回。void 是最干净的：账单直接作废，就当这期没发生过，不留收费记录。

三种模式对应三种生意。keep_as_draft 适合“缓一缓”：用户明确说下个月就恢复，钱晚点收没关系。mark_uncollectible 适合“送人情”：用户遇到困难，你主动免一期，账上留个记录，财务也好交代。void 适合“算不清就不算”：年付用户中途暂停，剩下的月份按比例折算太麻烦，直接把暂停期的账单作废，恢复时重新起一个新周期。最常见的错是图省事全选 mark_uncollectible：用户暂停三个月，三个月账单全记无法收回，财务月底一看坏账率飙升，还以为是催收出了问题。选模式之前先问财务一句话：暂停期的钱，我们到底是“晚收”“不收”还是“当没发生”？答案不同，模式就不同。

再说 resumes_at，也就是自动恢复的时间点。暂停收款可以不填 resumes_at，那就一直停到你手动恢复；填了就是到了那个时间点自动恢复收钱。经验是：凡是用户自己点的暂停，一定要填 resumes_at，而且默认 3 个月。没有截止日的暂停是最危险的——用户忘了，系统不提醒，订阅就这么免费挂一年，最后是你自己的收入在漏水。阿远的第一版就踩过这个坑：有个用户 2026 年 3 月暂停、没设恢复日，到 11 月才发现他一直在用专业档、8 个月一分钱没付。填了 resumes_at 之后，恢复日就是一道闹钟，到点要么扣款、要么进挽回流程，总有个下文。

还有一个坑比模式选错更隐蔽：暂停收款不会把账期往后推。账单照常生成、周期照常走，暂停 20 天不等于账单日往后挪 20 天。如果你的月付用户在 1 号续费、10 号暂停、30 号恢复，他这一个月该交的钱一分没少，只是晚交或者免了——暂停省的是钱，不是时间。很多开发者以为暂停会自动顺延，结果用户暂停三个月回来一看，账单日还是原来的那天，当月只剩 5 天又要扣全月费用，当场就炸了。想让账期顺延，得手动调 current_period_end 或者 billing_cycle_anchor，这一步 Stripe 不会替你做。

暂停订阅（新版）在这件事上干脆得多：暂停那一刻，Stripe 会把当期没用完的天数折成一笔待抵扣的金额。拿“云杉笔记”算一笔：专业档 90 元一个月，用户第 15 天暂停，没用完的 15 天折成 45 元记在账上；第 45 天恢复，恢复账单是新一期 90 元减去 45 元抵扣，实收 45 元，一个新周期从恢复那天开始算。想改这个默认算法，调 bill_for 里的 unused_time_from：now 是从暂停这一刻开始算、item_current_period_start 是从周期开始算、none 是不给抵扣。这个抵扣逻辑和 cycle163 讲的按比例计费是同一条公式——补差价等于（新价减旧价）乘以剩余天数除以周期天数，只不过这里是反过来算：退的是没用完的天数。两篇指南的公式是通的，代码里最好共用同一个函数，别各写一遍。

对账是最后一道防线。暂停功能上线后，财务每月要对三张表：第一，暂停中的订阅清单——谁在停、停到哪天、用的哪个模式；第二，暂停期的账单状态——草稿有几张、无法收回有几张、作废有几张，数字要和财务口径对得上；第三，恢复日的扣款结果——自动恢复扣成了几个、失败了几个、失败的进了哪个挽回流程。最容易漏的是 keep_as_draft 的草稿账单：恢复时不会自动扣款，你得手动把每张草稿的自动推进打开（auto_advance=true），钱才会真的收回来。草稿堆在那儿没人管，等于白暂停一场。

三、暂停期间用户还能干什么：只读，还是全冻住？

暂停键按下去之后，用户打开你的产品看见什么，决定了他还回不回来。这件事没有标准答案，但有一条底线：用户在暂停前产生的数据，一条都不能动。笔记、文件、项目、聊天记录，这些是用户的心血，不是你拿来要挟续费的人质。暂停期间把数据锁死、把导出入口也关掉，用户回来发现东西还在，但导出要先付钱——这种做法短期能逼回来几个人，长期丢的是口碑。正确的做法反过来：暂停期间导出功能照常开着，用户随时能把自己的东西拿走。他拿得走，才敢放心地停；敢放心地停，才敢回来。

只读态和完全冻结，是两种主流做法，选哪个看你的产品形态。只读态是：用户能看、能搜、能导出，就是不能新建、不能编辑、不能调用付费功能。笔记应用最适合只读态——用户出差三个月，偶尔翻翻旧笔记、对对资料，体验不断档，回来接着写也没有断层。完全冻结是：登录后只剩一个页面，写着“你的订阅已暂停，恢复后继续使用”，加一个恢复按钮和到期日。AI 算力、API 调用、团队协作这类按用量计费的功能更适合完全冻结，因为只读态挡不住用量：用户说停了，底层的 token 还在烧，账还是算不清。

两种做法的中间地带是“基础功能保留、付费功能冻结”。比如专业档暂停后自动落到免费档的水平：能看免费档的 50 条笔记、能用免费档的额度，超出部分锁住。这种做法的好处是用户不断粮、不断联，坏处是容易把用户惯坏——暂停三个月用免费档用得挺顺手，回来升级的动力就没了。所以落档之前要算一笔账：免费档的成本你扛不扛得住？如果免费档本身就是亏本引流的，暂停期就别再送，老老实实只读或者全冻。

数据保留期要写死在暂停页上，别含糊。建议是：暂停期数据至少保留到暂停结束后再加 90 天。用户暂停 3 个月、到期没恢复，你再给他 90 天缓冲，缓冲期里发两封提醒，过了缓冲期再按你的数据删除政策处理。千万别在暂停到期当天就删数据——用户可能只是忘了点恢复，回来发现东西没了，这比扣错钱更伤人。删除之前还要留一手：删的只是产品内的数据，账单、发票、支付记录这些财务凭证按法规留着，别一起清掉。

到期提醒是暂停期的最后一根线，节奏建议是三封：到期前 7 天一封，告诉用户“你的暂停还有 7 天结束，到期自动恢复扣款，点这里可以改期或者提前恢复”；到期前 3 天一封，附上到期后第一笔扣款的金额和日期，别让用户对着扣款短信发懵；到期当天一封，扣款成功报个平安，扣款失败给个处理入口。三封邮件的标题别写成营销味十足的“我们想你啦”，就写清楚事：暂停什么时候结束、下一次扣多少钱、点哪里改。用户在暂停期最烦的就是被打扰，提醒越少、越准、越像账单通知，打开率反而越高。

四、恢复那一刻最容易翻车：钱、权益、账单日三件事一起算

暂停功能最容易出事故的不是暂停那一刻，而是恢复那一刻。暂停是用户主动点的，心情是放松的；恢复是系统自动干的，心情是毫无防备的。恢复日那天三件事同时发生：扣款、权益恢复、账单日重算，任何一件出错，用户第一反应都是“你们背着我扣钱”。

第一件是自动恢复扣款失败。用户暂停三个月，卡可能过期了、额度可能不够了、银行可能换了风控规则。恢复日一到，Stripe 自动扣款，扣不成就直接进失败状态——这时候千万别让订阅悄悄变成取消。正确的做法是把恢复失败接进 cycle162 讲过的续费失败挽回流程：第一次扣款失败当天发提醒，给用户 3 天时间换卡；3 天后重试一次；再失败进入 7 天宽限期，宽限期内权益照常用；宽限期过了还没付上，才降到免费档。恢复失败不是取消的理由，它和普通续费失败是同一件事，用同一套流程，别为恢复单独写一套。

手动恢复的流程要比自动恢复更顺，因为点恢复的用户是带着明确意愿回来的，别让他再填一遍表。理想的路径是：邮件里的一键恢复链接 → 确认页（写清恢复后立即扣多少钱、下次扣款日是哪天）→ 点确认 → 权益立即恢复。确认页上最关键的一行字是金额：恢复当期到底扣多少。暂停订阅的新版流程里，恢复会生成一张恢复账单：新一期费用减去暂停时折算的未用天数抵扣，实收多少写清楚再扣。千万别先扣款、后发账单——用户收到扣款短信再去翻账单，信任已经掉了一半。

新版暂停订阅的恢复还有一个 23 小时的窗口要特别注意：恢复请求发出后，Stripe 立即生成恢复账单并尝试扣款；如果 23 小时内没有付款动作，账单会被作废，订阅保持 paused 状态。也就是说，调用恢复接口返回 200 不等于恢复成功——它只表示恢复流程启动了，订阅要等账单付清才变回 active。代码里必须监听状态变化，别在接口返回 200 的那一刻就给用户开权益，否则会出现“权益开了、钱没收到”的窟窿。正确的做法是：恢复接口只负责发起，等 webhook 告诉你订阅变回 active 再开权益；23 小时没等到，就发一封“恢复还没完成，点这里继续付款”的提醒。

恢复后的账单日是第二件容易吵架的事，两种算法要提前选好、写进帮助文档。算法 A 是账单日不变：用户原来每月 1 号扣款，暂停 45 天、6 月 15 日恢复，下次扣款还是 7 月 1 号，恢复当期只收 6 月 15 日到 7 月 1 日这 16 天的费用，按比例折算。算法 B 是账单日重置：恢复那天就是新的账单日，以后每月 15 号扣款。算法 A 对老用户友好，账单日不用重新记；算法 B 对你友好，收入预测整齐、不用算零头。阿远选了算法 B，因为他的财务按月对账，账单日五花八门对起来太痛苦。但选 B 有一个代价要提前说清楚：恢复当期收的是完整一个月的费用，不是按比例折算的零头，用户如果在确认页上看到“立即扣 90 元”却以为是“扣 16 天的钱”，投诉马上就到。两种算法没有对错，但一定要在恢复确认页上把“这次扣多少、下次什么时候扣”写死，用户点确认之前就看得到。

恢复后的权益要和扣款状态严格挂钩，这是最后一道防线。扣款成功，权益立即全开；扣款失败，权益保持暂停态，别先开后补；手动恢复点完确认、钱还没到账，页面上写“恢复处理中”，别写“恢复成功”。权益和钱的状态一旦脱节，对账的时候就是一笔糊涂账：用户用着专业档、系统里却记着暂停态，客服查不到、财务对不上，最后只能人工一笔笔翻。写代码的时候记住一句话：权益只认订阅状态，不认按钮点击。

五、暂停挽留漏斗：原因收集 → 恢复触达 → 指标与检查表

暂停功能上线不是终点，真正的价值在后面：每一个点暂停的用户，都是一次还没发生的流失。把暂停当成挽留漏斗的入口，漏斗分三段：暂停时问原因、暂停中做触达、到期后算指标。

原因收集要短、要准、要可选。暂停确认页上放一道单选题就够了，选项别超过 6 个：暂时不用、手头紧、功能不够用、找到了替代品、价格太贵、其他。选完可以留一句话，不留也能提交。千万别搞五页问卷、必填长文——用户本来就是来按暂停键的，你让他先写小作文，他直接点取消走人。原因数据的价值不在单条，而在分布：连续四周“价格太贵”排第一，说明定价出了问题；“暂时不用”占八成，说明暂停功能本身就是对的，用户不是要走，只是要歇。

恢复触达的节奏分三段。第一段是暂停刚开始的 7 天内：发一封确认信，写清暂停期、恢复日、恢复金额，再附一句“想提前回来随时点这里”。这封信的目的是让用户安心，不是推销。第二段是暂停中期：只发一次，而且只发给“有回头信号”的用户——比如暂停期间还登录看过旧笔记、还打开过你的邮件。内容也别推销，讲点实在的：暂停期间上的新功能、用户原来抱怨的那个问题修好了。第三段是到期前 7 天到到期当天，按第三节的三封提醒走：到期前 7 天、3 天、当天，写清金额和日期。整个暂停期触达不要超过 5 次，超过 5 次就不是提醒，是骚扰，用户回来第一件事就是退订邮件。

指标算三组，别只算一个数。第一组是暂停挽回率：暂停到期后 30 天内恢复的用户数，除以同一批暂停的总人数。行业里没有统一标准，但对 vibe 项目来说，3 个月暂停期的挽回率做到 40% 以上就算合格——因为“暂时不用”的用户本来就有明确的回头时间。第二组是暂停后 90 天留存：恢复的用户里，90 天后还在付费的占多少。这个数是用来防“假恢复”的：有人恢复一个月又取消，挽回率好看、留存难看，说明恢复触达把不该回来的人也哄回来了。第三组是暂停转取消率：点了暂停、到期没恢复、最后取消的用户占比。这个数如果超过 30%，说明暂停期触达没做到位，或者暂停本身只是把取消往后推了三个月。

最后是上线前逐项打钩的检查清单，一共 12 项，缺一项都别上线。暂停入口：三选一放在同一页，暂停时长 1/2/3 个月加自定义、最长 6 个月，12 个月内最多暂停两次。计费：两种暂停机制选定一种当默认，三种账单模式按财务口径选定，resumes_at 必填、默认 3 个月，账期不顺延的规则写进帮助文档，未用天数抵扣与 cycle163 的按比例公式共用一个函数。权益：暂停期只读还是全冻住定好，导出功能照常开，数据保留到暂停结束后 90 天。恢复：恢复失败接进续费失败挽回流程，恢复确认页写清本次扣款金额和下次扣款日，23 小时窗口内只认 webhook 的 active 状态开权益，账单日重置还是不变提前定好。触达与指标：原因单选不超过 6 项且可选填，提醒三封按 7 天、3 天、当天的节奏发，暂停挽回率、90 天留存、暂停转取消率三组指标进周报。12 项全打钩，暂停功能才算真正上线；缺一项，上线第一天就有人在客服群里问你没想过的问题。

说到底，暂停功能修的不是一个按钮，而是一种态度：用户说“我想歇一歇”的时候，你是递给他一把椅子，还是直接把门关上。椅子不贵，三个月少收 90 元；门关上了，回来的人要重新办卡、重新定价、重新找回自己的东西，十个里有九个懒得再进这扇门。把暂停做对了，流失率降下来的那部分用户，是你花多少钱打广告都买不回来的。