独立 App 开发系列:用 GitHub Pages 托管隐私政策和用户协议

做独立 App，除了开发功能，还要准备一些用户平时不太会点开、上架时却绕不开的内容。

隐私政策就是其中之一：Google Play 后台要填一个地址，App 里也要有入口，页面还得说清楚产品实际怎样处理数据。

我的做法是单独建一个公开的 legal 仓库，集中维护隐私政策和用户协议，再通过 GitHub Pages 发布。App 代码继续放在自己的仓库里，两边通过固定链接和发布检查配合。

本地工具也需要隐私政策

如果 App 没有账号、没有自己的服务器，主要功能都在手机上完成，还需要隐私政策吗？

Google 的要求很明确：需要。用户数据政策 [1] 的 Privacy Policy 部分写的是：

Apps that do not access any personal and sensitive user data must still submit a privacy policy.

即使不访问个人和敏感用户数据，App 仍然要提交隐私政策。

本地工具也有值得说明的事情：为什么申请某个权限，选择的文件会不会上传，设置保存在哪里，删除数据时应该怎样操作。

与页面建设直接相关的要求，可以归成这几项：

• 找得到：
   Play Console 填写链接，App 内提供链接或正文。
• 打得开：
   URL 有效、公开可访问，不限制访问地区；不能是 PDF 或可编辑文档。
• 说得清：
   标明应用或开发者归属，说明数据处理、第三方服务、安全措施、保留和删除方式，并提供联系渠道。

我也会一起准备用户协议。两份文档的分工要讲清楚：

隐私政策： 产品怎样处理用户数据。

用户协议： 使用规则、付费权益与服务边界。

用户协议是我们的产品安排，不能把它与上面列出的 Google 隐私政策要求混成一项。

平台要求沿用 2026 年 9 月 15 日核对的官方资料。

用 GitHub Pages，把页面放到网上

隐私政策和用户协议主要由文字和链接组成，用静态 HTML 就能呈现。GitHub Pages 可以从仓库发布静态页面，并提供 github.io 地址 [2]。

这部分不需要自己购买服务器，也不必先买域名。对我来说，免费托管，加上 Git 的修改记录，已经足够满足这类页面的需要。

但采用免费方案有一个前提：使用 GitHub Free 时，承载 Pages 的仓库必须公开。 部分付费方案支持从私有仓库发布 Pages，因此“必须公开”不是所有方案的通用限制 [4]。

App 代码可以继续保持私有，公开的内容放进另一个仓库。我习惯给它加上 -legal 后缀。

两个仓库分别提交和发布；App 发布前，直接读取 legal 工作区做检查。

隐私政策和用户协议，以 legal 仓库里的内容为准。 各语言文案、共用生效日期、样式和生成工具都放在这里，修改源文件后生成 HTML。

我把两个仓库放在同一个工作目录（workspace）下，方便和 AI 一起查看代码与法律文案。添加广告、账号、上传或付费功能时，先根据 App 的实现核对数据行为，再修改 legal 仓库中的说明。

Pages 负责静态内容展示。账号处理、数据删除和支付等业务仍由对应系统完成；GitHub 对商业交易和 SaaS 等用途另有使用限制 [3]。

官网可以顺带一起做

如果产品还需要一个官网，可以在同一个 Pages 站点加一个简单的首页，介绍产品、提供下载入口和联系方式，再链接到隐私政策与用户协议。

我的项目就把首页和法律页面放在同一个 legal 仓库里，共用样式和导航。我觉得，对独立产品来说，有这样一个完整的对外入口，会显得更正规一些。

官网按产品需要增加。 只准备上架所需的页面时，把隐私政策和用户协议做好就可以，产品介绍以后再补。

先核对产品，再写页面

页面有了托管位置，接下来要确定写什么。

我会让 AI 读取 App 的代码、权限和依赖，先整理数据行为，再起草文案。代码无法确认的服务器配置、SDK 开关和保留期限，由开发者补充。

• 账号与服务器：
   是否注册，哪些数据离开设备。
• 权限与文件：
   为什么访问，用于什么功能。
• 第三方 SDK：
   广告、统计、崩溃服务处理哪些数据。
• 付费功能：
   提供什么权益，怎样处理购买相关信息。
• 保存与删除：
   存在哪里，保留多久，怎样删除。

例如，一个工具可以在本地处理文件，同时接入广告或崩溃分析服务。文件有没有上传、SDK 有没有发送其他数据，要分别核对。

删除方式也要写具体。应用内部的设置、用户导出的文件、服务器上的账号数据，可能需要不同的删除操作。只有确认数据会随清除存储或卸载一起删除，才能这样描述。

如果 App 支持在应用内创建账号，还要核对账号删除要求 [6]：提供 App 内和网页端的删除请求入口，并实际处理账号及相关数据。

从文案生成到页面上线

文案和页面分开维护

我的项目支持多种语言，日常修改从文案源开始：

• content/legal/<语言>.json
  ：各语言的隐私政策和用户协议。
• content/legal.json
  ：共用生效日期。
• tools/build_site.py
  ：生成静态 HTML 页面。

完整目录放在文末，先看页面需要具备的结构：

页面结构示意；实际文案、日期和联系方式应按产品填写。

隐私政策与用户协议各自有直接访问的地址。英文页面位于根目录，其他语言放在对应目录下。商店使用固定的隐私政策地址，App 按语言设置选择页面，未覆盖时回退到默认版本。

我的项目目前有 15 种语言、30 个法律页面。把文案与生成工具分开后，更新日期、样式和语言导航更容易统一检查。

让 AI 协助，再核对结果

可以让 AI 同时读取两个仓库，完成数据行为清单、文案初稿和页面生成工具。任务至少要交代清楚：

文末附了完整提示词，可以替换目录和应用信息后使用。生成后，我会重点核对数据处理、付费承诺、删除方式和联系方式，确保每项说明都能对应到实际行为。

生成并检查页面

我的项目使用 Python 3，在 legal 仓库运行：

python3 tools/build_site.py python3 tools/build_site.py --check 

第一条生成页面，第二条检查输出是否与源文件一致。我的项目还把产品首页放在同一个仓库，所以生成时也会更新首页和站点地图。

这两条命令只操作本地文件。检查通过后，再审阅文案和差异，将源文件、日期及生成结果一起提交。

生成检查负责文件一致性；文案准确性和翻译含义，仍要单独核对。

配置 GitHub Pages

将页面提交到公开 legal 仓库后，打开 Settings → Pages。

在 Build and deployment 中，按下面设置：

• Source：Deploy from a branch
• Branch：
   存放页面的分支，例如 main
• Folder：
   页面在仓库根目录时，选择 /(root)

图源：GitHub Docs「配置发布源」[7]；示例选择从分支发布。

点击 Save，等待部署完成，再通过 Visit site 打开站点。这采用 GitHub 提供的从分支发布方式 [7]，初次托管静态 HTML 时不必额外编写构建工作流。

项目站点地址包含仓库名这一层路径。例如下面的隐私政策地址，your-account 是占位名称，实际以自己的 Pages 设置为准：

https://your-account.github.io/app-legal/privacy.html 

中文版本可以放在 zh-CN/privacy.html，用户协议可以放在 terms.html。页面中的资源和语言链接，都要按实际部署地址检查。

把地址接入 App 和商店

Play Console 填写具体的隐私政策页面地址，让用户打开就能读到正文。App 的设置或关于页面提供隐私政策和用户协议入口，按已支持的语言选择链接。

上线前，沿着用户的路径检查一遍：

• 未登录 GitHub 时，页面仍然能打开。
• 手机上能读清正文，语言切换与协议链接正常。
• App 内的入口打开了对应语言的页面。
• 页面归属、联系方式与当前数据行为一致。
• 在面向用户的访问环境中确认可用；自己电脑能打开，不代表所有地区都已验证。

后续维护，跟着 App 的变化走

假设最初没有广告，后来接入了广告 SDK，我会把法律页面也纳入这次功能交付：

1. 在 App 仓库核对 SDK、配置和数据行为。
2. 在 legal 仓库更新各语言文案与实际生效日期。
3. 生成页面，检查文件一致性、正文和翻译。
4. 核对 Play Console 的 Data safety，运行 App 发布资料校验。
5. 发布 legal 改动，再检查线上页面与链接。

App 发布校验直接读取指定的 legal 工作区，核对必需页面、生效日期、语言切换和本地链接。目录或页面缺失会报错；检查另一个开发工作区时，可以用 --legal-root 指定目录，命令示例见文末。

在我的配置中，legal 改动合入 main 后，Pages 才会部署。新增页面或语言时，先上线并验证页面，再发布引用新链接的 App 版本。

还要留意两件事：

• 文案与后台申报保持一致。
   Data safety 是结构化表单，政策页文字不能代替它 [5]。超出用户合理预期的数据访问，还可能需要在功能使用前作出显著说明并取得同意 [8]。
• 保留已经对外使用的 URL。
   改版、增加语言或调整首页时都要检查旧链接；需要迁移时，同时处理跳转和 App、商店中的引用。用户手机上的旧版本，可能还在使用旧地址。

写在最后

我选择这套方式，主要看中两点：托管成本低，文案也有固定的维护位置。

App 仓库负责产品实现、页面入口和发布校验，legal 仓库负责法律文案、生成与发布。两边在同一个工作目录下协作，功能变化时一起检查。

以后做新的应用，可以沿用这套结构。真正需要重新判断的，是这个产品访问什么数据、引入什么服务，以及向用户做了哪些承诺。

附录：可复用的文件与提示词

最小目录示例

app 和 app-legal 分别代表 App 仓库与公开页面仓库。路径和脚本名是项目约定，按自己的工程调整。

index.html 可以作为法律页面的目录；需要产品官网时，再扩充为产品介绍首页。

交给 AI 的完整提示词

替换应用名称、公开联系方式和目录后使用：

如果还想一起搭建官网，可以补充：在同一个站点增加产品介绍首页，包含功能介绍、下载入口、联系方式，以及隐私政策和用户协议链接。

检查另一个 legal 工作区

先在对应 legal 工作区运行生成检查，再在 App 仓库运行以下命令。示例路径需要换成待检查的实际目录：

python3 tools/release/validate_store_listing.py \   --legal-root /path/to/legal-worktree 

参考资料

以下网址可复制到浏览器打开。

[1] Google Play 用户数据政策

https://support.google.com/googleplay/android-developer/answer/10144311?hl=en

[2] GitHub Pages 官方介绍

https://docs.github.com/en/pages/getting-started-with-github-pages/what-is-github-pages

[3] GitHub Pages 使用限制

https://docs.github.com/en/pages/getting-started-with-github-pages/github-pages-limits

[4] 创建 GitHub Pages 站点

https://docs.github.com/en/pages/getting-started-with-github-pages/creating-a-github-pages-site

[5] Data safety 填写说明

https://support.google.com/googleplay/android-developer/answer/10787469?hl=en

[6] 账号删除要求

https://support.google.com/googleplay/android-developer/answer/13327111?hl=en

[7] 配置 GitHub Pages 发布源（含配图来源）

https://docs.github.com/en/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site

[8] Google 的显著披露与同意要求

https://support.google.com/googleplay/android-developer/answer/11150561?hl=en