一个只讲清楚「我们解决什么问题」的 SaaS 网站，最多能拿到询盘，拿不到注册用户。真正让 SaaS 成立的是四层能力叠加：营销层让人看懂并愿意试；账号层确认「你是谁」；计费层确认「你付了多少钱、买到什么」；应用与管理层把承诺兑现成日常使用。缺任何一层，网站就退化成宣传册。
对创业者和小型软件团队来说，改造顺序建议是先补账号体系，再补订阅计费，最后补后台与权限。三者存在强依赖：没有账号就没有归属主体，没有计费就没有可区分的权益，没有后台就没有人工兜底的手段。
SaaS 官网和实际产品界面到底差在哪
这两类页面的用户、目标和技术要求完全不同，混在一起做是很多项目卡住的第一步。
| 对比维度 | 营销层（首页、价格页） | 产品层（工作台、后台） |
|---|---|---|
| 访问者 | 公开访客、搜索引擎与 AI 搜索爬虫 | 已登录的试用或付费用户 |
| 核心目标 | 解释价值、建立信任、推动注册 | 完成任务、管理数据与账单 |
| 认证要求 | 无需登录 | 必须登录并校验角色 |
| 内容 | 少变，需要被索引 | 高频变化，不能被抓取收录 |
| 优化重点 | 标题、结构化内容、可被引用 | 权限、性能、数据隔离 |
一个常见错误是把工作台也交给搜索引擎抓取，或者把价格页锁在登录墙里。前者泄露产品结构、稀释站点主题；后者让潜在客户在决策前看不到定价，直接流失。正确做法是在路由层就分开：公开路由输出可索引内容，应用路由强制鉴权并禁止收录。
一个能跑起来的 SaaS 网站需要哪些模块
按层拆功能，比按页面拆功能更容易排期。
| 层级 | 必备模块 | 判断标准 |
|---|---|---|
| 营销层 | 首页、功能页、价格页、文档或博客、隐私与条款 | 不看文档也能理解价格与价值 |
| 账号层 | 注册、邮箱验证、登录、找回密码、账户设置 | 用户能自助完成全流程 |
| 计费层 | 结账页、订阅、发票、支付回调、额度 | 付款状态可被系统读出并执行 |
| 应用层 | 用户工作台、核心业务数据 | 登录后能看到「自己的」数据 |
| 管理层 | 用户、订阅、订单、内容、权限、操作日志 | 运营无需改数据库就能处理问题 |
如果时间只够做一半，优先做账号层、计费层和最小的可用工作台，最后再补管理层。管理后台可以先用最笨的表格实现，但一定要有，否则第一批付费用户出问题时只能手工改库。
用户注册、邮箱验证和登录怎么实现
实现路径可以压缩成五步：
- 选择登录方式：邮箱密码为主，加上 Google、GitHub 这类 OAuth 作为快捷入口，能明显降低注册摩擦。
- 写入账号并发送验证邮件：注册成功后立即生成一次性验证 token，绑定账号并设置过期时间；未验证账号标记为待验证，不授予任何付费权益。
- 验证与重发限流：验证链接只能使用一次；同一邮箱的重发要限频，否则会变成轰炸别人邮箱的工具。
- 维持会话：使用服务端会话或带签名的令牌，配合 HttpOnly、Secure 的 Cookie，前端不要长期保存可被脚本读取的凭证。
- 找回密码与解绑：忘记密码走一次性链接重置；第三方登录要允许绑定与解绑，避免用户换邮箱后永久丢失账号。
安全细节上不要自研加密与哈希，使用成熟框架的密码哈希与会话机制。邮箱验证、Google / GitHub 登录和基础账户体系属于通用基础设施，We0 的全栈生成能力已把这类能力纳入生成范围（We0 全栈代码生成），团队可以把精力放在业务字段与权限规则上。
免费用户和付费用户怎么区分
最容易被忽略的一点：权益判断必须发生在服务端，前端只做展示。前端隐藏按钮不等于限制，接口被直接调用时照样会执行。
推荐模型是三张表加一个服务端函数：套餐表定义每个方案的权益标识；订阅表记录账号当前状态、周期与外部订阅 ID；权益表记录账号级额度余量。
canUse(user, feature):
if user.status != "active": return false # 未验证或被封禁
plan = plans[user.plan_id]
if not plan.features.contains(feature): return false
if plan.quota > 0 and user.used >= plan.quota: return false
return true
免费与付费的差别通常落在三处：功能开关（高级报表、多人协作）、数量额度（项目数、成员数、生成次数）、数据保留期。用额度做分层比用「禁用」做分层更平滑——免费用户能真实用出价值，才会主动升级。
Stripe 订阅付款如何接入
订阅接入的核心不是按钮，而是「谁说了算」。原则只有一条：以支付平台的订阅状态为唯一事实来源，自己数据库里的字段只是副本。
- 创建价格对象：为月付与年付各建一个价格，把价格 ID 写进环境变量，不要把金额硬编码在前端。
- 发起结账：由服务端创建结账会话，把账号 ID 写进 metadata，用户跳转离开站点完成付款。
- 接收回调：配置 Webhook 端点，订阅创建、续费成功、付款失败、订阅取消等事件都要处理，回调是开通权益的唯一触发点。
- 回调可重放：同一事件可能重复投递，处理逻辑必须幂等，按事件 ID 或订阅 ID 去重；响应要快速返回，耗时动作异步执行。
- 状态映射：把外部订阅状态映射成内部状态，业务代码只认内部状态，不直接读外部字段。
- 提供账单入口：跳转到支付平台自带的客户门户管理发票与卡片，比自研账单页省下大量维护成本。
| 事件类型 | 系统应做的事 |
|---|---|
| 结账完成 | 写入订阅记录，置为试用或有效，记录周期 |
| 续费成功 | 延长有效期，重置周期内额度 |
| 付款失败 | 置为逾期，保留只读权限并提示更新支付方式 |
| 订阅取消 | 不立即降级，等周期结束再降权 |
| 退款或争议 | 记录状态，暂停高风险权益并人工复核 |
付款成功之后如何开放功能
这一段最容易出事故：用户在支付成功页看到「欢迎使用」，但权益还没写进数据库，进来后看到的是空工作台或再次付款提示。
正确做法是把「支付成功」和「权益生效」当作两个独立事件。回调到达并校验成功后，才写入订阅、刷新权益、发送欢迎邮件；支付成功页只负责轮询自己的接口等待权益可用，超时则提示「付款处理中，稍后邮件通知」，而不是直接放行。
降级同样要设计。到期、欠费、退款都该走统一的降权流程：先保留只读访问一段时间，再逐步关闭写入与导出。突然断掉全部权限会激怒用户，无限期保留全部权限等于免费送产品。
用户在哪里管理账户和套餐
几分钟搭建展示站并增长获客
输入一句想法，We0 AI 即可生成展示站、页面与 CMS。发布上线后并帮你获取客户和流量。
用户注册赠送一次完整项目生成
适合先体验一次完整生成流程，快速看到项目初稿。
一个信息完整的账户页能减少大量客服工单。至少包含：个人资料与密码、邮箱修改（需重新验证）、当前套餐与续费日期、用量与额度余量、发票历史与下载、升级降级取消入口、退出全部设备与账号注销。
套餐变更要区分方向：升级即时生效并按比例计费，降级排到下个周期，避免用户反复切换造成结算混乱。取消订阅时不必做连击式挽留弹窗，一次清晰确认加一句「权益保留到 X 月 X 日」比十层弹窗有效得多。
管理员后台该管理什么
后台不是「给老板看的仪表盘」，而是异常处理工具。
| 对象 | 常见操作 | 关键约束 |
|---|---|---|
| 用户 | 查询、重置密码、封禁、备注 | 不允许直接改明文密码，操作留痕 |
| 订阅 | 查看状态、手动延期、补开发票 | 与支付平台侧核对后再改 |
| 订单 | 查询、退款标记、对账导出 | 退款必须记录原因与操作人 |
| 内容 | 文档、文章、帮助中心 | 与公开站点同源，避免两套内容 |
| 权限 | 分配管理员角色 | 最小权限，敏感操作二次确认 |
后台最常见的错误是把管理员账号做成万能钥匙。建议至少分三档：只读运营、可处理订单与用户、可修改计费与权限。所有敏感操作写入审计日志，出问题时能追溯谁在什么时候改了什么。
官网和后台该放进一个项目，还是拆成两套
早期团队几乎都该选单项目：共享域名与会话，用户在首页注册后直接进入工作台，不需要在多个系统间做单点登录；内容、SEO 与产品更新在同一套路由和部署里，运维成本最低。公开的 SaaS 认证与账户管理示例也采用这种一体化形态，认证、角色权限、订阅、域名与部署都在同一个应用内完成（SaaS Auth Dashboard 示例）。
当团队已经分工明确、流量大到需要独立扩容时再拆成官网、前台应用与后台服务。代价是要维护跨域会话、统一鉴权与内容同步。判断标准可以看三条：官网是否每周多次更新而应用半年才发一版；是否已有多人分别负责营销与产品开发；应用是否有独立的伸缩与数据库隔离要求。三条都成立再拆，否则先合并。
单项目内部也要有清晰边界：营销路由不做鉴权但必须可索引，应用路由强制鉴权且禁止收录，接口层统一校验权益，后台路由加额外角色校验。We0 把页面结构、认证、订阅与积分、CMS 与后台、多语言、SEO 与部署放在同一条生成链路里（We0 全栈代码生成），适合希望用一个项目承接官网与产品入口的团队；具体业务规则与权限边界仍需按产品需求定义。
用项目管理 SaaS 走一遍完整链路
假设做一个给小团队用的项目管理 SaaS，免费版 3 个项目，专业版不限项目并支持成员协作。
- 首页：说清「谁在什么场景下用它」，给出免费注册入口，不要求信用卡。
- 价格页：三个方案并列，标明月付与年付差额，写明额度与限制。
- 注册与验证：邮箱注册后立即收到验证邮件，验证完成才允许创建项目。
- 订阅付款：在工作台内点击升级，跳转托管结账页，选择月付或年付。
- 权益开通：回调写入订阅状态，工作台刷新后项目上限解除，显示当前套餐与续费日期。
- 用户工作台：只展示该账号自己的项目，成员邀请按席位校验。
- 管理后台：客服可查询用户、查看订阅，为逾期用户手动延期一天做缓冲。
这条链路里真正花时间的不是页面，而是第 5 步的状态一致性，以及第 7 步的异常处理。很多团队把八成时间花在首页视觉上，上线后却靠人工处理欠费与退款。
上线前的检查清单
- 未验证邮箱的账号是否被拦在付费权益之外？
- 每一处权益判断是否都在服务端执行？
- 支付回调是否幂等，是否只认平台状态？
- 支付成功页是否等待权益落库，而不是直接放行？
- 逾期、取消、退款是否都有对应降级路径？
- 应用路由是否禁止收录，公开页面是否可被索引？
- 管理员操作是否有审计日志与最小权限？
- 官网内容与帮助文档是否同源，避免长期分叉？
FAQ
SaaS 网站可以只做产品介绍页吗？
可以作为阶段性落地页，但它只能承担获客，无法承载注册、试用与付费。用户点「免费开始」后无处可去，流量就浪费了。
不会写代码能做 SaaS 吗？
账号、订阅、后台与部署这类通用基础设施可以借助成熟平台或 AI 生成能力快速搭起来，但计费规则、权限边界与数据模型仍需人来设计并验证。工具减少重复工程，不能替代产品决策。
订阅付款必须用 Stripe 吗？
不是，但选型要看目标市场与结算周期。Stripe 的订阅、发票与客户门户相对完整；面向国内用户还需考虑本地支付方式。无论用哪家，都要遵守「外部状态为唯一事实来源」的原则。
免费用户和付费用户怎么区分最省事？
套餐表、权益表加一个服务端判断函数。不要在各个页面散布条件判断，否则新增一个套餐就要改十几处代码。
官网和后台要不要放在同一个项目里？
早期放在同一个项目，共享域名与会话，运维成本最低；等团队与流量都需要独立迭代时再拆。
付款成功但功能没开通怎么办？
先查回调是否到达、签名是否校验通过、幂等去重是否误判，再查权益是否写入。用户侧要给出「处理中」的明确反馈与人工兜底渠道，而不是让用户重复付款。
Related Tools
- Stripe 官方文档：订阅、结账与回调机制的原始说明
- React + Shadcn UI 等组件库：快速搭建工作台表格、图表与分页交互（实现参考）
- 设计稿转代码工具：把后台界面设计直接转成可运行页面
- We0.ai：在一个项目内组合认证、支付、CMS 后台与部署
Related Links
- We0 全栈代码生成能力
- SaaS Auth Dashboard：认证与账户管理示例
- Build a SaaS Admin Dashboard with React, Shadcn UI & TypeScript
Summary
只做产品介绍页的 SaaS 网站解决的是「让人相信」，而登录、订阅付款和后台管理解决的是「让人真正用起来并持续付费」。落地顺序建议是账号体系、订阅计费、最小可用工作台、管理后台；技术上有三条硬约束：权益判断放在服务端、支付平台状态是唯一事实来源、支付成功与权益生效分开处理。官网与后台在早期可以放在同一个项目里共享域名与会话，等团队和流量都需要独立迭代时再拆分。
