今天没有继续一股脑地加页面，而是把已经做出来的功能重新走了一遍。
这一走，问题还真不少：商家登录后进入了买家首页、购物车加完商品还是空的、订单支付成功却查不到数据、优惠券看得到但结算时不能用、后台侧边栏切换页面后菜单还会变化。
这些问题单独看都不大，但放在一起，项目就只能算“页面能展示”，还不能算“业务能跑通”。
所以今天主要做了一件事：按照真实电商的业务顺序，把买家、商家和管理员三端的主要链路重新串起来。
一、先把三类账号真正分开
项目目前有三种角色：
- 买家
- 商家
- 管理员
之前虽然已经有不同账号，但登录后的跳转并不准确。商家账号登录后仍然会先进入商城首页，管理员也是一样，需要自己再找后台入口。
这和正常系统的使用习惯不符。
今天重新调整了登录后的角色跳转：
- 买家登录后进入商城首页
- 商家登录后直接进入商家工作台
- 管理员登录后直接进入平台管理后台
同时，商家和管理员页面都增加了权限校验。仅仅隐藏前端菜单是不够的，直接在地址栏输入后台路径时，也必须检查当前账号角色。
这部分做完之后，三端才算真正分开，而不是只换了三个不同的账号名称。
二、重新打通购物车到订单的完整流程
买家端今天重点检查了下面这条链路：
浏览商品
→ 加入购物车
→ 修改购买数量
→ 删除商品
→ 提交结算
→ 选择支付方式
→ 创建订单
→ 支付完成
→ 订单中心查看
购物车现在支持：
- 商品数量增加
- 商品数量减少
- 删除单个商品
- 实时计算商品小计
- 实时计算购物车总金额
之前遇到过一个比较明显的问题：页面提示加入购物车成功，但打开购物车后没有数据。
最后发现不能只看前端按钮有没有响应，还要继续检查用户 ID、购物车 RPC、Redis 数据以及购物车查询接口是不是使用了同一个用户上下文。
修复后，购物车中的商品能够正常带到结算页，支付完成后也会清空购物车，并生成对应订单。
三、支付不再只是一个“成功页面”
支付部分目前接入了：
- 支付宝沙箱
- 模拟银行卡
- 微信支付演示入口
- 云闪付 / 银联演示入口
支付宝沙箱已经完成了基本闭环：
商城创建订单
→ 生成支付宝支付地址
→ 跳转沙箱收银台
→ 用户完成支付
→ 支付宝同步回跳
→ 支付宝异步通知
→ 校验签名和金额
→ 更新订单支付状态
支付回调不能收到请求就直接把订单改成已支付，至少还要检查：
今天也重新配置了内网穿透地址，用于接收支付宝的同步回跳和异步通知。
模拟银行卡则使用固定测试卡号，避免开发测试时填写真实银行卡信息。
四、订单终于能正常保存和查询了
之前出现过支付完成后订单中心没有数据的问题。
这种问题最容易误判成“前端没刷新”，但实际上需要从订单创建开始逐层排查：
- Checkout 服务有没有成功创建订单；
- 订单有没有绑定当前买家；
- 商品明细有没有写入；
- 支付状态有没有更新；
- 订单列表查询是否使用了正确的用户 ID；
- 页面有没有把 RPC 返回的数据正确转换出来。
修复后，买家可以在订单中心查看：
- 订单编号
- 下单时间
- 商品明细
- 购买数量
- 实付金额
- 当前订单状态
- 收货信息
- 支付方式
商家端也能看到对应订单，并继续执行发货操作。
五、补齐商家履约和平台管理功能
买家下单只是电商流程的开始，后面还要有商家履约和平台治理。
今天完善了商家端的几个主要模块：
- 经营概览
- 商品管理
- 订单管理
- 售后管理
- 投诉举证
商品管理支持新增、编辑、库存调整和上下架；订单管理支持查看买家订单并进行发货；售后管理可以处理买家的退款或退货申请。
管理员端目前包括：
- 平台经营概览
- 用户与角色管理
- 商品审核
- 消费者保障
- 投诉与纠纷处理
过程中还修了一个菜单问题：进入订单管理或者售后管理后，左侧菜单数量会发生变化，有时还会出现两个“经营概览”。
最后把商家后台和管理员后台的侧边栏统一成公共模板，避免每个页面单独维护一份菜单。
六、会员、积分和优惠券不再只是静态页面
今天新增并完善了会员中心，包括：
- 会员等级
- 成长值
- 可用积分
- 积分兑券
- 优惠券包
- 优惠券分类筛选
- 会员规则
- 结算页使用优惠券
这里专门确定了成长值的业务规则：
成长值来自订单消费，不是充值会员获得。
当前规则为：
订单支付成功后：
1 元实付金额 = 1 成长值
1 元实付金额 = 1 积分
会员采用成长等级制，不单独售卖“充值升级”。
后续如果订单取消或发生退款，还需要按照退款金额扣回对应的成长值和积分。
七、优惠券必须真正影响订单金额
优惠券一开始只做了券包和“去使用”按钮，但这并不算完成，因为结算页没有选择入口，支付金额也没有发生变化。
今天把优惠券接进了完整结算流程。
结算页现在会展示：
- 当前可用优惠券
- 不可用优惠券
- 不可用原因
- 商品金额
- 优惠券优惠金额
- 最终实付金额
服务端会再次校验：
- 优惠券是否属于当前用户；
- 是否已经使用；
- 是否被待支付订单占用；
- 是否已经过期；
- 是否达到使用门槛；
- 商品品类是否符合要求；
- 优惠金额是否合理。
结算 RPC 也增加了优惠券字段：
message CheckoutReq {
uint32 user_id = 1;
string firstname = 2;
string lastname = 3;
string email = 4;
Address address = 5;
payment.CreditCardInfo credit_card = 6;
string coupon_code = 7;
float coupon_discount = 8;
}
优惠金额不仅在页面上显示，还会同时影响：
- 订单商品实际金额
- 支付服务扣款金额
- 支付宝订单金额
- 订单中心展示金额
今天实际跑了一笔测试订单：
商品金额：798 元
优惠券：满 199 减 20 元
实付金额：778 元
获得成长值：778
支付完成后，订单中心正确显示 778 元，对应优惠券变为“已使用”，成长值也增加了 778。
这一遍跑通之后，优惠券才算真正完成，而不是只做了一个好看的页面。
八、今天遇到的几个实际问题
今天修复的问题里，有几个比较有代表性。
1. 只做前端跳转，不等于权限隔离
不同角色不仅需要不同首页，后端路由也必须检查角色，否则用户直接输入地址仍然可能进入不属于自己的页面。
2. 页面金额变化，不等于订单真的优惠了
优惠金额必须一直传到订单服务和支付服务。只在 JavaScript 中把数字减掉，没有任何业务意义。
3. 支付成功，不代表订单流程完成
支付成功后还要继续处理：
- 更新订单状态；
- 核销优惠券；
- 发放积分；
- 发放成长值；
- 清空购物车；
- 记录支付流水。
其中任何一步失败，都需要能够查日志和补偿。
4. 后台菜单不要每个页面复制一份
复制出来的菜单短期方便，后期很容易出现某个页面多一栏、某个页面少一栏。统一模板之后，维护成本低了很多。
5. 时间格式也可能藏着小坑
优惠券有效期最开始使用了错误的 Go 时间格式，导致页面出现异常时间。后来统一成日期加固定的 23:59，同时对 Redis 中已有的旧数据做了兼容处理。
九、目前项目的整体结构
目前项目使用的主要技术包括：
- Hertz：前端入口和 HTTP 服务
- Kitex：微服务 RPC 调用
- MySQL：用户、商品、订单等业务数据
- Redis：会话、购物车、会员积分和优惠券数据
- 支付宝沙箱：支付流程联调
- Go Template：商城和后台页面渲染
主要业务模块包括：
用户服务
商品服务
购物车服务
结算服务
订单服务
支付服务
会员服务
商家后台
管理员后台
售后与投诉
现在已经不只是几个独立页面，而是能够从买家下单一直走到商家履约和平台处理。
十、接下来准备继续做什么
目前主流程已经能跑，但距离完整电商系统还有不少细节。
下一步准备继续补：
今天最大的进展不是又增加了多少页面，而是把几个原本分散的功能真正串了起来。
一个电商项目是否完整，不能只看首页漂不漂亮，而是要看用户下单之后，订单、支付、优惠券、积分、商家履约和后台管理能不能对得上。
目前第一条完整业务链路已经跑通，后面继续沿着订单生命周期往下完善。
