总体路线与原则

版本：2026-04-26

目标

这个方案面向一个个人开发者主导的论坛项目。约束条件是：

• 部署在 Vercel 上，尽量使用 Vercel Functions、Marketplace 数据库、Blob、Cron、Queues、Edge Config、Observability 等托管能力。
• 主要开发语言是 JavaScript/TypeScript；Rust 作为可选增强，不作为第一阶段主框架。
• 需要接入付费，但 Stripe 是否可开通存在不确定性。
• 产品形态是论坛。论坛的核心资产不是“功能数量”，而是内容质量、关系网络、信任和社区秩序。

最终目标不是搭一个“论坛程序”，而是搭一个能真实运营、能收费、能长期迭代的社区产品。

核心原则

这个项目从第一版开始遵循以下原则：

1. 安全是地基，不是后补项。 一人项目没有安全团队兜底，所以登录、权限、密钥、审计、支付 Webhook、管理员操作必须从第一版就设计。

2. 复杂度必须有收益来源。 如果只有一个产品、一个人维护，早期不值得维护多套部署单元和自建平台。先用 Vercel 托管能力，把复杂度留给平台。

3. 成本纪律比极致省钱更重要。 论坛早期流量可能很小，但垃圾请求、爬虫、图片上传、搜索、邮件通知都可能产生真实成本。每个变动成本都要有上限、记录和关闭开关。

4. 规格驱动开发。 在 AI 辅助开发时代，写清楚数据模型、状态机、权限、错误码和测试计划，比直接让 AI 开写更重要。设计文档是给未来的你和 AI 的共同上下文。

5. 先占坑，后填坑。 会员等级、付费板块、邀请码、审核状态、审计事件、内容修订历史这些结构第一版就可以存在，但不必第一版实现全部复杂功能。

6. 独立服务思想可以保留，物理拆分要延后。 邀请、计费、使用量应该有清晰边界。但第一版论坛不建议拆成多个服务。先在单体内做成 bounded context，等第二个产品或第二个论坛复用时再抽离。

论坛产品特性

论坛不是用户进来完成一个任务就走。论坛的价值来自持续互动：

• 高质量主题能被搜索引擎长期带来流量。
• 用户之间的回复、收藏、关注、提及会形成关系网络。
• 社区规范和治理会决定内容质量的上限。
• 早期用户质量比用户数量重要得多。
• 付费形态更适合“会员制”和“访问权”。

所以第一版优先级应该是：

内容发布和阅读
  > 权限和审核
  > 搜索和发现
  > 通知和留存
  > 会员和付费
  > 实时互动和复杂增长

不要一开始做完整的大型社区平台。第一版只需要服务好一个垂直人群和一个明确讨论场景。

推荐总体架构

第一阶段采用“Vercel 单项目 + 清晰模块化单体”：

用户浏览器
  -> Vercel CDN / Middleware
  -> Next.js App Router
       -> 公开论坛页面
       -> 登录后发帖、回复、通知、个人设置
       -> Route Handlers / Server Actions
       -> auth 模块
       -> forum 模块
       -> moderation 模块
       -> notification 模块
       -> billing 模块
       -> audit 模块
  -> Neon Postgres
  -> Vercel Blob
  -> Upstash Redis / Vercel Queues
  -> Stripe / Paddle / Lemon Squeezy / Manual Provider

部署单元先保持简单，代码边界先设计清楚。这样能利用 Vercel 的预览部署、环境变量、托管数据服务和自动扩缩容，同时避免过早维护多个服务。

技术栈选择

层级	默认选择	原因
前端与后端	Next.js + TypeScript	与 Vercel 最贴合，SSR/SEO/Route Handlers 一体化
数据库	Neon Postgres via Vercel Marketplace	论坛是关系和查询密集型产品，Postgres 比 NoSQL 更自然
ORM	Drizzle ORM	类型友好，迁移文件可审查，SQL 透明
对象存储	Vercel Blob	头像、帖子图片、附件、导出物
速率限制/热缓存	Upstash Redis	限频、计数、短期锁、反垃圾状态
异步任务	Vercel Queues 或 Upstash QStash	邮件通知、搜索索引、审核扫描、摘要任务
定时任务	Vercel Cron Jobs	每日摘要、过期数据清理、统计汇总
配置开关	Vercel Edge Config	邀请制开关、只读模式、付费功能开关、关键词规则
认证	Auth.js 或 Better Auth	自主可控，适合 Postgres 存储
支付	Stripe 优先，MoR/Manual 备选	通过 BillingProvider 抽象隔离
Rust	后置增强	仅用于明确收益的 CPU 密集或 Wasm 模块

当前不建议做的事

• 不建议第一阶段自建通用 serverless framework。Vercel 已经提供了足够的运行时抽象。
• 不建议第一阶段拆多个 Vercel 项目。先做一个模块化单体。
• 不建议第一阶段做 WebSocket 实时论坛。Vercel Functions 不适合作为 WebSocket server；论坛也不需要第一天实时。
• 不建议一开始做私信、群聊、复杂声望系统、广告系统、创作者分成。
• 不建议把 Rust 放进普通 CRUD、OAuth、支付 Webhook 和后台管理主路径。
• 不建议在 Stripe 能否开通之前，把业务代码绑定死在 Stripe。

Vercel 付费计划判断

如果论坛有收费、会员、广告、赞助或商业用途，应按 Vercel Pro 规划，而不是长期跑在 Hobby。

这点会影响成本预期：一旦开始收费，Vercel Pro 的平台费应算入固定成本，而不是当成可选项。

支付可行性判断

Stripe 支持的商户开户地区包含美国、香港、日本、新加坡、英国、欧盟多国等，但不包含中国大陆。如果你的经营主体和银行账户在中国大陆，短期不应假设 Stripe 可以直接开通。

判断路径：

• 如果你人在美国并能以合法个人/sole proprietor 或公司身份通过 Stripe KYC，可以优先用 Stripe。
• 如果你有香港、新加坡、美国等 Stripe 支持地区的主体和银行账户，可以评估对应地区 Stripe。
• 如果你只有中国大陆个人身份和大陆银行账户，应优先评估 Paddle、Lemon Squeezy 这类 Merchant of Record，或先用 Manual Provider 验证付费意愿。
• Stripe Atlas 是可能路径，但它会引入公司、税务、银行和维护成本，不应只为论坛 MVP 轻率启用。

这不是法律或税务建议。支付方案最终要按你的主体所在地、用户所在地、产品类型和平台审核结果确认。

论坛的第一性原理

第一版论坛的目标不是“功能完整”，而是形成一个可验证的闭环：

有明确垂直主题
有可读的公开内容
有可控的注册和发言门槛
有最小审核后台
有通知和回访机制
有会员或付费板块假设
有审计和成本记录
能通过 Vercel 快速部署和回滚

如果三周后你有 20 个高质量帖子、10 个真实用户、3 个持续回复的人、1 个愿意付费或明确表达付费意愿的人，这比拥有一个功能齐全但没人发帖的论坛更有价值。