今天主要做的是项目上线前的收尾。功能没有大改，重点放在三端入口、运行环境和数据安全上。看起来都是部署工作，但真正操作下来，还是遇到了不少容易踩坑的地方。
一、拆分三端登录入口
商城分为买家端、商家端和管理端。之前三端共用一个登录地址，虽然能根据账号角色跳转，但使用时不够直观，也容易进错页面。
今天给三端分别增加了独立入口：
/buyer/login
/merchant/login
/admin/login
这三个地址没有各自复制一套登录页面，而是统一跳转到原来的登录逻辑，同时带上对应角色和登录后的目标页面。
这样既保留了一套认证代码，也让三端入口更清楚。后面即使修改登录校验，也不用同时维护三份代码。
二、重新部署前端服务
路由修改完成后，重新构建了前端 Docker 镜像，并单独替换了前端容器。
这次没有重建用户、商品、购物车、支付、订单和结算服务，更没有操作数据库。这样可以减少部署影响，避免为了改三个入口把整套服务全部停掉。
目前运行的核心服务包括：
- 用户服务
- 商品服务
- 购物车服务
- 支付服务
- 订单服务
- 结算服务
- 前端服务
容器启动后又检查了健康状态，七个服务都处于正常运行状态，前端的健康检查和就绪检查也能稳定返回。
三、打通公网访问
本地服务运行正常后，又把公网穿透地址接到了前端端口。
公网只需要一个基础地址，买家、商家和管理员通过不同路径进入对应端。这样比维护三个独立隧道省事，也方便后面统一配置支付回调、Cookie 和跨域策略。
三个入口已经分别验证过，访问后都会先跳到正确角色的登录页，登录成功后再进入对应系统。
四、确认原来的测试数据没有丢失
部署完成后最担心的问题，是替换容器会不会把之前积累的测试数据弄没。
实际检查后可以确认，这次替换的是前端容器，业务数据仍然保存在原来的 MySQL 中。容器本身不保存订单和商品数据，因此重新构建前端不会清空数据库。
今天重新执行了生产数据审计，当前主要数据如下：
用户：4 条
商品：30 条
订单：16 条
除了数量，还检查了订单与用户、订单项与商品、支付记录与订单、售后与投诉等关联关系，审计结果为 0 项失败。
发现的一条提示是数据库中还保留了演示账号。这在测试阶段没有影响，但正式对外上线前需要重新检查，避免演示账号继续留在生产环境。
五、补了一轮上线前安全检查
这次也顺便检查了数据库连接和服务运行配置。
数据库没有继续使用 root 账号，而是使用权限受限的应用账号；数据库连接启用了 TLS，服务之间仍通过 Docker 内部网络通信。公网只暴露前端端口，后端 RPC 服务没有直接开放到外网。
这些配置平时测试时感觉不到差别，但准备上线后必须处理。否则一旦数据库账号或内部端口暴露，后面再补救会比较麻烦。
今天的总结
今天没有继续堆新功能，而是把已经完成的业务真正跑进了接近上线的环境。
三端有了独立入口，Docker 服务运行正常，公网可以访问，原来的测试数据也完整保留。到这一步，项目已经不只是本地能打开的演示页面，而是一套能够持续运行和验证的电商系统。
接下来主要还剩三件事：固定访问域名、清理演示数据、补充数据库备份和运行告警。把这几项处理好之后，就可以进入正式上线后的持续维护阶段。
