如何为你的SaaS应用规划具备前瞻性的子域名结构

你终于为你的新SaaS应用想好了名字并购买了域名，令人兴奋的时刻！

你需要做的第一个技术决策之一，就是为各个Web属性选择合适的子域名。

你当然不想过早优化，但如果此时为不同的Web属性选择一组合理的子域名，将有助于你避免后续出现以下这些头疼的问题：

• 市场人员误操作导致应用路由出错
• 开发者修改导致营销站点样式混乱
• 管理复杂的重定向配置
• 应用架构中不得不引入反向代理
• SEO受损

让Web应用与营销站点分离

如果你是一个人既开发Web应用又负责撰写营销内容，可能会倾向于将两者放在同一个子域下。毕竟，这样可以共享CSS、Logo等资源，还能节省单独托管的费用。

但将来你可能会雇佣非技术的市场人员来添加或修改内容。为了让他们能独立高效地工作，你可能希望使用CMS（如Wordpress）。这通常需要独立的服务器，并且很可能与你开发Web应用所用的服务端技术（如Ruby/Rails、Nodejs/Express、Python/Django）不同。你也不希望在维护应用时影响到营销站点的可用性，或者因为修改应用的CSS规则而破坏营销站点的样式。

同一个子域还会让你无法选择用CDN托管静态营销网站，从而提升加载速度并降低托管成本。

为你的应用选择子域名

最简单的选择就是用 app，它不会过于限定用途，即使Web应用未来扩展也不会受限。B2B和B2C用户对此都很熟悉，许多知名服务如YNAB、Sendgrid和Optimizely都采用了这种方式。它还很简短，用户浏览器中的URL