如何为 Next.js 应用添加隐私政策

确定项目使用 App Router、Pages Router，还是既有的混合结构。Next.js 将文件映射到路由，页面位置取决于该结构。在 App Router 项目中，app/privacy-policy/page.tsx 可定义隐私路由；使用 src 目录的项目则将同样结构放在 src 下。遵循项目现有约定。

创建另一套布局前，检查是否已有法律页面外壳。定位共享页脚、注册表单、结账入口和账户设置页，同时查明身份验证守卫和路由规则。实现应适配这些调用位置，不要假定 AI 助手创建的项目都使用相同文件树。

检查服务器操作、路由处理程序、数据库调用、身份验证、邮件发送和支付 webhook。浏览器网络面板不会显示服务器代表用户发出的每个请求。再单独检查客户端分析、嵌入内容和错误报告。如果营销网站与应用共同部署，也应纳入。

使用可丢弃的测试账户，追踪从注册到删除的过程，验证实际持久化行为。切勿将环境机密或客户内容粘贴到文档流程中。隐私政策通用生成指南提供了可交给编程助手的梳理方法。框架名称只是检查起点，并不能回答产品具体收集哪些数据。

使用网站隐私政策生成器，或选择适当的应用或 SaaS 产品类型。填写已确认的运营方身份、联系方式、处理活动、服务商、受众、保留期限和地区事实。审阅完整预览，不要让助手用看似可信的文字填满法律页面。

如果项目有订阅或工作区，可用SaaS 政策指南检查额外数据流。未明确的业务决定应向负责人确认，不要从代码猜测。核实所选模块显示的价格，并在审阅内容后选择交付格式。路由只是容器；文档内容准确仍是一项独立要求。

托管文档可让共享页脚直接指向公开政策 URL，无需新增本地内容路由。独立 HTML 是适合作为单独文件提供的完整文档。受支持的 HTML 片段则适用于已提供应用导航、阅读宽度和视觉设计的法律页面。应选择符合现有架构的格式。

使用助手集成时，请求适当交付格式并集成原样返回的输出。不要让助手为缩短组件而改写文档。保留标题、链接、日期和所有章节。确保不可信内容经过转义，避免在应用中引入可渲染任意用户标记的通用功能。

检查页面及外层布局的身份验证逻辑，避免法律页面意外继承已登录仪表板的重定向。也要检查重写未知路径、要求完成引导或依会话限制访问的规则。使用全新的浏览器会话验证结果。

选择 /privacy-policy 等稳定地址并一致使用。不要在生产页脚和服务商管理面板中使用预览部署或会过期的审阅链接。日后变更路径时，应有意保留重定向，让旧链接继续有效。政策 URL 指南解释了为什么地址必须指向完整公开文档，而非产品首页。

在共享页脚添加标识明确的隐私政策链接，让新页面也能继承。再按实际情况，在注册、邮件简报信息收集、上传或结账附近提供入口。单一共享布局不一定覆盖嵌入式支付、独立营销域名或身份验证服务商的托管界面。应逐处检查。

使用放置指南检查位置。服务条款应另设链接，并明确其作用。测试键盘焦点和手机可读性。不要将唯一政策链接藏在悬停菜单或依赖已登录状态的按钮中。读者激活链接前就应明白它通往哪里。

在隐私窗口打开最终 URL、刷新，并分别从表单和页脚进入。检查 HTTP 响应及可见内容；服务器返回响应，并不意味着应用外壳或品牌错误页就是成功的政策页面。如果发布方案支持静态或服务端渲染 HTML，还应测试脚本不可用时的情况。

检查页面标题、唯一主标题、章节导航、长 URL 和打印布局。在窄屏上确认内容不会溢出或被固定控件遮挡。如果项目同时包含 Next.js 和独立客户端应用，需要分别检查导航，可参阅React 集成指南。

记录已批准版本及其事实输入，避免未来的助手在重新设计时，用临时编写的页面替换。修改布局、身份验证、域名设置或托管时，应纳入法律路由检查。如果实现会获取托管内容，应了解请求失败时的行为，避免默默显示空白页。

服务器行为改变时，例如新增模型 API、移动上传存储或引入分析，应重新审阅政策。更新指南有助于识别审阅触发条件。仅改样式时，应保留文档实质章节。陌生访客能在实际生产地址访问并阅读已批准内容，才算完成发布。