完善网站与部署上线

前面的教程已经完成核心功能、额度限制和支付接入。这一篇完善页面与生产配置，部署服务，并在正式域名上验证主要流程。

完善页面和组件

到目前为止，网站的基本功能已经完成了，接下来就是完善页面和组件，让网站看起来更美观、更专业。

这个要看个人的审美和需求，Saavo 已经提供了大部分的页面和组件，你只需要根据需要进行调整和完善即可。更多时候，都是让 AI 进行美化修正，然后人工审查校验即可。

下面是需要修正的页面列表：

• 首页
• Pricing 页面
• 关于页面
• Terms、Privacy、Cookie 页面
• Affiliate 页面
• 博客内容
• 文档内容
• 用户后台的产品页面
• public 目录下的图标、OG 图片、favicon 等资源
• llms.txt 文件内容

这些页面完善之后，如果增加或修改了组件，最好再使用 saavo-localize-components 处理国际化，保证组件支持多语言。

除了页面的内容之外，还需要完善每个页面的 SEO 信息，可以让 AI 根据页面内容，使用 useSeoMeta 和 useSchemaOrg 等 hook 函数，自动生成对应的 SEO 内容。

发布前的准备

上面只是把功能做出来了，离正式上线还差最后一步：把开发阶段使用的测试配置换成生产配置。这里最容易出问题的往往不是代码，而是域名、回调地址和密钥填错。

Stripe 已经在上一篇教程中配置好了，剩下的服务建议按下面的顺序处理。具体的操作步骤都放在可选服务章节里，这里只说明 WebpageToPDF 上线前要做哪些事情。

确定正式域名

先确定网站正式使用的域名，具体的解析和绑定可以在 Worker 部署完成后，按照域名配置处理。workers.dev 提供的地址适合临时测试，正式上线还是要使用自己的域名。

域名最好先确定下来，因为后面的 Turnstile 和 OAuth 都要填写正式域名。WebpageToPDF 使用的是 webpagetopdf.dev，下面的回调地址也以这个域名为例。如果你的项目使用其他域名，记得全部替换成自己的。

配置 Resend

注册验证、找回密码和安全通知都需要通过邮件发送。按照配置 Resend完成发信域名验证，创建 API Key，并把 RESEND_API_KEY、发件人地址和客服邮箱写入生产环境配置。

部署完成后，最好用一个真实邮箱完整测试一次注册和找回密码。邮件能发出去只是第一步，还要检查发件人名称、正文里的链接以及垃圾邮件拦截情况。

配置 Turnstile

Turnstile 用来拦截批量注册和自动化请求。按照配置 Turnstile为正式域名创建站点，并在生产环境中填写 CLOUDFLARE_TURNSTILE_SITE_KEY 和 CLOUDFLARE_TURNSTILE_SECRET_KEY。

本地开发时使用的测试密钥只适合调试流程，并不能提供真正的防护，上线前一定要换成正式密钥。

配置 GitHub OAuth

如果要支持 GitHub 登录，按照配置 GitHub OAuth创建 OAuth App，并把正式回调地址设置为 https://webpagetopdf.dev/api/auth/oauth2/github。然后将拿到的 GITHUB_CLIENT_ID 和 GITHUB_CLIENT_SECRET 写入生产环境配置。

部署完成后，分别用新账号和已经注册过的账号登录一次，确认不会重复创建用户，也不会因为邮箱相同导致登录失败。

配置 Google OAuth

如果要支持 Google 登录，按照配置 Google OAuth创建 Web 应用客户端。授权来源填写 https://webpagetopdf.dev，回调地址填写 https://webpagetopdf.dev/api/auth/oauth2/google，再把 GOOGLE_CLIENT_ID 和 GOOGLE_CLIENT_SECRET 写入生产环境配置。

如果还启用了 Google One Tap，部署后也要在正式域名上单独测试一次。浏览器隐私设置、第三方 Cookie 和 HTTPS 都可能影响它的显示，不能只看普通的 Google 登录是否正常。

整理业务资源和生产配置

以上密钥和地址都应该写在 .env.production 中，不要提交到 Git，也不要只在 Cloudflare 控制台里手动修改。这里先把需要的配置准备齐，等部署时再统一同步到 Cloudflare。

WebpageToPDF 还使用了一个独立的 PDF Worker。进入部署前，需要把它的部署命令、Service Binding 名称和环境变量整理清楚。通用的 Saavo 部署流程无法自动判断这部分业务依赖，后面部署时需要单独处理。

最后再用匿名用户、注册用户和 Pro 用户各走一遍主要功能，确认三种转换模式、免费体验、额度扣减和付费权限与前面的产品设计一致。失败的转换是否扣除额度，也要按既定规则检查一次。

到这里，产品功能和上线所需的配置就准备完成了，接下来开始部署。

部署上线

前面已经完成了 Stripe、Resend、Turnstile 和第三方登录的配置，对应的生产密钥也已经写入 .env.production。这里不再重新创建商品、Webhook 或 OAuth 应用，只处理还没有完成的 Cloudflare 部署。

部署 PDF Worker

WebpageToPDF 使用了一个独立的 PDF Worker，Saavo 的部署脚本不会自动创建这项业务服务。如果它还没有部署，需要先把它发布到同一个 Cloudflare 账号，再确认主项目中的 Service Binding 名称与实际 Worker 一致。如果前面迁移功能时已经部署过，这一步检查无误后可以直接跳过。

确认 Cloudflare 账号

先在项目目录中检查 Wrangler 当前登录的账号：

npx wrangler whoami

如果尚未登录，或者显示的不是准备部署 WebpageToPDF 的账号，再执行：

npx wrangler login

正式域名、R2 和刚才的 PDF Worker 最好都放在这个账号下，后面创建资源和绑定服务会省去不少麻烦。

完成首次部署

确认账号无误后，执行：

npm run deploy:init

项目在本地开发时只运行过 saavo:init，还没有创建远程资源，因此这里使用 deploy:init。脚本会读取现有的 .env.production，补全缺少的部署配置，然后创建并绑定 D1、KV、R2 和 Queue，初始化远程数据库，部署 Worker，最后检查网站是否可以访问。

前面已经填过的 Resend、Turnstile 和 Stripe 配置不需要重新输入。按照终端提示确认即可，也不要再去 Cloudflare 后台手动创建一套同名资源。完整的终端操作可以参考首次部署。

首次部署使用 workers.dev 地址。等终端提示部署成功后，先打开这个地址检查首页，确认网站没有出现 500 错误，再继续绑定正式域名。PDF 转换等完整业务流程可以等域名切换后再测试。

切换到正式域名

WebpageToPDF 使用的正式地址是 https://webpagetopdf.dev，执行下面的命令完成切换：

npm run domain:set -- https://webpagetopdf.dev

这个命令会更新生产环境中的站点地址，为 Worker 添加 Custom Domain，并重新完成验证和部署。执行前要确认 webpagetopdf.dev 已经接入当前 Cloudflare 账号，具体可以参考前面的域名配置。

核对第三方服务

域名生效后，再检查一次各个平台中的正式地址：

这些内容前面已经配置过，这里只核对，不要重复创建 Stripe Webhook 或 OAuth 应用。如果发现 .env.production 中的密钥有修改，再运行一次：

npm run deploy:update

如果只是修改 GitHub、Google 或 Stripe 后台中的回调地址，没有改项目代码和环境变量，就不需要为了这一步重新部署。

上线验证

最后在正式域名上把主要流程走一遍：

1. 使用新邮箱完成注册、邮件验证、登录和找回密码。
2. 分别测试 GitHub 和 Google 登录，启用了 Google One Tap 的话也一并检查。
3. 使用匿名用户、注册用户和 Pro 用户测试三种 PDF 转换模式，确认额度扣减和权限限制符合前面的设计。
4. 确认 Stripe 测试模式中的购买、Webhook 回调和权益发放已经走通。正式模式如需验证，应使用经过允许的小额商品完成交易，并按流程退款。
5. 登录管理后台，检查用户、订单、任务日志以及 Queue 是否存在异常。

更完整的检查项目可以参考上线验证。这些流程都没有问题后，WebpageToPDF 就可以正式开放给用户了。

以后修改代码或生产配置时，直接使用 npm run deploy:update 更新即可，不要在同一个项目上重复执行 deploy:init。上线后的日志、定时任务和数据备份可以继续参考发布后的检查事项。

本篇检查

完成上线验证后，这个教程中的产品开发流程就走完了。后续可以在当前基础上继续迭代功能。

教程总览 · 上一篇：接入 Stripe 支付