客户域名在产品规划里听起来很简单：让每个客户都能使用自己的品牌 URL。
但真正做起来，它会牵涉 DNS、SSL、租户解析、客服流程、权限、状态和清理。如果太随意地上线，每个客户域名都会变成一个小型基础设施项目。
这篇文章讲 SaaS 团队在太早引入 tenant subdomain 或 customer domain 时，最容易犯的 5 个错误。
先给结论
最大的错误，是把客户域名当成一次性技术配置，而不是一个生命周期工作流。
你需要知道：
- 这个域名属于哪个租户。
- DNS 是否验证通过。
- SSL 是否启用。
- 它指向哪里。
- 谁能改目标地址。
- 最近是否还有访问。
- 客户流失后怎么处理。
错误一：tenant routing 还没理清，就急着做 custom domain
支持客户域名前，应用里最好已经有干净的 tenant resolution 层。
应用应该能从一个地方回答：
这个请求属于哪个租户？如果 tenant lookup 散落在 controller、middleware、前端路由和后台任务里，加 custom domain 会把混乱放大。
先集中到一个函数：
resolveTenant(request)再让这个函数逐步支持：
- Path slug。
- Tenant subdomain。
- Customer custom domain。
tenant resolution 抽象好了，custom domain 才不会变成重构灾难。
错误二：把 DNS 验证变成客服聊天
很多团队一开始会手动发说明：
请添加这个 CNAME，完成后告诉我们。前几个客户还可以。客户多了以后，客服会收到各种 DNS 提供商截图、配错的记录、未完成的配置，以及“现在好了没有”的追问。
更好的方式，是把验证做成可见状态：
pending_dns
dns_verified
ssl_pending
active
error
retired客户和客服应该能看到进度，而不是每次都问工程。
错误三：忘了目标地址以后会变
很多 customer domain 讨论只关注开通：
portal.customer.com -> app.yourplatform.com/customer但后面目标地址可能会变。
客户可能迁移 workspace，你们可能调整 app URL 结构，客户可能升级套餐，某些地区可能有独立目标，迁移期间也可能需要临时路由。
如果目标变化没有记录，客服迟早会问：
为什么这个客户域名指向这里？
从一开始就记录目标历史。
错误四：没想清楚客户流失后的下线
客户离开后，这个域名怎么办？
可选方案包括：
- 停用入口。
- 显示账号停用页。
- 指向客服页面。
- 保留一段宽限期。
- 到期后删除。
最差的方案是什么都不做，因为没人知道这个客户域名归谁管。
客户域名下线应该是 offboarding 的一部分，而不是事后想起来。
错误五：给内部工具过大的权限
如果客户域名通过内部脚本或 API 创建，权限必须控制。
不要让每个自动化都能创建、更新、停用和删除所有入口。
建议拆开：
- 租户创建。
- 域名验证。
- 目标地址更新。
- 报表读取。
- 入口下线。
每个系统只拿它需要的最小权限。
PushUlink 可以帮助团队通过 Console 和 OpenAPI 创建、统计、替换和下线托管子域名转发入口。
更好的客户域名工作流
一个实用流程可以是：
- 客户申请域名。
- 团队创建域名入口。
- 系统提供 DNS 配置说明。
- 跟踪 DNS 验证状态。
- 跟踪 SSL 状态。
- 分配目标地址。
- 域名进入 active。
- 监控访问和错误。
- 记录目标地址变更。
- 客户不再需要时下线。
这不是过度设计，只是把隐藏流程显性化。
FAQ
SaaS 早期都应该支持 custom domain 吗？
不一定。如果客户还没要求，tenant slug 或 tenant subdomain 可能已经够用。custom domain 会带来支持和运营成本。
tenant subdomain 是不是一个好的中间阶段？
很多时候是。tenant subdomain 可以先验证租户级路由，再支持客户自己的域名。
客户成功团队至少应该看到什么？
至少要看到域名状态、DNS 验证、SSL 状态、目标地址、owner、最近变更和近期流量。
小结
客户域名不是一个功能勾选项。
它是一个路由生命周期。越早把生命周期设计清楚，后面越容易运营。
