基于 Gin 与 Nuxt 的跨境电商独立站

一、项目背景与一句话

1.1 企业级迁移背景（广东真格软件有限公司）

本项目不是从零拍脑袋的玩具 Demo，而是建立在本人于 广东真格软件有限公司实习期间接触的企业级电商 / 跨境电商中后台真实业务之上：熟悉商品多规格与 SKU、订单全链路、运营侧 RBAC、内容与推荐位等在生产环境中的落地方式。公司侧原技术栈以 Java 生态承载后台服务为主。

在毕业设计阶段，我在对齐同一业务域与接口契约思维的前提下，将服务端从 Java 企业栈迁移为 Go 实现：采用 Go + Gin + GORM 重写（或等价迁移）领域服务与 REST 分层，保留「可运营、可支付、可审计」的工程标准，同时利用 Go 编译型单二进制、部署简单、并发模型清晰等优势，完成一次栈级迁移与再设计——这也是简历与面试中可单独展开的一条故事线：为何从 Java 迁到 Go、域模型如何平移、认证与支付等横切能力如何重组。

1.2 项目一句话（电梯演讲）

独立设计并实现了一套跨境电商独立站：Go + Gin 提供统一业务与支付能力，Vue 3 + Ant Design Vue 承担运营侧管理后台，Nuxt 4 + Nuxt UI 承担 C 端 SSR 商城。打通「商品上架 → 前台展示 → 加购下单 → PayPal 支付 → 订单履约与退款」闭环，并针对管理端 Session 与前台 JWT + 设备指纹做了双轨认证，适合多角色、多端部署场景。

个人角色（可按投递岗位改写）：全栈 / 后端为主 / 前端为主 —— 含企业级业务理解 + Java→Go 服务端迁移/重写、后端分层与路由规划、管理端 RBAC 与核心业务模块、前台 SSR 与 Docker 下双 BaseURL 配置、支付与邮件通知联调等。

二、情境与目标（STAR · Situation / Task）

情境：毕业设计需要覆盖与企业实习同级的真实业务复杂度，而非 Demo 级 CRUD；跨境电商场景要求支付、订单状态、内容与商品模型可运营。本人在真格软件期间已积累对电商域模型与运营后台的认知，本仓库将后台实现路径切换为 Go，以完成技术栈上的闭环验证。

情境补充（迁移维度）：需在脱离原 Java 代码依赖的情况下，用 Go 重新落地双端认证、订单与支付、OSS 与配置等横切能力，并保证管理端与 Nuxt 前台可稳定联调。

任务：

1. 设计可维护的后端分层与数据库模型，支撑商品 SKU、订单、用户、CMS、支付日志等领域。
2. 交付可用的管理后台，使运营能录入商品、处理订单与退款、维护站点与内容。
3. 交付对 SEO 与首屏友好的前台商城，并与同一套 Client API 严格对齐。
4. 前台技术栈统一到 Nuxt UI，降低 UI 碎片化与暗色/无障碍适配成本（相对早期自拼组件方案）。

结果：三子系统可独立构建与部署；接口覆盖管理端与客户端两大前缀；本地与 Docker 下均可联调（MySQL + Redis + Backend + 多前端服务）。

三、系统架构（面试可画图）

flowchart LR
  subgraph web [前台_zhuyi_store]
    NuxtSSR[Nuxt4_SSR]
    NuxtUI[NuxtUI4]
  end
  subgraph admin [管理端_shop_admin]
    Vite[Vite_SPA]
    AntDV[AntDesignVue]
  end
  subgraph api [服务端_server]
    Gin[Gin_API]
    MySQL[(MySQL)]
    Redis[(Redis)]
    PayPal[PayPal]
  end
  web -->|"/api/client"| Gin
  admin -->|"/api/manage"| Gin
  Gin --> MySQL
  Gin --> Redis
  Gin --> PayPal

• 通信方式：前后端分离，JSON REST；全局 CORS；静态上传走 /api/oss。
• 部署：docker-compose 编排 MySQL、Redis、Backend；前台容器通过环境变量区分浏览器访问后端的地址与 SSR 容器内访问后端的地址（见下文「难点」）。

四、模块一：前台 Web（zhuyi-store）

4.1 技术栈

• 框架：Nuxt 4、Vue 3、TypeScript
• UI：Nuxt UI 4、Tailwind CSS 4
• 质量：ESLint（@nuxt/eslint）
• 请求：自封装 HttpRequest（$fetch），统一携带 Cookie 中的 accessToken 与请求头 X-Device-Fingerprint，与后端 DeviceFingerprintMiddleware 对齐

4.2 功能清单（与 app/pages 一致）

组合式逻辑：useCartShared 等实现购物车数量等跨页共享，避免重复请求与状态分裂。

4.3 难点与解法（STAR · Action）

难点：Docker 部署时，浏览器访问后端常用 localhost:8080，而 Nuxt SSR 在容器内访问后端需使用服务名（如 http://backend:8080）。单一 baseURL 会导致构建期预渲染或 SSR 请求失败或指向错误主机。

解法：在 nuxt.config.ts 的 runtimeConfig 中拆分 apiUrl（仅服务端） 与 public.apiUrl（浏览器），分别由 NUXT_API_URL 与 NUXT_PUBLIC_API_URL 注入；请求封装在服务端渲染分支读取 config.apiUrl，在客户端读取 public.apiUrl。首页等关键路由按需使用 ssr: true，保证容器内可拉到真实数据。

4.4 诚实边界（避免面试过度承诺）

• 登录页存在「忘记密码」类导航入口时，若仓库中尚未落地独立找回密码页，面试应表述为「可接邮件重置链路 / 预留路由」，而非「已全链路实现」。
• 商品详情若存在指向标签聚合的路径，而未单独实现标签列表页时，宜表述为「详情展示标签 + 可扩展标签频道」。

五、模块二：管理端（shop_admin）

5.1 技术栈

Vue 3、Vite、Ant Design Vue 4、Pinia、TypeScript、Axios；富文本（WangEditor、Quill）、图片裁剪（Cropper）、表格导出（xlsx）、数据可视化（ECharts）等。

5.2 功能清单（与路由模块一致）

• 商品管理：商品列表、录入/编辑、类目树、商品属性与属性值（支撑多规格 SKU）。
• 订单管理：订单列表、状态更新、发货、退款申请与处理；独立退款列表页。
• 内容管理（CMS）：文档（博客）管理、标签、推荐位与推荐位内容管理。
• 站点管理：商店设置、站点信息。
• 系统管理：管理员、部门、角色、权限（RBAC）、前台用户（MP User）；字典相关子页等。

5.3 难点与卖点（STAR · Action / Result）

• RBAC 落地：后端权限模型与前端路由 meta.permission、自定义指令（如 v-permission）配合，实现菜单级 + 按钮级控制，降低误操作面。
• 复杂表单与资源编辑：多规格 SKU、富文本详情、图片上传与裁剪，考验状态拆分与提交流程设计，可直接作为简历中「中后台复杂表单」案例。

六、模块三：服务端（server）

6.1 技术栈与迁移说明

Go 1.24、Gin、GORM、MySQL、Redis、Viper、JWT、PayPal SDK、gomail 等。

与 Java 企业后台的对照：在真格软件阶段熟悉的典型 Java 后端分层（Controller / Service / DAO 等）与中间件思维，在本项目中映射为 Gin Handler → Service → Repository，依赖注入由 ServiceFactory / RepositoryFactory 承担，便于在迁移过程中按模块逐项对照域模型与边界，而非简单「翻译语法」。

6.2 路由与职责边界

支付：对接 PayPal Sandbox，支持创建订单与捕获；路由中可预留 Webhook；管理端侧支持退款相关能力；支付结果可配合邮件通知（gomail）。

6.3 架构与扩展性

• 分层：Handler → Service → Repository，依赖通过 ServiceFactory / RepositoryFactory 注入，业务与持久化解耦，便于单测与替换实现。
• 数据层：30+ 张业务表量级（商品含 SKU/属性/属性值、订单、用户、CMS、支付日志等），索引与关联按领域建模。

6.4 个人可强调的贡献表述示例

• 「我负责把 Client / Manage 两套认证 从需求拆成中间件与路由组，并保证前台请求头与设备指纹策略一致。」
• 「PayPal 流程与订单状态、邮件通知的时序由我联调并通过 Sandbox 验证。」
• 「在真格软件熟悉 Java 侧电商后台后，毕业设计中将同域能力用 Go 按 Handler-Service-Repository 再实现一遍，并打通双端认证与支付。」

（请按你实际参与比例增删。）

七、技术亮点速查表

八、量化成果（简历数字栏可直接摘）

• 子系统：3 个（管理后台、SSR 前台商城、后端 API）联调可用。
• 企业背景：业务域与工程标准对齐 广东真格软件有限公司实习所接触的企业级电商；服务端为 Java 企业栈 → Go + Gin 的迁移/重写实现。
• 接口规模：合计 100+ RESTful 接口量级（管理端 60+、客户端 40+ 为经验区间，以实际 router 统计为准可再精确）。
• 后端：约 150+ Go 源文件，30+ 数据模型。
• 管理端：约 80+ 组件与页面，10+ 业务模块。
• 前台：10 个左右核心页面（首页、集合、详情、购物车、结算、订单详情、登录、注册、地址、博客等）。
• 认证方式：2 套（Redis Session + JWT 体系），管理端 Token 多来源提取等能力便于网关或反向代理场景。

九、结语（博客收尾）

本项目把「能卖货的独立站」拆成可运营的后台、可转化的前台与可演进的后端；其底色是广东真格软件有限公司期间接触的企业级电商实践，并在毕业设计中用 Go 重写后台完成与 Java 时代的能力对齐与栈升级。在认证、支付、SSR 部署等真实工程痛点上给出了可落地的方案。若你投递全栈 / 后端 / 前端，可分别放大模块三（尤其 Java→Go 迁移动机与分层映射）、模块一或模块二的篇幅，并在面试中用一条主流程（如下单支付）把三个模块串讲，印象分通常高于罗列名词。