SaaS 多租户的机制，之前拆开讲过不少：隔离策略、动态租户上下文、租户生命周期、套餐开关、计费模型——每个专题只管自己那一块。但真实做一个 SaaS 平台时，这些机制不是各管各的，而是在一条注册和使用的链路上互相咬合。
这篇就假想一个任务协作类 SaaS 产品（团队建任务、看板、统计报表），把这些机制放进一个完整系统里走一遍：一个租户怎么注册进来、请求进来怎么隔离、套餐怎么裁剪功能、到期那天发生什么。机制细节不展开，正文里随时链回对应的专题篇。
先看整体分层。一个多租户 SaaS 平台，和单体应用最大的区别是多了三个
上一篇《SaaS 多租户数据隔离》讲了字段级隔离的全景：租户插件自动改写 SQL，业务代码零感知。但“零感知”的前提是插件每改一条 SQL 都能答对一个问题——当前租户是谁。
这个问题看起来不起眼，其实被问得极频繁：一次分页查询，主表问一次、count 再问一次、每张关联表各问一次；一次页面渲染，几十条 SQL 就是上百次提问。而答案可能来自四个完全不同的地方——线程里、请求缓存里、Redis 里、token 里。**动态租户的实现，
想象一个场景：你把一套企业管理系统卖给 50 家公司用。每家公司都觉得自己“独享”这套系统——自己的员工、自己的资产、自己的单据，谁也看不见谁。而对你来说，只有一套代码、最好也只有一套数据库，不然 50 家公司的版本升级能把运维逼疯。
这就是 SaaS 多租户的核心矛盾：客户要隔离感，你要低成本。这套机制的难点不在“加个字段”，而在于：租户 ID 从哪来、怎么自动跟着每一条 SQL 走、缓存和登录态怎么隔离，以及运维人员临时“替某个租户干活”时怎么安全切换。
这篇基于 RuoYi-Vue-Plus 的租户模块（`ruoyi-comm
想象一个场景：你做了套企业管理软件，最早是一家客户一家客户地卖——装服务器、部署、培训、收钱，典型的传统软件生意。后来你想清楚了要做 SaaS：客户按月付费、打开浏览器就能用。第一家中型客户签了，第二十家也签了，直到有一天，一家银行说：“数据必须物理隔离，或者这单免谈。”
这时候你的架构怎么摆？这就是 SaaS 架构演进要回答的问题。这篇是 SaaS 系列的开篇，讲清整条演进路线的“为什么”，后面的租户隔离、生命周期、套餐计费都长在这条线上。
起步阶段最自然的做法：每个客户独立部署一套应用和数据库。
想象一个场景：月底对账，财务拿着报表来问——这个客户 8 月账单怎么算出来的？他 8 月 10 号从基础版升到专业版，补了差价；15 号又加了 5 个席位；隔壁那个按用量计费的客户调了 120 万次 API……三笔钱三套算法，对不上账。
这就是 SaaS 计费的全部难度所在：计费不难，“变化中的计费”才难。客户随时升级、降级、加减席位、退订，每一笔变更都要折算成公平的金额。这篇把套餐、订阅、计费模式与升降级结算一次讲清。
想象一个场景：一家公司注册了你的 SaaS，14 天试用期内录了 500 条数据，到期后没付费。三个月过去，这 500 条数据还躺在共享数据库里占着地方，他的租户还能登录吗？数据该删吗？如果第四个月他又回来了呢？
这就是租户生命周期管理的问题：租户从注册到离开，每个阶段“能干什么、数据怎么处理”，得有一套明确的状态机管着。隔离解决的是“租户之间看不见”，生命周期解决的是“一个租户的时间轴上的每个阶段怎么对待”。
一个典型的租户生命周期长这样：
![租户生命周期状态机](./saas-tenant-lifecycle.svg
操作系统层面的基础原理笔记。点击进入：
想象一次压测现场：接口 QPS 死活上不去，CPU 利用率却已经 90%+。打开 top 定睛一看，us（用户态）只占 40%，sy（内核态）却占了一半——CPU 忙了半天，一大半时间不是在跑你的业务代码，而是在替你跑内核的代码。
时间去哪了？要回答这个问题，得先搞懂这篇文章的主题：CPU 其实有两个"档位"，你的代码和内核的代码，各在其中一个档位上跑。这两个档位怎么划分、什么时候切换、切换为什么有开销，就是"用户态与内核态"的全部内容。
文末附一个能自己跑的实测程序：纯用户态操作和"进内核"操作，单次耗时差了四五个数量级。这不
想象一个场景：活动页上线，两个入口同时在扣同一份库存，各扣 10 万次，运营对账时发现账对不上——凭空少了一截。日志里没有任何报错，把请求单独重放一遍，每一笔又都是对的。这种“单看每一步都对，合在一起就是错”的问题，十有八九出在并发。
volatile、synchronized、AtomicInteger、线程池——这些东西平时都在用，但“各自到底解决什么问题、为什么要配合着用”，值得系统梳理一遍。这篇就按这条线走：先看多线程为什么会出事，再按“一个问题一把钥匙”讲每件工具，最后讲线程池怎么配。文中的示例代码都实际跑过（JDK 21），运
