微信小程序用户服务协议及隐私政策模板

小程序上架前被驳回，八成不是代码问题，而是服务协议和隐私政策这两份文本缺项、权限声明对不上实际调用。这篇不讲法条大道理，只给可直接套用的模板骨架、逐项填空清单和提交前的自查顺序，让开发者在提审前把文本这块补完整。

小程序提审被打回，很多开发者第一反应是去翻代码，其实被卡住的常常是服务协议和隐私政策这两份文本：要么缺段落，要么声明的权限和实际调用的接口对不上。这篇不讲法条大道理，只给能直接套用的模板骨架、逐项填空清单，以及提交前的自查顺序，帮你把文本这块补完整。

先记住一个原则：模板只提供结构，不提供结论。凡是涉及你实际业务的部分——收不收位置、接不接支付、有没有社交功能——都得按真实功能增删。留着一堆用不上的条款，审核照样会问你为什么写。

模板骨架：两份文本各写哪几段

服务协议和隐私政策是两份不同的东西，别混在一起写。服务协议管的是「你和我之间怎么用」，隐私政策管的是「我拿你的信息做什么」。骨架先搭对，后面填内容才不会乱。

• 每段先写一句人话，再补细节，审核和用户都先看那句
• 两份文本都要写生效日期和版本号，改一次动一次版本，别只改正文不改日期
• 没有的功能整段删掉，不要留占位符，比如不接支付就别写退款
• 未成年人、数据出境这类敏感段，没有就写明不涉及，含糊过去反而被追问

权限声明与接口调用要一一对上

这是驳回率最高的一块。后台声明了哪些权限、代码里实际调了哪些接口，两边必须一一对应。多声明是浪费，少声明是硬伤——调了没声明，基本直接打回。

1. 第一步：拉接口清单把小程序里实际调用的每个敏感接口列成表，写清接口名、触发场景、拿到的信息类型。用搜索全局找一遍，别凭记忆。
2. 第二步：做映射表每个接口对应到隐私政策里的哪一句，逐条对。对不上的要么补句子，要么删接口。
3. 第三步：补降级路径用户拒绝授权后会怎样，写进文本也要真能跑通。比如不给位置就只显示城市级结果，审核会点进去试。
4. 第四步：拆第三方第三方 SDK、登录组件、支付组件单独列出名称和收集的信息类型，别笼统写「第三方服务商」。

• 只声明不调用的权限删掉
• 调用了没声明的必被驳回
• 拒绝授权后的降级路径要写明
• 第三方组件逐项列名

映射表做完别扔，下次改功能时对照着更新。字段术语拿不准的，去 安全与合规（/safety） 对照一下再决定怎么写。

填空清单：提审前逐条打勾

模板套完，真正容易漏的是那些「看起来写了其实点不到」的地方。下面这几类，逐条自己走一遍流程，比对着文本读十遍有用。

• 主体信息：运营者全称、联系方式（邮箱或电话至少一个能打通）、注册地址与实际一致
• 用户权利入口：查询、更正、删除、注销账号的路径要能真点到，不能只写一句话
• 未成年人条款：有面向学生或社交功能就必须写，没有也建议写明不面向未成年人
• 数据共享与出境：用境外服务或把数据给外部处理方，要写清场景和大致范围
• 联系方式验证：用一个陌生邮箱发一封信，看多久能回，回不了就换

还有一类常被忽略：注销账号。很多模板只写「用户可以注销」，但没说怎么注销、多久生效、注销后数据怎么处理。补一句流程说明，能省一次驳回。

改版、留证与后续维护

文本不是一次写完就锁死的。功能一改、第三方一换，协议就得跟着动。真正能保护你的不是协议正文，而是「用户当时同意了哪一版」这件事能不能举证。

驳回之后别急着反复提交同一份。先看理由是缺字段、缺入口还是表述含糊：缺字段就补，缺入口就做，表述问题就改说法，改完更新版本号再提。同一份反复提交只会拖时间。

如果你同时在做合规自查和成本核算，站内几个页面可以配合着看：合规术语去 安全与合规（/safety），接口和技术口径去 工具目录（/tools/speed-test），要用到外部 API 的，价格和数据去 价格追踪（/price-watch） 核对当时的数字，别照着旧文章里的数写进预算。