4. 租户入驻与初始化

租户入驻是 SaaS 多租户系统真正开始运转的起点。它并不是“让用户填个表单”这么简单，而是一条从身份建立到租户空间可用的完整链路：用户以自助注册或邀请方式进入系统，完成企业认证，系统为其创建租户、分配套餐与配额，再通过一组初始化任务把组织、角色、字典、示例数据等基础资源准备好。只有这条链路闭环，租户才具备“可登录、可配置、可协作”的初始状态。

一、两条入驻入口：自助注册与邀请入驻

自助注册面向公开获客场景。访客在注册页提交企业邮箱、手机号、企业名称与管理员密码，系统先做邮箱/手机号唯一性校验，再创建“待认证租户”记录，状态置为 PENDING_VERIFY。此时租户空间已存在，但功能受限，仅允许管理员登录完成认证与初始配置。

邀请入驻面向销售或客户成功驱动的场景。运营人员在后台创建邀请码，绑定目标企业名称、套餐、有效期与邀请人。被邀请人通过邀请链接进入，系统跳过公开注册的验证码环节，直接关联预置租户，减少重复录入。两种入口最终都汇聚到同一套“租户创建 + 初始化编排”流程，区别只在入口校验与租户来源标记。

二、企业认证：从待认证到已认证

企业认证决定租户能否解锁完整能力。常见认证方式包括：营业执照上传 + 企业名称/统一社会信用代码比对、对公打款验证、法人实名核验。系统在认证表中记录认证类型、提交材料、审核状态与审核人。审核通过后，租户状态由 PENDING_VERIFY 流转为 ACTIVE，并触发套餐权益生效。

认证状态建议设计为独立状态机，而不是直接复用租户主状态，因为认证可能被驳回、过期或需要重新提交。典型状态包括：UNSUBMITTED、SUBMITTED、APPROVED、REJECTED、EXPIRED。驳回时必须记录驳回原因，便于前端展示与用户重新提交。

三、初始配置：租户级参数与配额

租户创建后，系统需要写入一批初始配置，这些配置决定租户的默认行为。常见配置项包括：默认时区、默认语言、数据保留天数、是否开启双因素认证、默认角色模板、套餐配额（用户数、存储空间、API 调用量）。这些配置应集中存放在租户配置表中，避免散落在业务表里。

配额需要与套餐绑定。例如免费版默认 10 个用户、5GB 存储、每月 1 万次 API 调用；专业版默认 100 个用户、100GB 存储、每月 100 万次 API 调用。初始化时把套餐对应的配额快照写入租户配额表，后续用量统计与超限拦截都基于这份快照。

四、数据初始化任务编排

初始化不是一次数据库插入，而是一组有依赖关系的任务。典型任务包括：创建租户主记录、创建管理员账号、初始化角色与权限、写入字典与枚举、创建默认组织架构、导入示例数据、发送欢迎邮件、记录初始化日志。这些任务之间存在先后依赖，例如“创建管理员账号”必须在“创建租户主记录”之后，“初始化角色与权限”必须在“创建管理员账号”之前或同时完成。

推荐用任务编排表来管理，每个任务有 task_key、status、retry_count、error_message、started_at、finished_at。任务状态包括 PENDING、RUNNING、SUCCESS、FAILED、SKIPPED。失败任务可重试，重试次数超过阈值则标记为 FAILED 并告警，避免租户长期停留在半初始化状态。

五、初始化失败与幂等设计

初始化任务必须支持幂等。每个任务在执行前先检查是否已完成，已完成则直接跳过。例如“创建管理员账号”任务先按租户 ID 查询管理员是否存在，存在则标记 SKIPPED。这样即使任务被重复触发，也不会产生重复数据。

失败处理上，建议把任务分为“可重试”和“不可重试”两类。网络超时、邮件发送失败属于可重试；租户 ID 冲突、套餐不存在属于不可重试，需要人工介入。重试策略可采用指数退避：第 1 次间隔 5 秒，第 2 次 30 秒，第 3 次 5 分钟，超过 3 次则告警。

六、初始化完成后的验收

初始化完成后，系统应提供一个“租户就绪检查”接口，返回各任务状态与整体结果。运营人员可据此判断租户是否可交付。验收要点包括：租户状态为 ACTIVE、管理员可登录、角色权限已写入、字典数据完整、配额已生效、欢迎邮件已发送。若任一关键任务失败，租户应标记为“初始化异常”，并在后台提供一键重试入口。

整体来看，租户入驻与初始化的核心不是单点功能，而是状态流转 + 任务编排 + 幂等重试三者的配合。把入口、认证、配置、初始化任务拆清楚，才能让租户从“注册成功”真正走到“可正常使用”。