会员、权限与评论可选集成路线图

本文是 NotionNext 下一阶段“登录、会员、权限、评论”方向的克制方案草案。它不是承诺清单，也不是要把 NotionNext 做成完整会员 SaaS 平台；目标是把已有 Clerk 演示、Notion Integration 能力和评论插件体系收口成可维护、可替换、可自托管的可选方案。

丰富功能可以带来更便捷的集成体验，但也会违背工具应当专一、专业、简洁的原则。NotionNext 的默认路径仍然应该是轻量博客和内容站：能不用会员系统就不用，能用现有评论插件就不重写，能做成可选插件就不进入核心。

核心判断

NotionNext 的优势是用 Notion 维护内容，用独立站完成发布、检索、展示和运营。会员能力也应该沿用这个边界：

• Clerk 等认证服务负责登录身份。
• Notion Integration 负责读取站长在 Notion 中维护的低频权限数据。
• 评论优先复用现有评论插件。
• NotionNext 核心只保留最小接口，不强制普通站点启用登录、会员或自有评论。

不建议一开始内置支付、订单、积分、复杂 RBAC、CRM 和运营看板。那些能力差异很大，且容易把普通博客用户的部署路径变复杂。短期更适合提供字段约定、适配器接口、可选插件、最小示例和清晰文档。

目标用户

优先服务三类站点：

• 内容站：希望登录后查看特定文章、资料或页面。
• 课程/知识库站：希望用 Notion 维护会员名单和内容分层。
• 社区官网：希望展示成员资料，并逐步接入登录评论、资料页和轻量互动。

暂不优先服务：

• 高并发社区。
• 交易型会员平台。
• 多租户 SaaS。
• 需要复杂审批、积分、优惠券、分销和财务对账的商业系统。

设计边界

这条路线必须满足几个约束：

• 不影响最简单的博客部署。
• 不把 Clerk、Notion 评论或任何会员服务设为必选依赖。
• 能作为插件、适配器或示例存在的能力，不放进核心路径。
• 默认复用专业工具，只有站点深度绑定需求明确时才新增 NotionNext 侧实现。
• 文档要先讲“什么时候不需要它”，再讲“什么时候可以启用它”。

推荐架构

身份层

使用 Clerk 作为默认演示实现，但接口不绑定 Clerk，且不要求普通站点配置：

• 读取当前登录用户。
• 暴露 userId、email、name、avatar 等标准字段。
• 未配置登录服务时，保持现有公开站点行为。

后续可以让 Auth.js、Supabase Auth 或自建登录实现同一接口。

权限层

Notion 作为低频权限源，推荐新增或复用 Member 数据库字段。字段约定应服务于可选插件和示例站，不应让普通博客模板变复杂：

字段	用途
email	与登录账号匹配
clerkUserId	与 Clerk 用户 ID 精确匹配
status	Active / Inactive / Expired
role	member / editor / admin 等轻量角色
plan	free / pro / vip 等站点自定义等级
expiresAt	到期时间
allowedTags	可访问的内容标签

文章或页面侧推荐增加轻量字段：

字段	用途
access	Public / Login / Member / Role
requiredRole	需要的角色
requiredPlan	需要的会员等级
requiredTag	与会员 allowedTags 匹配

评论层

默认继续使用现有评论插件：

• Giscus、Utterances 适合 GitHub 生态和开源项目。
• Cusdis 适合轻量审核。
• Twikoo、Waline、Artalk 适合自托管、通知和管理后台。

只有在站点需要“评论必须绑定当前登录用户”和“评论由站点统一权限控制”时，才新增 Notion 评论适配。该适配应作为可选插件存在，并保持很小：

• 轻量公开评论场景已经由 NotionComments 覆盖：独立 Notion 评论数据库、昵称、邮箱识别、嵌套回复、手动审核状态和基础频率限制。
• 登录后提交评论。
• 写入 Notion Comments 数据库。
• 默认审核后展示。
• 只提供基础分页和删除/隐藏状态。

高流量评论、实时互动、复杂反垃圾和通知系统不放进核心，继续交给专业评论系统或自建数据库。

分阶段计划

阶段 1：收口现有登录演示

目标：让已有 Clerk 演示从“能登录”变成“可被可选插件复用”，不改变默认博客路径。

任务：

• 梳理现有 Clerk Provider、middleware、登录页和 dashboard 入口。
• 新增统一的当前用户读取函数。
• dashboard 或演示页显示当前登录用户和 Notion Member 状态。
• 未配置 Clerk 时保持现有站点不受影响。

验收：

• 配置 Clerk 后可以登录并进入 dashboard。
• dashboard 能显示来自 Notion 的会员状态。
• 不配置 Clerk 时不会影响普通博客部署。

阶段 2：会员权限读取

目标：让 Notion Integration 可以作为轻量权限后台，但只在启用会员插件时参与。

任务：

• 扩展 Member 官方 API 读取字段。
• 支持通过 clerkUserId 或 email 匹配当前用户。
• 提供 getCurrentMember 之类的服务端 helper。
• 增加最小测试，覆盖 active、expired、missing 三种状态。

验收：

• 站长可以在 Notion 修改会员状态。
• 服务端能稳定判断当前用户是否是有效会员。
• 不把 Notion 当实时交易数据库。

阶段 3：内容访问控制

目标：在可选模式下支持文章或页面按字段控制可见性。

任务：

• 定义 access、requiredRole、requiredPlan、requiredTag 字段约定。
• 在文章页服务端判断访问权限。
• 未授权时显示登录入口或会员提示。
• 保持公开文章、密码文章、隐藏评论等现有行为不破坏。

验收：

• Public 内容无需登录。
• Login 内容登录后可见。
• Member 内容只对有效会员可见。
• 权限不足时不泄露正文内容。

阶段 4：登录评论适配

目标：为深度绑定站点账号的场景提供最小评论插件，而不是替代现有评论生态。

任务：

• 定义 Notion Comments 数据库字段。
• 新增评论提交 API，要求登录。
• 写入评论时保存 postId、memberId、authorName、content、status。
• 前端新增可选 NotionComment 插件/组件。
• 默认只展示 Approved 评论。

验收：

• 登录用户可以提交评论。
• 站长可以在 Notion 审核评论。
• 现有第三方评论插件仍然可用。

阶段 5：文档、模板和预告

目标：让用户知道该用哪条路径，尤其是知道普通博客无需接入会员系统。

任务：

• 更新评论插件文档，说明评论、登录、会员的边界。
• 提供 Member 和 Comments 数据库模板说明。
• 写一篇从 Clerk 到 Notion Member 的配置教程。
• 在更新日志或大版本预告中说明这是可选能力，不是默认能力。

验收：

• 普通博客用户能继续只配置评论插件。
• 会员站用户能按教程逐步接入。
• 贡献者能按阶段拆 PR。

不做什么

短期不做：

• 内置支付。
• 订单和发票。
• 积分和分销。
• 多租户组织管理。
• 复杂 RBAC 权限矩阵。
• 评论实时聊天。
• 把所有评论插件替换成 Notion 评论。
• 让会员体系进入默认博客模板。
• 为了演示集成体验增加核心依赖。

这些能力可以通过外部系统、站点定制或后续适配器接入，但不应成为 NotionNext 核心路径的前提。核心要继续保持专一：读取 Notion 内容，渲染独立站点，并把扩展入口留给需要的人。

推荐的第一个实现切片

先做一个小闭环：

1. 登录后读取 Clerk 当前用户。
2. 用 email 或 clerkUserId 匹配 Notion Member。
3. dashboard 显示会员状态。
4. 一篇测试文章设置为 access = Member。
5. 未授权用户看到登录或会员提示。

这个切片足够验证插件化架构，但不会引入支付、订单、积分或完整评论系统。验证完成后，也应优先作为可选插件或示例文档交付。