大多数早期 SaaS 团队会先问一个表面问题：
每个租户应该用 slug、subdomain，还是 custom domain？
这是一个好问题，但不是全部。
更深的问题是：
随着产品增长，团队准备怎么管理所有租户入口？
快速回答
Tenant URL strategy 不只是路由选择，它会变成一层运营系统，覆盖 tenant resolution、subdomain 命名、wildcard DNS、custom domain 验证、owner、TLS、状态、客服、统计和 offboarding。早期可以简单，但要尽早集中 tenant entry management，让产品未来能从 path slug 演进到 tenant subdomain 和 customer custom domain，而不是到处散落逻辑。
决策对比表
| 阶段 | URL 模式 | 运营需求 |
|---|---|---|
| 原型期 | /tenant/menu | 集中 tenant resolution。 |
| 早期 SaaS | tenant.example.com | 管理命名、路由和客服支持。 |
| 增长期 SaaS | customer.com 或 app.customer.com | 增加验证、状态、TLS 和 offboarding。 |
| 成熟平台 | 多种入口混合 | 需要 inventory、owner、API 自动化和生命周期控制。 |
为什么这个问题一直出现
多租户 SaaS 天然会积累入口。
一开始，tenant 只是数据库里的一行。后来 tenant 需要 workspace URL。再后来客户希望 URL 更品牌化。再后来销售会问企业客户能不能接自己的 domain。最后客服需要知道为什么这个 tenant URL 能打开，另一个打不开。
Microsoft Azure Architecture Center 介绍多租户应用里的 domain name 时提到，domain 可以用于区分租户、路由请求、提供品牌化体验；同时也会带来 subdomains、wildcard DNS、custom domains、validation、dangling DNS 和 TLS certificates 等取舍。
这才是重点：URL 不是字符串，而是租户运营的一部分。
Slug vs Subdomain 只是第一个选择
Slug 早期更简单：
app.example.com/acmeTenant subdomain 会让租户身份更清楚：
acme.example.comCustom domain 给客户更强品牌控制：
portal.acme.com但当 SaaS 团队支持不止一种模式时，就需要稳定的 tenant entry model。
这个模型要回答：
- 这个入口属于哪个 tenant？
- 当前 active 的 domain 或 subdomain 是什么？
- route 到哪里？
- ownership 是否验证？
- TLS 是否 ready？
- 谁可以改？
- 最后一次检查是什么时候？
- tenant churn 后怎么办？
没有这一层，tenant URLs 很快会变成客服工单。
没有 Tenant Entry Management 会发生什么
常见问题包括：
- 客户要 custom domain，但没人知道流程
- CNAME 指向旧环境
- 租户迁移区域后，入口还指向旧地方
- sales demo URL 永远活着
- trial workspace 删除了，但 subdomain 还解析
- 客服分不清问题是 DNS、TLS、routing 还是 app logic
- 只有工程团队能回答 URL 相关问题
这些不是极端情况，而是 SaaS 增长后很普通的日常。
最小 Tenant Entry Model
至少要记录：
- tenant ID
- entry hostname
- entry type：slug、subdomain、custom domain
- target 或 route
- status
- owner
- verification state
- created date
- last changed date
- last seen traffic
- offboarding state
第一天不需要巨大平台，但团队要停止把 URL 当成散落配置。
API 自动化为什么重要
当 tenant creation 自动化后，tenant entry creation 也应该自动化。
例如：
- 新客户注册。
- 应用创建 tenant record。
- 应用通过 API 请求 tenant entry。
- entry 以 draft 或 active 状态创建。
- 客户收到正确 onboarding URL。
- 客服可以看到 entry status。
- tenant churn 后，entry 可以下线。
这时 subdomain forwarding 已经不是 DevOps 小事，而是产品生命周期的一部分。
PushUlink 适合放在哪里
PushUlink 帮 SaaS 和运营团队通过 Console 和 OpenAPI 创建、统计、替换和下线 tenant-style subdomain forwarding entries。
Pushulink 目前处于 MVP 阶段，专注于托管子域转发、OpenAPI 自动化、访问统计、权限边界、日志和可追踪操作。
它不是替代你应用里的 tenant resolver，而是管理租户体验前面的业务入口层。
常见问题
早期 SaaS 应该先用 slug 还是 subdomain？
大多数早期产品可以先用 slug，除非租户品牌、公开分享、cookie 边界或未来 custom domain 已经很重要。关键是从第一天集中 tenant resolution。
什么时候 custom domain 值得做？
当客户需要品牌 URL、企业信任或自己的 domain 出现在用户路径中时，就值得做。但它会增加验证、TLS、客服和 offboarding 工作。
wildcard DNS 够不够？
不够。wildcard DNS 能帮助路由很多 subdomains，但不能回答 owner、status、verification、lifecycle、statistics 和 support 问题。
tenant 离开后入口怎么办？
应该按策略禁用、重定向或归档入口，并检查 custom domain records，避免 dangling DNS 风险。
