项目在这：github.com/lindaailabs/tenant-grid。Apache 2.0，Java 17 起，Spring Boot 3.5 和 4.x 都能用，212 个测试，CI 常驻跑着。下面不是功能介绍——README 里写得够全了——想聊的是几个设计上反复权衡过的点。先交代背景第一次正经面对多租户数据放置是在海外仓 SaaS 项目上。当时的方案很朴素：一个租户一个库。隔离是真的彻底，出问题也好查，但几年下来长尾客户的数据库成本越来越扛不住，而且迁库、共享库隔离、按租户排查这些杂活全靠手工。后来一直在想这个问题有没有更好的解法。答案其实业内都清楚：混合分治。大客户独占物理库保 SLA，长尾进共享库靠tenant_id分片摊成本。麻烦的不是分治本身，是围着它转的一圈事：新客户入驻要热加数据源；小卖家涨成大客户要不停服迁库；共享库里一个租户的慢查询能拖死同库所有人；库慢了要能定位到是哪个租户在搞事。这些活没有现成轮子。ShardingSphere 解决的是表级分片——SQL 解析、改写、跨库归并，而这里一次请求只落一个库，tenantId → DataSource就完了。为了一个路由引入整套 SQL 解析引擎，背它的兼容性清单，不划算。dynamic-datasource 那类只管切数据源，租户模型、迁移、隔离都没有。于是自己写了一个。比较意外的是，这个「不依赖」反而换来了组合的自由：共享库内部如果还要按月分表，把 ShardingSphere 包出来的数据源直接注册进来就行。tenant-grid 只认DataSource抽象，底下是 HikariCP 还是别的什么它不管——它管租户落在哪个库，分表的事归分表工具管。用起来什么样配置声明数据源、逻辑分组和租户归属：tenant-grid:strict:truedatasources:ds_vip_1:{url:jdbc:mysql://vip-db:3306/vip1,...}