北京
给一家本地出租车公司做网站，最难的部分往往不是设计。有时候，难的是确保访客打开域名时，看到的确实是你想给他看的那个网站。
这次的项目是给 Din Borlänge Taxi AB 做一个站点。目标很直接：让访客看懂服务内容、查到价格，然后要么打电话，要么直接提交预约请求，不用在页面上到处找下一步该点哪里。听起来像是个纯前端活儿，做下来却变成了一堂关于路由和部署的课。
先想清楚访客要知道什么
动手写组件之前，先列出访客可能冒出来的问题：你们服务我所在的区域吗？这趟大概要多少钱？能在线预约，还是只能打电话？信息有没有我读得懂的语言版本？
这些问题决定了站点的结构：一个清晰的主页，服务页和价格页，联系方式，再加一条预约流程。瑞典语和英语的支持从一开始就写进设计里，而不是等做完再往上补。
前端用 React 和 Vite 搭建。预约表单和联系表单把请求发到一个独立的 Node API，由服务端做校验。这一点很关键：浏览器端的检查能改善体验，但不能当成唯一的校验手段。
域名验证不等于网站已发布
域名已经验证过了，按理说出租车公司的站点应该出现在上面。但打开线上域名一看，显示的是项目里另一个已经存在的应用。出租车站点原来的路径则返回 404。
这里暴露出几个容易混淆的概念：
- 域名验证，确认的是 DNS 指向了 Replit。
- 发布，是把某个具体的项目构建推到线上。
- 路由，决定某个 URL 的请求由哪个应用来处理。
这是三个独立的步骤。域名可以处于已验证状态，而你打算展示的站点还没接管首页。
给每个应用分配明确的路由
这个项目里不止一个 Web 应用。一个叫 Daylight 的个人效率面板已经占着根路由。出租车站点此前被配置在 /din-borlange-taxi/ 下面。
我希望出租车站点成为首页，同时不删掉 Daylight，于是重新分配了路由：Din Borlänge Taxi 使用 /，Daylight 保留在 /daylight/，出租车 API 使用 /taxi-api/api。
给 API 单独加前缀，是为了避免出租车请求和项目共用的 /api 混在一起。路由表也因此更好理解：首页服务出租车站点，它的后端有自己的命名空间。
站点基路径和 API 基路径要分开
过程中遇到一个很隐蔽的 bug。应用把同一个基路径变量同时用于 API 请求和客户端路由。改了 API 前缀之后，路由开始把 /taxi-api/ 当成网站的基路由，页面直接白屏。
修法是让这两个概念各自明确：路由基路径控制前端识别哪些网站路径，API 基路径控制表单请求发往哪里。两个字符串看起来可能很像，职责却完全不同。分开之后，应用能在根路由正常工作，同时请求仍然发往专用的 API 路径。
验证整条链路，而不只是构建
构建成功，并不能证明网站在目标 URL 上可达。我检查了前端构建、API 测试和 API 健康检查端点，也打开了实际的预览页面，这才发现那个构建本身不会暴露的白屏路由问题。
这改变了我对“做完”的定义。多应用项目里，验证至少要覆盖：预期的首页能不能加载？其他应用在各自路径上是否还能打开？前端能不能连上自己的 API？发布之后，线上域名显示的是不是预期的构建？
目前路由改动在项目预览里工作正常。自定义域名还需要重新发布一次，才能带上这些改动。
接下来要补的东西
在把站点交给真实客户请求之前，还得把业主侧的工作流做完：确保预约信息得到妥善保护，有新请求时通知业主，表单需要修正时给客户更清楚的即时反馈。
这次搭建最大的收获很简单：组件能渲染出来，网站不算完成。正确的站点在正确的地址上，能完成访客来这一趟想做的事，才算完成。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
