# eshop-class2-group5

**Repository Path**: grade24-fullstack-class2/eshop-class2-group5

## Basic Information

- **Project Name**: eshop-class2-group5
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 6
- **Created**: 2026-07-21
- **Last Updated**: 2026-08-07

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 电子商城（E-Shop）暑期企业级综合项目实战

> 班级：____ 组号：____ 组名：____

## 一、项目简介

本项目为软件技术专业暑期企业级综合项目实战，目标是以小组协作方式，在 **4 周** 内完成一个功能完整、可演示、可部署的 **电子商城系统**，全程模拟企业真实研发流程：需求分析 → 系统设计 → 编码实现 → 测试 → 部署 → 验收答辩。

## 二、小组成员与分工（模块负责制）

本项目采用 **模块负责制**：不按前后端分工，每人认领业务模块，独立负责该模块的 **数据库表 + 后端接口 + 前端页面** 完整链路。

| 姓名 | 学号 | 角色 | 负责模块（全栈） |
|------|------|------|------------------|
|   史宗烁   |   2444310208   | 组长/架构员 | 项目脚手架、登录鉴权、公共组件、集成联调 + 1 个小模块 |
|   舒露瑶   |   2444310241   | 模块负责人 | 商品模块（分类/列表/搜索/详情 + 后台商品管理） |
|   陈智贤   |   2444310234   | 模块负责人 | 订单 + 支付模块（含后台订单管理） |
|   钟咏琪   |   2444310224   | 模块负责人 | 用户 + 购物车模块（含后台用户管理） |
|   均摊   |   均摊   | 模块负责人 | 测试 + 部署 + 选做功能 |

> 分工规则详见 `docs/00-项目要求/项目要求.md` 第三节，模块难度权重与考核挂钩。
> 4 人组时，测试与部署职责分摊到各模块负责人，选做功能由认领者负责。

## 三、技术栈（各组自选，确定后填写）

| 分层 | 技术选型 | 版本 |
|------|----------|------|
| 前端 |     Vue 3 (组合式API) + Vite (构建工具) + Pinia (状态管理) + Element Plus (UI组件库)     |  Vue 3 : 3.5.40，Vite : 8.1.4，Pinia : 3.0.4 ，Element Plus ：2.14.3 |
| 后端 |    Node.js (运行环境) + NestJS (后端框架)      |  Node.js： 24.18.0， NestJS：11.1.28， |
| 数据库 |     PostgreSQL (关系型主库) + Redis (缓存/会话库)   |  PostgreSQL16， Redis7.2 |
| ORM/数据驱动 |     Prisma (Node.js 的现代化 ORM)   |   Prisma ： 7.4.2  |
| 中间件/工具 |    订单超时取消：PostgreSQL 定时扫描（原消息队列方案已移除，详见 docs/02-设计文档/后端设计规划.md §5.3）    |   -   |
| 部署 |    Docker + Docker Compose (容器化编排) + Nginx (反向代理)      |   Docker Engine 29，Nginx 1.30.3   |

## 四、仓库目录结构

```
├── README.md                            # 项目说明（本文件）
├── 项目架构文档(不可进行更改).md          # 架构设计（教师发布，勿改）
├── docs/                                # 项目文档
│   ├── 00-项目要求/                     # 项目要求、验收标准、评分标准（教师发布，勿改）
│   ├── 01-需求文档/                     # 需求规格说明书
│   ├── 02-设计文档/                     # 架构设计、数据库设计、接口设计
│   ├── 03-测试文档/                     # 测试计划、测试报告
│   ├── 04-会议记录/                     # 小组会议纪要
│   ├── 05-总结答辩/                     # 项目总结报告、答辩材料
│   ├── strategy/                        # 战略治理（应急/微服务/培训）
│   ├── deployment/                      # 部署治理（生产/审批/应急流程）
│   ├── database/                        # 数据库设计文档
│   ├── performance/                     # 性能基线
│   └── DEBT_MANAGEMENT.md               # 技术债务登记（A-012）
├── reports/                             # 日报周报
│   ├── daily/                           # 日报（每人每天一份）
│   └── weekly/                          # 周报（每组每周一份，组长汇总）
├── frontend/                            # 前端代码（自行创建）
└── backend/                             # 后端代码 + 基础设施（自行创建）
    ├── src/                             # 后端源码（framework / common / core / modules）
    └── infra/                           # 基础设施
        ├── docker/                      # Docker Compose + Dockerfile
        ├── nginx/                       # 反向代理
        ├── env/                         # 环境变量示例
        ├── k6/                          # 性能压测脚本
        ├── monitoring/                  # Prometheus / AlertManager
        ├── scripts/                     # 一致性校验脚本
        └── monorepo/                    # pnpm / turbo / eslint / husky
```

> **架构说明**：所有部署 / 编排 / 工具配置已统一收纳到 `backend/infra/` 下，避免污染根目录。Monorepo 根配置在 `backend/infra/monorepo/`。`apps/` 目录保留旧的前端 API 服务层（向后兼容）。

## 五、关键时间节点（4 周）

| 阶段 | 时间 | 交付物 |
|------|------|--------|
| 第 1 周 | 需求与设计 | 需求规格说明书、架构/数据库/接口设计 |
| 第 2 周 | 核心功能开发 | 用户、商品模块可演示 |
| 第 3 周 | 完整功能开发 | 购物车、订单、支付（模拟）模块可演示；选做功能与挑战模块开发 |
| 第 4 周 | 测试、部署与答辩 | 测试报告、挑战模块压测/边界验证、部署上线、总结报告、答辩 |

## 六、Git 协作规范

1. 主分支 `main` 只存放可运行代码，禁止直接 push。
2. 功能开发使用 `feature/功能名` 分支，完成后经组长 Code Review 合并。
3. 提交信息格式：`<type>: <描述>`，type 取值：`feat` `fix` `refactor` `docs` `test` `chore`。
4. **每人每天至少一次有效提交**，提交记录将作为个人考核依据。
5. **交叉 Code Review**：每人的功能分支由相邻模块负责人审查后方可合并（审查人在合并说明中留名）。

## 七、如何开始

1. 全组阅读 `docs/00-项目要求/` 下的全部文档。
2. 完成分工表、确定技术栈并填入本文件。
3. 按 `docs/01-需求文档/` 模板开始编写需求文档。
4. 每天下班前提交个人日报到 `reports/daily/`。
5. **启动项目**：
   ```bash
   # 1. 启动基础设施（postgres + redis）
   cd backend
   docker-compose -f infra/docker/docker-compose.yml up -d

   # 2. 安装依赖
   cd infra/monorepo && pnpm install

   # 3. 启动后端（端口 3000）
   pnpm dev:server

   # 4. 启动前端（端口 5173，新终端）
   cd ../../../frontend && pnpm install && pnpm dev
   ```

## 八、多角色测试注意事项（DEC-C 决策 A）

**同一浏览器多标签共享 localStorage**：前端登录态（accessToken）与角色信息存放在 localStorage（按站点共享），同一浏览器开多个标签切换 admin / ceshi 等不同账号时，后登录的账号会覆盖前一个账号的会话，导致旧标签页操作 401 / 误用他人身份（参见 TEST-D10 / RT-DEBUG 结论）。

- admin（后台）与普通用户（商城）测试请使用**不同浏览器**或**隐身窗口**，避免会话互覆；
- 同一会话内切换角色时，请先退出登录再登录另一账号，并刷新旧标签页；
- WebSocket（/socket.io）使用登录时注入的 token，角色切换后旧连接需重新建立（重新打开对应页面即可）。