软件需求规格说明书（SRS）

• 项目名称：Nomad
• 版本：v0.1
• 日期：2025-09-21

1. 项目介绍

1.1 背景

Nextrip 是一个在线旅行预订平台，旨在为用户提供便捷的航班、酒店和租车服务预订体验。项目模仿主流 OTA（Online Travel Agency）平台如携程、Expedia 等，专注于提供完整的旅行解决方案。

1.2 目标

构建一个功能完整、用户友好的在线旅行预订平台，提升用户的旅行规划和预订体验。

2. 总体概述

2.1 系统概述

平台支持用户注册登录、机票搜索、订单提交与支付、订单管理等核心业务功能，初期聚焦于航班预订场景。

2.2 用户特征

本系统的用户主要包括普通注册用户（旅行者），未来可扩展至商家和平台管理员。

2.3 运行环境

• 前端：Web 浏览器（PC、移动端）
• 后端：FastAPI
• 数据库：SQLite

2.4 约束条件

• 必须支持手机号与邮箱注册
• 登录与注册流程中需要验证码验证
• 数据库使用 SQLite（基础版）

2.5 假设与依赖

• 系统依赖第三方短信与邮箱服务发送验证码
• 系统依赖浏览器本地存储实现“记住登录状态”

3. 功能需求

3.1 业务需求简述与索引

用户管理模块

• 用户注册功能（支持邮箱或手机号）
• 用户登录功能（支持账号密码、验证码登录）
• 用户基本信息管理（查看、编辑个人信息）
• 常用旅客信息管理（添加、编辑、删除旅客）

机票查询与预定

• 基础搜索功能（出发地、目的地、日期选择）
• 高级搜索功能即筛选、排序（可选）
• 航班列表展示（航班信息、价格、时间）
• 机票预订页面（选择乘机人、确认机票信息）
• 机票选座与值机（可选）

订单管理

• 订单列表分类展示（历史订单）
• 订单详情查看
• 订单状态管理

支付功能

• 使用余额模拟支付
• 支付成功后订单状态更新
• 退款功能

3.2 功能需求详细设计与描述

3.2.1 用户管理模块

3.2.1.1 注册

页面 1：用户协议 + 邮箱/手机号验证码发送 + 第三方注册

1、功能：用户协议确认

Scenario: 用户必须勾选协议才能继续注册

• Given 用户位于注册页面
• When 用户点击“注册”按钮但未勾选协议
• Then 系统提示用户必须勾选协议后才能继续

输入：勾选框状态
输出：提示信息或进入下一步
异常：页面刷新导致勾选状态丢失 → 需重新勾选

2、功能：邮箱 / 手机号注册 - 发送验证码

Scenario: 用户输入邮箱或手机号以接收验证码

• Given 用户在注册页输入邮箱或手机号
• When 用户点击“发送验证码”
• Then 系统校验输入格式并发送验证码

输入：邮箱或手机号
输出：发送成功提示，验证码发送到对应渠道
处理逻辑：

1. 校验格式
2. 检查发送频率
3. 发送验证码，记录时间戳

异常 / 边界情况：

• 输入格式错误 → 立即提示
• 发送频率过高 → 返回错误提示
• 网络异常 → 发送失败提示

3、功能：重新发送验证码

Scenario: 用户未收到验证码，点击重新发送

• Given 用户已填写邮箱/手机号
• When 点击“重新发送”按钮
• Then 系统重新发送验证码并提示成功

输入：邮箱/手机号
输出：提示“验证码已重新发送”
异常：频繁点击、网络异常

4、功能：第三方账号注册（可选分支）

Scenario: 用户通过 GitHub / Google 注册

• Given 用户点击第三方注册按钮
• When 用户在授权页面完成授权
• Then 系统获取用户信息并创建本地账户，进入下一步

输入：OAuth 授权信息
输出：注册成功或错误提示
异常：拒绝授权 / 网络超时 / 获取用户信息失败

页面 2：用户名 + 密码 + 人机验证

1、功能：用户名设置

Scenario: 用户输入用户名

• Given 用户进入注册第二页
• When 用户输入用户名并提交
• Then 系统校验格式和唯一性，返回结果

输入：用户名
输出：可用/不可用提示
异常：数据库延迟、网络问题

2、功能：密码输入与确认 + 强度校验

Scenario: 用户设置登录密码

• Given 用户进入注册第二页
• When 用户输入密码和确认密码
• Then 系统检查密码强度和一致性

输入：密码、确认密码
输出：验证通过或错误提示
异常：两次不一致、密码太弱

3、功能：人机验证码验证

Scenario: 用户进行人机验证码校验

• Given 用户完成用户名和密码填写
• When 用户触发验证码验证
• Then 系统完成验证，允许提交

输入：验证码（图形 / 行为）
输出：验证通过 / 错误提示
异常：验证码过期 / 网络问题

页面 3：手机号绑定（仅邮箱注册用户）

1、功能：绑定手机号

Scenario: 用户使用邮箱注册，需绑定手机号

• Given 用户通过邮箱完成注册第二页
• When 用户输入手机号并获取验证码
• Then 系统验证并绑定手机号

输入：手机号、验证码
输出：绑定成功提示
异常：手机号已存在 / 验证码错误 / 超时

3.2.1.2 登录

1、功能：用户名 + 密码登录

Scenario: 用户使用用户名和密码登录

• Given 用户在登录页面
• When 用户选择“用户名 + 密码登录”方式并输入正确的用户名和密码
• Then 系统验证成功后跳转至用户主页，登录状态生效

输入：用户名、密码
输出：登录成功提示 / 页面跳转
执行逻辑：

1. 校验用户名格式
2. 校验密码是否匹配数据库
3. 登录成功后，生成会话 / Token

异常 / 边界情况：

• 用户名不存在 → 提示“用户名不存在”
• 密码错误 → 提示“密码错误，请重试”
• 网络异常 → 登录失败提示

2、功能：邮箱 / 手机号 + 密码登录

Scenario: 用户使用邮箱或手机号和密码登录

• Given 用户在登录页面
• When 用户选择“邮箱 / 手机号 + 密码”登录方式，输入信息后提交
• Then 系统验证身份后登录成功，跳转主页

输入：邮箱或手机号、密码
输出：登录成功或错误提示
执行逻辑：

1. 判断输入是邮箱还是手机号
2. 格式校验
3. 密码比对
4. 登录成功后生成 Token

异常 / 边界情况：

• 邮箱或手机号未注册 → 提示“账户不存在”
• 密码错误 → 错误提示
• 网络异常 → 登录失败

3、功能：邮箱 / 手机号 + 验证码登录

Scenario: 用户使用邮箱或手机号 + 验证码快速登录

• Given 用户在登录页面
• When 用户输入邮箱或手机号，点击“发送验证码”，再输入收到的验证码
• Then 系统验证验证码并完成登录

输入：邮箱/手机号、验证码
输出：登录成功或错误提示
执行逻辑：

1. 校验邮箱/手机号格式
2. 发送验证码
3. 用户输入验证码
4. 系统验证正确 → 登录成功 → 发放 Token

异常 / 边界情况：

• 验证码错误 / 过期 → 错误提示
• 未注册邮箱/手机号 → 提示“账户不存在”
• 网络异常 → 登录失败

4、功能：第三方快速登录（页面下方小图标）

Scenario: 用户使用第三方（GitHub / Google）快速登录

• Given 用户在登录页点击下方第三方登录图标
• When 用户完成授权流程
• Then 系统校验授权信息，若成功则创建 / 关联本地账户并登录

输入：第三方授权信息（OAuth）
输出：登录成功或错误提示
执行逻辑：

1. 跳转授权页
2. 获取 OAuth token
3. 验证、创建/关联用户
4. 登录成功 → 发放 Token

异常 / 边界情况：

• 用户拒绝授权 → 提示“授权取消”
• 授权失败 / 网络超时 → 登录失败提示

5、功能：记住登录状态

Scenario: 用户勾选“记住登录”

• Given 用户在登录页勾选“记住登录状态”
• When 登录成功
• Then 系统将 Token 或会话信息加密存储于本地，实现长时效登录

输入：勾选框状态
输出：本地存储信息
执行逻辑：

1. 登录成功后检查是否勾选
2. 若勾选 → 将 Token 存储至 localStorage / Cookie（加密）
3. 设置有效期

异常 / 边界情况：

• Token 过期 → 自动跳转登录页
• 浏览器隐私模式 / 清缓存 → 状态失效

6、功能：自动登录

Scenario: 用户已勾选记住登录，在下次访问时自动登录

• Given 用户已登录并勾选“记住登录”
• When 用户重新访问网站
• Then 系统检测本地 Token，有效则自动登录并跳转主页

输入：本地 Token
输出：自动登录成功或跳转登录页
执行逻辑：

1. 页面加载时检查本地存储
2. Token 有效 → 自动发起验证 → 登录成功
3. Token 失效 → 清除存储，跳回登录页

异常 / 边界情况：

• Token 过期 → 清除登录状态
• Token 被篡改 → 拦截并提示错误

3.2.1.3 用户资料管理

该模块位于「个人中心」，通过页面左侧的侧边栏切换不同信息区块，右侧内容区域进行信息的展示与编辑。
用户可以管理个人基本信息、偏好设置、旅行信息、上传头像，以及修改 / 重置密码。

1、功能区块一：基本信息

Scenario: 用户查看与编辑基本信息

• Given 用户进入“基本信息”区块
• When 用户修改姓名、昵称、生日、性别、手机号或邮箱后点击“保存”
• Then 系统校验输入合法性并更新数据库记录

输入：姓名、昵称、生日、性别、手机号、邮箱
输出：保存成功提示 / 错误提示
执行逻辑：

1. 获取用户现有信息并填充表单
2. 用户修改 → 前端格式校验（如邮箱格式、手机号格式）
3. 提交 → 后端更新数据库 → 返回成功状态

异常 / 边界情况：

• 邮箱/手机号格式错误 → 前端实时提示
• 数据库更新失败 → 返回错误提示
• 生日超出合理范围 → 阻止提交

2、功能区块二：偏好设置

Scenario: 用户修改个人偏好设置

• Given 用户进入“偏好设置”区块
• When 用户修改语言、货币、通知偏好后点击“保存”
• Then 系统保存设置并立即在前端生效（如界面语言切换）

输入：语言、货币、通知偏好
输出：保存成功提示
执行逻辑：

1. 显示当前设置
2. 用户修改 → 提交 → 后端更新
3. 返回成功 → 前端刷新或局部更新界面

异常 / 边界情况：

• 提交失败 → 提示“保存失败，请稍后重试”

3、功能区块三：旅行信息

Scenario: 用户管理旅行信息

• Given 用户进入“旅行信息”区块
• When 用户添加或编辑常用出发地、护照信息、常用旅客信息
• Then 系统更新对应信息

输入：出发地、护照信息、常用旅客列表（姓名、证件号等）
输出：更新成功提示
执行逻辑：

1. 加载已有旅行信息
2. 用户增 / 删 / 改
3. 后端同步更新 → 前端刷新

异常 / 边界情况：

• 护照信息格式错误 → 提示
• 重复添加旅客 → 阻止提交并提示

4、功能区块四：头像上传

Scenario: 用户上传或更换头像

• Given 用户进入“头像上传”区块
• When 用户上传一张图片并进行裁剪
• Then 系统保存裁剪后的头像并更新用户资料

输入：图片文件（JPEG / PNG）
输出：头像更新成功 / 错误提示
执行逻辑：

1. 选择图片 → 本地预览 → 裁剪组件
2. 提交 → 上传文件 → 后端存储（可能是对象存储）
3. 返回成功 → 前端更新显示

异常 / 边界情况：

• 文件过大或格式不支持 → 拒绝上传
• 网络中断 → 上传失败提示

5、功能区块五：密码管理

（1）功能：忘记密码重置

Scenario: 用户通过邮箱 / 手机号重置密码

• Given 用户在密码管理区点击“忘记密码”
• When 用户输入绑定邮箱 / 手机号，接收验证码并设置新密码
• Then 系统验证成功后重置密码

输入：邮箱/手机号、验证码、新密码
输出：重置成功提示
异常 / 边界情况：验证码过期 / 格式错误

（2）功能：密码修改

Scenario: 用户修改密码

• Given 用户已登录，进入密码管理区
• When 用户输入旧密码和新密码后提交
• Then 系统验证旧密码，成功后更新为新密码

输入：旧密码、新密码
输出：修改成功提示
执行逻辑：

1. 校验旧密码是否正确
2. 检查新密码强度
3. 更新密码并提示成功

异常 / 边界情况：

• 旧密码错误 → 阻止修改并提示
• 新密码不符合规范 → 阻止提交

[!Proficiency]+

• 敏感信息如手机号，邮箱之类的中间打码处理

3.2.1.4 常用旅客管理

用户可以在个人中心的“常用旅客”区块，对常用旅客信息进行新增、查看、修改和删除操作。

1、功能：新增常用旅客

Scenario: 用户新增一位常用旅客

• Given 用户在“常用旅客”页面
• When 用户点击“新增旅客”，填写姓名、证件号、联系方式并保存
• Then 系统校验输入并将旅客信息写入数据库

输入：姓名、证件类型、证件号、手机号（可选）、邮箱（可选）
输出：新增成功提示，页面显示新增旅客
执行逻辑：

1. 用户点击“新增旅客”
2. 前端弹出表单 → 输入旅客信息
3. 校验（格式/唯一性）
4. 保存到数据库
5. 返回成功并刷新页面

异常 / 边界情况：

• 证件号重复 → 阻止保存并提示
• 手机号格式不合法 → 提示错误
• 网络异常 → 保存失败提示

2、功能：查看常用旅客

Scenario: 用户查看旅客列表

• Given 用户在“常用旅客”页面
• When 页面加载
• Then 系统从数据库读取旅客列表并展示

输入：无（仅页面访问）
输出：旅客列表（姓名、证件号掩码、联系方式掩码）
执行逻辑：

1. 加载用户 ID 对应的旅客数据
2. 返回 JSON / 数据表
3. 前端展示（部分敏感信息打码）

异常 / 边界情况：

• 无数据 → 显示“暂无旅客，请添加”

3、功能：修改常用旅客

Scenario: 用户修改一位旅客的信息

• Given 用户在“常用旅客”列表页
• When 用户点击“编辑”，修改字段并保存
• Then 系统校验后更新旅客信息

输入：旅客 ID、新的姓名/证件号/联系方式
输出：修改成功提示
执行逻辑：

1. 用户点击编辑按钮
2. 系统加载旅客原信息并显示在表单
3. 用户修改并提交
4. 后端验证 & 更新数据库
5. 返回成功并刷新显示

异常 / 边界情况：

• 修改为重复证件号 → 提示错误
• 输入非法字符 → 阻止提交
• 数据库更新失败 → 返回失败提示

4、功能：删除常用旅客

Scenario: 用户删除一位旅客

• Given 用户在“常用旅客”列表页
• When 用户点击“删除”并确认操作
• Then 系统删除该旅客记录

输入：旅客 ID
输出：删除成功提示，列表刷新
执行逻辑：

1. 用户点击删除按钮
2. 弹出确认对话框
3. 确认后 → 调用接口删除数据
4. 列表刷新

异常 / 边界情况：

• 用户取消确认 → 不执行删除
• 网络异常 → 删除失败提示
• 数据库删除失败 → 返回错误提示

[!Proficiency]+

• 敏感信息如省份证号之类的中间打码处理

3.2.2 机票查询与预定模块

机票查询与筛选是 Nextrip 平台的核心功能，为用户提供便捷的航班搜索和个性化筛选服务。

3.2.2.1 基础搜索

机票搜索栏集中展示在一个页面顶部，用户可在此完成搜索条件的设置。
所有基础搜索条件（出发地、目的地、出发日期、返程日期、乘客类型、舱位等级、行程类型）在一个页面上并行设置，不存在前后依赖关系。

用户可自由组合搜索条件，然后点击「搜索」按钮发起查询。

1、功能：行程类型选择

Scenario: 用户选择单程、往返或多程

• Given 用户在搜索栏最上方
• When 用户点击单程、往返或多程选项
• Then 系统切换相应的日期选择和搜索表单布局

输入：行程类型（单程 / 往返 / 多程）
输出：对应的日期输入区块显示或隐藏
异常 / 边界情况：无（选择切换逻辑简单）

2、功能：出发地选择

（同前述，简写）

• 输入：城市名 / 机场代码
• 输出：下拉列表 → 选择一项
• 异常：无匹配结果、网络异常

3、功能：目的地选择

（同前述，简写）

• 输入：城市名 / 机场代码
• 输出：热门目的地 / 匹配结果
• 异常：目的地与出发地相同

4、功能：日期选择（出发日期 + 返程日期）

Scenario: 用户在日历组件中选择出发和返程日期

• Given 用户点击日期输入框
• When 用户选择日期（单程仅选择出发日期，往返选择两个日期）
• Then 系统显示所选日期，并验证合法性

输入：出发日期、返程日期
输出：已选择的日期文本（YYYY-MM-DD）
异常 / 边界情况：

• 过去日期 → 阻止提交
• 返程早于出发 → 错误提示

5、功能：乘客类型选择

Scenario: 用户选择是否带儿童或婴儿

• Given 用户点击“乘客类型”选项
• When 勾选“带儿童”或“带婴儿”
• Then 系统在搜索条件中记录，并在结果过滤时使用

输入：乘客类型勾选框
输出：配置状态
异常 / 边界情况：无

6、功能：舱位等级选择

Scenario: 用户在下拉框中选择舱位等级

• Given 用户点击舱位等级下拉菜单
• When 用户选择「不限 / 经济舱 / 商务舱 / 头等舱」
• Then 系统更新搜索条件

输入：舱位类型
输出：已选择的舱位标签
异常 / 边界情况：无

7、功能：搜索按钮

Scenario: 用户完成所有搜索条件配置后点击“搜索”

• Given 所有搜索条件已设置
• When 用户点击搜索按钮
• Then 系统组合所有条件，发起航班搜索请求，返回搜索结果页

输入：行程类型、出发地、目的地、日期、乘客类型、舱位等级
输出：搜索结果页面
执行逻辑：

1. 收集所有输入
2. 进行前端合法性校验
3. 调用航班搜索 API
4. 跳转到结果页显示航班列表

异常 / 边界情况：

• 必填项为空 → 阻止提交并提示
• 网络异常 → 弹出错误提示

[!tips] > **业务规则：**出发日期不能早于当前日期，往返票程日期不能早于出发日期。

3.2.2.2 高级筛选

在用户完成基础搜索并进入航班列表页后，页面提供「高级筛选」功能，帮助用户对搜索结果进一步细化筛选。
筛选栏位于搜索结果区域上方，所有筛选项在一个页面中并行操作，可单独或组合使用。

高级筛选包括以下功能点：

• 航班所属航空公司筛选
• 起飞 / 到达时间段筛选
• 机场筛选与搜索
• 中转次数筛选（直飞 / 经停）

用户可以对任意组合条件进行筛选，筛选结果实时更新航班列表。

1、功能：航空公司筛选

Scenario: 用户按航空公司筛选航班

• Given 用户已进入搜索结果页
• When 用户在筛选栏中勾选一个或多个航空公司
• Then 系统筛选列表中只显示对应航空公司的航班

输入：航空公司勾选项
输出：筛选后的航班列表
执行逻辑：

1. 前端读取筛选条件 → 更新请求参数
2. 发起新的搜索或在前端过滤结果
3. 航班列表实时刷新显示

异常 / 边界情况：

• 未选中任何航空公司 → 显示全部
• 所选航空公司无符合航班 → 提示“无符合条件的航班”

2、功能：起飞 / 到达时间段筛选

Scenario: 用户按时间段筛选航班

• Given 用户已进入搜索结果页
• When 用户选择起飞时间或到达时间的时间区间（如早晨、下午、晚上、自定义区间）
• Then 系统只显示在该时间范围内的航班

输入：时间段选择（如 06:00–12:00）
输出：筛选后的航班列表
执行逻辑：

1. 用户选择预设时间段或自定义区间
2. 更新筛选参数
3. 重新过滤或请求航班数据
4. 列表更新

异常 / 边界情况：

• 区间设置不合法（如开始时间大于结束时间） → 提示错误
• 无匹配航班 → 显示空结果提示

3、功能：机场筛选与搜索

Scenario: 用户按机场筛选航班

• Given 用户已进入搜索结果页
• When 用户在机场筛选栏中勾选或输入机场名称 / 代码
• Then 系统仅显示从所选机场出发或到达的航班

输入：机场名、机场代码
输出：筛选后的航班列表
执行逻辑：

1. 输入框实时匹配机场数据库
2. 勾选目标机场
3. 筛选结果实时更新

异常 / 边界情况：

• 输入无匹配机场 → 显示“未找到机场”
• 所选机场无航班 → 空结果提示

4、功能：中转次数筛选（直飞 / 经停）

Scenario: 用户按中转情况筛选航班

• Given 用户已进入搜索结果页
• When 用户在筛选栏中选择“直飞”或“有经停”
• Then 系统只显示符合条件的航班

输入：筛选选项（直飞 / 经停）
输出：更新后的航班列表
执行逻辑：

1. 用户点击单选项
2. 更新搜索参数
3. 刷新结果列表

异常 / 边界情况：

• 某类航班不存在（如没有直飞） → 提示“暂无符合条件的航班”

[!tips]+ 筛选逻辑： 支持多条件组合筛选； 实时显示筛选结果数量； 支持筛选条件重置以及实时更改。

3.2.2.3 航班列表

用户完成搜索后，将进入搜索结果页。
搜索结果页核心包括两部分内容：

1. 航班信息展示区域
2. 排序与筛选控制区域

1、功能：航班信息展示

Scenario: 用户查看航班列表

• Given 用户完成基础搜索
• When 搜索结果加载完成
• Then 系统以列表形式展示符合搜索条件的所有航班信息

展示信息字段：

• 航空公司名称与 Logo
• 航班号
• 起飞时间与出发机场
• 到达时间与到达机场
• 飞行时长
• 中转次数（直飞 / 1 次中转 / 多次中转）
• 价格（起售价格）

执行逻辑：

1. 用户点击搜索后，系统调用航班搜索接口获取数据
2. 后端返回符合条件的航班列表
3. 前端按默认排序规则（如“低价优先”）进行初始渲染
4. 列表以分页或懒加载方式显示

异常 / 边界情况：

• 无搜索结果 → 显示“暂无符合条件的航班”
• 数据加载超时 → 显示加载失败提示
• 部分字段缺失（如准点率） → 以“—”占位

2、功能：排序功能

Scenario: 用户对航班列表进行排序

• Given 用户在搜索结果页顶部的排序栏
• When 用户选择某种排序方式（如价格、起飞时间等）
• Then 系统根据选中的规则重新排序航班列表

可用排序规则：

• 价格排序：从低到高 / 从高到低
• 起飞时间排序：从早到晚 / 从晚到早
• 到达时间排序：从早到晚 / 从晚到早
• 准点率排序：从高到低
• 飞行耗时排序：从短到长

执行逻辑：

1. 用户点击排序选项
2. 前端根据所选规则对已有航班列表排序（如已加载所有数据）
3. 若需后端排序（如分页数据），则重新发送请求
4. 列表即时刷新显示新顺序

异常 / 边界情况：

• 当前排序规则下无变化（如所有航班价格相同） → 列表保持不变
• 网络请求失败（后端排序模式） → 保留原列表，提示“排序失败”

3.2.2.4 机票预订

在用户完成航班选择（去程与返程）后，系统将跳转至订单填写页面。
该页面用于录入乘机人、联系人信息，并确认所选航班及票价信息，最后提交订单并跳转至支付页面完成支付。

1、功能：选择乘机人

Scenario: 用户选择乘机人信息

• Given 用户进入订单填写页面
• When 用户点击“选择乘机人”
• Then 系统显示常用旅客列表，用户可以勾选已有旅客，也可以选择“新增乘机人”并填写信息

输入：

• 乘机人姓名
• 证件类型与证件号（如身份证、护照）
• 手机号（可选）
• 邮箱（可选）

输出：

• 乘机人信息表单（已选旅客或新增旅客）
• 校验结果提示

执行逻辑：

1. 加载用户常用旅客列表
2. 用户可勾选一位或多位旅客（根据人数限制）
3. 或点击“新增乘机人” → 输入信息 → 校验 → 暂存至订单上下文
4. 支持删除、修改已选旅客信息

异常 / 边界情况：

• 信息缺失或格式错误（证件号、手机号等） → 阻止提交
• 乘机人数量超过航班余票 → 提示错误
• 新增旅客时重复证件号 → 阻止添加

2、功能：确认机票信息

Scenario: 用户核对所选航班与价格

• Given 用户进入订单填写页面
• When 页面加载完成
• Then 系统展示用户所选去程与返程航班详情，以及票价与税费明细

显示信息包括：

• 去程、返程航班的航空公司、航班号、时间、机场、舱位等
• 乘机人名单与对应票价
• 行李额度、退改签手续费、税费明细
• 价格合计（例如：票价 + 燃油税 + 机建费）

执行逻辑：

1. 从订单上下文中读取已选航班信息
2. 调用航班实时价格接口，刷新票价
3. 渲染航班信息区与价格明细区
4. 若价格或库存有变化，页面顶部显示提示

异常 / 边界情况：

• 航班价格发生变动 → 提示用户确认
• 舱位售罄 → 提示重新选择航班
• 加载失败 → 提示“信息加载失败，请刷新重试”

3、功能：订单提交

Scenario: 用户确认信息后提交订单

• Given 所有信息填写完成
• When 用户点击“提交订单”按钮
• Then 系统校验订单信息并生成订单记录，进入待支付状态

输入：乘机人、联系人信息、航班信息
输出：订单号、跳转支付页面

执行逻辑：

1. 表单合法性校验（乘机人、联系人、必填项）
2. 生成订单号并写入数据库
3. 状态标记为“待支付”
4. 跳转至支付页面

异常 / 边界情况：

• 乘机人信息未填 → 阻止提交
• 网络异常 → 提示“订单提交失败”
• 舱位库存不足 → 提示重新选择

4、功能：跳转支付页面

Scenario: 用户完成订单提交后跳转支付

• Given 用户提交订单成功
• When 系统生成订单号
• Then 自动跳转支付页面，用户可完成余额支付或其他方式支付

输入：订单号、支付方式
输出：支付成功 / 失败提示

执行逻辑：

1. 携带订单号跳转支付页面
2. 显示订单金额与支付选项（余额、第三方）
3. 用户输入支付信息并确认
4. 后端处理支付请求，返回支付结果
5. 成功 → 更新订单状态为“已支付”
   失败 → 保持“待支付”，可重试

异常 / 边界情况：

• 余额不足 → 提示“余额不足，请充值”
• 支付中断 / 超时 → 提示失败，可重试
• 订单超时未支付 → 自动取消

[!Proficiency]+

• 订单等待支付页面有天气预报和保险
• 可选择接送机服务，和机场休息室
• 可以设计一个排队等待界面

3.2.2.5 选座与值机

在机票搜索首页，提供一个独立的“选座与值机”模块，方便已购票用户快速进入对应航空公司官网完成在线选座与值机操作。
该模块不直接处理选座逻辑，仅起到跳转功能。

1、功能：进入选座与值机模块

Scenario: 用户在机票搜索首页点击“选座与值机”

• Given 用户在首页
• When 用户点击“选座与值机”入口
• Then 系统进入选座与值机模块页面，展示航空公司选择界面

输入：无
输出：航空公司选择页面

执行逻辑：

1. 用户点击入口按钮
2. 系统跳转至选座与值机模块（内部页面）
3. 显示航空公司列表（可搜索）

异常 / 边界情况：

• 网络错误 → 提示“页面加载失败，请重试”

2、功能：选择航空公司

Scenario: 用户选择自己的航班所属航空公司

• Given 用户已进入选座与值机模块
• When 用户在航空公司列表中查找并选择对应公司
• Then 系统跳转至该航空公司的官网值机/选座页面

输入：航空公司名称（点击选择）
输出：跳转链接（对应航空公司官网）

执行逻辑：

1. 系统提供航空公司搜索框 + 列表（支持中文/英文/拼音检索）
2. 用户选择一家公司
3. 系统从预设跳转表中读取该公司的官网链接
4. 打开新页面 / 新标签页跳转

异常 / 边界情况：

• 航空公司未收录 → 提示“暂不支持该航空公司，请手动前往官网”
• 跳转链接失效 → 提示“链接暂不可用”

3、功能：跳转外部官网进行选座与值机

Scenario: 用户在跳转后的页面完成选座/值机

• Given 用户已被跳转至航空公司官网
• When 用户在该网站完成值机、选座
• Then 该功能在 OTA 系统中无需记录，操作完全在航空公司官网完成

输入：用户在官网上自行输入的航班信息、证件信息
输出：航空公司官网的选座 / 值机成功页面

系统角色说明：

• OTA 平台仅提供跳转入口，不处理值机与选座数据
• 不会在本系统中保存或同步任何用户在外部官网的操作结果

异常 / 边界情况：

• 外部网站访问失败 → 提示用户手动复制链接访问
• 航空公司官网改版 → 跳转地址需更新

3.2.3 订单管理

3.2.3.1 订单列表

用户可以在个人中心的“我的订单”页面查看、筛选和管理所有订单。
该页面默认展示订单列表，并提供多种筛选方式（状态、日期、订单号）方便用户快速定位目标订单。

1、功能：订单列表

Scenario: 用户查看自己的全部订单

• Given 用户已登录，进入“个人中心 - 我的订单”页面
• When 页面加载完成
• Then 系统按时间倒序显示该用户的所有订单列表，支持分页浏览

显示信息包括：

• 订单号
• 去程与返程航班信息（城市、航班号、起降时间）
• 乘机人信息（打码显示）
• 订单状态（待出行、未支付、已取消、待评价、已完成等）
• 订单金额

执行逻辑：

1. 根据当前登录用户的 ID 查询订单表
2. 以创建时间倒序排序，分页加载
3. 渲染订单列表区块

异常 / 边界情况：

• 用户暂无订单 → 显示“暂无订单记录”
• 网络异常 → 显示加载失败提示

2、功能：订单筛选

Scenario: 用户使用筛选功能查找特定订单

• Given 用户在“订单列表”页面
• When 用户设置筛选条件（订单状态、日期、订单号）并点击“搜索”
• Then 系统根据条件返回符合的订单列表

可用筛选条件：

• 订单状态：全部 / 未支付 / 待出行 / 待评价 / 已完成 / 已取消 / 已退款
• 日期范围：按预订日期起止区间筛选
• 订单号：支持精确匹配

执行逻辑：

1. 用户在筛选栏中设置条件
2. 前端将筛选条件提交给后端接口
3. 后端根据条件查询订单数据库，返回结果
4. 页面刷新显示筛选结果

异常 / 边界情况：

• 无匹配订单 → 显示“未找到符合条件的订单”
• 日期输入错误（开始日期 > 结束日期） → 阻止查询并提示

3.2.3.2 订单详情

用户点击订单列表中的任意订单，可以进入订单详情页面查看该订单的完整信息，包括订单状态、支付信息、航班详情、乘机人信息及售后服务入口。

1、功能：查看订单详情

Scenario: 用户点击订单查看详细信息

• Given 用户已登录并位于订单列表页面
• When 用户点击某一订单（订单号区域）
• Then 系统跳转到订单详情页，展示该订单的详细内容

订单详情页显示内容包括：

• 订单信息

  • 订单号
  • 订单状态（未支付 / 已支付 / 已取消 / 已退款 / 已完成）
  • 取消原因（如有）
  • 订单创建时间

• 支付信息

  • 订单总金额
  • 机票价格、机建费、燃油税明细（分去程 / 返程列出）
  • 支付时间与方式（如已支付）
  • 失败/取消订单提供“再次预订”按钮

• 航班信息

  • 去程与返程航班分别展示
  • 航空公司、航班号、出发与到达机场、时间、飞行时长、舱位
  • 退改签政策、行李政策、产品说明的跳转链接

• 乘机人信息

  • 姓名（可打码）
  • 证件类型与号码（打码）
  • 联系方式（部分打码）

• 用户评分区（可选）

  • “您对本次预订体验满意吗？” 1~10 分打分区

执行逻辑

1. 用户点击订单 → 获取订单 ID
2. 前端调用订单详情接口 → 后端返回订单、航班、乘机人、支付等多表联合数据
3. 前端渲染详情页，并按模块展示
4. 根据订单状态，动态显示：
   • 未支付 → “去支付”按钮
   • 已取消 → 显示取消原因 + “再次预订”
   • 已完成 → 显示评价区块

异常 / 边界情况

• 订单不存在 / 已删除 → 提示“订单不存在或已被删除”
• 数据加载失败 → 显示“加载失败，请刷新重试”
• 部分航班信息缺失 → 标记为“暂无信息”，但不影响整体页面显示
• 取消订单后再次访问 → 订单状态应显示为“已取消”，并可再次预订

3.2.3.3 订单操作

订单的状态会根据用户在订单详情页的操作以及系统自动处理流程进行更新，涵盖取消、退款、支付后状态变更等典型场景。

1、功能：订单取消

Scenario: 用户在订单详情页主动取消订单

• Given 用户的订单处于“待支付”状态
• When 用户点击“取消订单”并确认操作
• Then 系统将订单状态更新为“已取消”，并在订单列表与详情页同步显示更新结果

输入：订单 ID
输出：订单状态变更结果（已取消）

执行逻辑：

1. 校验订单当前状态是否允许取消（仅“待支付”状态可取消）
2. 更新订单表状态字段 → 已取消
3. 返回操作成功提示，并刷新页面

异常 / 边界情况：

• 非待支付订单点击取消 → 提示“当前订单不可取消”
• 网络异常或接口失败 → 显示“取消失败，请重试”

2、功能：订单退款 / 改签

Scenario: 用户在订单详情页申请退款或改签

• Given 用户的订单处于“待出行”状态，且符合退款或改签规则
• When 用户点击“申请退款”或“改签”并确认操作
• Then 系统发起退款 / 改签流程，成功后将订单状态更新为“已退款”或“已改签”，并在详情页和列表中同步

输入：订单 ID、退款/改签请求参数
输出：订单状态更新（已退款 / 已改签）

执行逻辑：

1. 校验订单状态与退改签规则（是否允许退款、改签期限等）
2. 创建退款/改签申请 → 调用支付网关/航司接口处理
3. 成功后更新订单状态 → 已退款 或 已改签
4. 推送状态变更通知

异常 / 边界情况：

• 不满足退款/改签规则 → 提示用户原因
• 支付渠道异常 → 退款/改签失败提示
• 超过改签或退款时限 → 阻止操作并提示

3、功能：订单状态自动更新

Scenario: 系统根据用户操作和时间进度自动更新订单状态

• Given 用户下单并支付成功
• When 用户完成支付、航班出行或旅程结束
• Then 系统自动更新订单状态，保证状态流转与实际业务一致

状态流转规则：

执行逻辑：

• 支付成功 → 回调接口更新订单状态为待出行
• 行程结束 → 定时任务或航班接口回调更新订单状态为待评价
• 用户完成评价 → 状态更新为已完成
• 退款成功 → 状态更新为已退款
• 取消订单 → 状态更新为已取消

异常 / 边界情况：

• 回调失败 → 系统定时任务二次校正
• 支付成功但订单状态未更新 → 定时任务与人工介入修正
• 行程未被正常标记完成 → 用户可手动标记或系统根据航班实际时间更新

[!Proficiency]+

• 响应速度不用太高，10 秒以内即可
• 订单详情页面可以看见退改签政策，行李额等
• 提供订单下载服务
• 提供开具发票功能

3.2.4 支付功能

3.2.4.1 使用余额模拟支付

Scenario: 用户在订单详情页使用余额支付

• Given 用户的订单处于“待支付”状态，且余额充足
• When 用户点击“使用余额支付”并确认操作
• Then 系统将订单状态更新为“已支付”，并在订单列表与详情页同步显示更新结果

输入：订单 ID
输出：订单状态变更结果（已支付）

执行逻辑：

1. 校验订单当前状态是否允许支付（仅“待支付”状态可支付）
2. 校验用户余额是否充足
3. 更新订单表状态字段 → 已支付
4. 返回操作成功提示，并刷新页面

异常 / 边界情况：

• 非待支付订单点击支付 → 提示“当前订单不可支付”
• 余额不足 → 提示“余额不足，请充值”
• 网络异常或接口失败 → 显示“支付失败，请重试”

3.2.4.2 支付成功后订单状态更新

功能描述：
当用户完成订单支付后，系统需要自动将订单状态从「待支付」更新为「待出行」，以便后续出行管理和退款流程的正确运转。
订单状态的更新依赖支付结果的回调接口或系统主动轮询机制，确保状态的及时、准确同步。

场景（Scenario）：

• Given 用户在支付页面完成支付
• When 支付渠道返回支付成功的回调
• Then 系统自动更新订单状态为「待出行」，并触发后续出行提醒、通知等流程

输入 / 输出：

• 输入：订单号、支付结果（成功）、支付时间、交易号
• 输出：订单状态更新结果（从「待支付」→「待出行」），以及支付完成通知

执行逻辑：

1. 系统接收到支付成功回调（或轮询检测到支付成功）
2. 根据订单号查找对应订单
3. 校验订单状态必须为「待支付」
4. 更新订单状态字段为「待出行」，记录支付完成时间、交易流水号
5. 推送支付成功通知（如站内信 / 邮件 / 短信）
6. 将该订单加入“即将出行”任务队列，后续用于出行前提醒

异常 / 边界情况：

• 如果订单状态不为「待支付」但收到了支付成功回调（重复支付 / 异常），系统记录异常日志并不更新状态
• 支付回调超时或丢失 → 系统会通过定时任务轮询支付状态，进行二次确认
• 更新数据库失败 → 系统回滚状态并发出告警
• 用户支付完成后关闭页面 → 订单状态更新不依赖前端，仍能通过回调正常完成

3.2.4.3 退款功能

功能描述：
用户在订单状态为「待出行」时，可选择申请退款。系统需要校验订单是否符合退款规则，向支付渠道发起退款请求，处理退款结果，并在成功后将订单状态更新为「已退款」，同时通知用户退款成功。

场景（Scenario）：

• Given 用户的订单处于「待出行」状态，且符合退款规则
• When 用户在订单详情页点击「申请退款」按钮并确认
• Then 系统校验订单并发起退款流程，退款成功后订单状态更新为「已退款」，并发送通知

输入 / 输出：

• 输入：订单号、退款原因（可选）、退款方式（默认原路退回）
• 输出：退款处理结果（成功 / 失败）、订单状态更新结果

执行逻辑：

1. 用户点击「申请退款」 → 系统校验订单状态必须为「待出行」
2. 检查航班是否允许退款，是否超出退票期限
3. 创建退款申请记录
4. 调用支付网关接口发起退款请求
5. 等待支付网关返回退款结果
6. 退款成功 → 更新订单状态为「已退款」，记录退款时间和流水号
7. 退款失败 → 保持原状态并提示用户
8. 发送退款结果通知（短信 / 邮件 / 站内信）

异常 / 边界情况：

• 订单状态不是「待出行」 → 拒绝退款，提示“当前订单不可退款”
• 超过航司退票时限 → 提示用户“已超过退款期限”
• 支付渠道返回失败 → 显示“退款失败，请联系客服”
• 网络或系统异常 → 退款申请进入待处理队列，系统自动重试或人工介入

4. 非功能需求

本章定义系统在性能、安全、可靠性、可维护性、兼容性、数据一致性、可测试性、法规合规与容错灾备方面的要求。这些非功能性要求保证了系统不仅能实现功能目标，还能在实际运行中表现出良好的性能、稳定性和可扩展性。

5.1 性能需求（Performance Requirements）

5.2 安全性（Security Requirements）

• 全站采用 HTTPS 进行通信，防止中间人攻击
• 用户密码使用强哈希算法（如 bcrypt / SHA256）加盐存储
• 登录与支付等关键接口需实现防重放、防 SQL 注入、防 XSS 和 CSRF 攻击
• 对身份证号、手机号、邮箱等敏感信息在前端和日志中进行打码处理
• 管理后台需设置多级权限（管理员 / 财务 / 客服 / 普通用户），并基于角色控制访问范围
• 所有支付请求必须进行签名验证和双向身份认证
• 失败登录尝试超过 5 次的账户需进行临时冻结或验证码验证

5.3 可靠性与可用性（Reliability & Availability）

5.4 可维护性与可扩展性（Maintainability & Scalability）

• 系统采用前后端分离、模块化架构，支持水平扩展和局部替换
• 后台数据库结构需支持未来扩展，如增加新的航司、航线、支付方式
• 所有代码遵循统一的风格规范，并具备注释与文档
• 新模块的上线不得破坏原有功能，需通过 CI/CD 管道实现自动化部署和回滚
• 关键配置（如航司官网跳转表、价格策略）需支持后台动态管理，不需要重新部署

5.5 兼容性与可移植性（Compatibility & Portability）

、

5.6 数据一致性与同步（Data Consistency & Synchronization）

• 前后端一致性：订单状态、余额信息等必须在前后端保持实时同步
• 数据库一致性：支付、退款等关键操作需通过事务或分布式事务机制保证原子性
• 多终端同步：当用户在一个终端执行操作（如取消订单），其他终端应立即刷新状态
• 缓存策略：若使用缓存（如 Redis），需设置合理的过期策略，并在关键数据变更时触发主动失效机制
• 并发控制：同一订单在多终端同时操作时，需通过乐观锁或悲观锁机制避免冲突

5.7 可测试性（Testability）

• 提供完整的 API 文档与接口说明，支持自动化测试工具调用
• 核心模块（搜索、下单、支付、退款）需具备 ≥ 80% 的单元测试覆盖率
• 支持沙盒环境进行支付与退款测试，避免对真实交易造成影响
• 提供日志与监控接口，便于在测试和调试阶段快速定位问题
• 支持集成测试与回归测试场景的自动执行

5.8 法律与合规性（Legal & Compliance）

• 系统应遵守 GDPR / CCPA 等数据保护与隐私法规
• 用户个人信息的采集、存储与使用需有明确的隐私政策
• 支付系统必须符合 PCI-DSS 安全标准
• 票务数据管理需遵循中国民航局等相关部门的法规与标准
• 用户协议、退款政策等需在网站上明确展示，并在注册时要求用户确认

5.9 容错与灾备（Fault Tolerance & Backup）

5. 接口需求（API Requirements）

本章节定义系统前后端交互使用的标准接口格式与主要接口。所有接口均通过 HTTPS 访问，并遵循 RESTful 风格，部分场景可使用 WebSocket 进行实时通信。
返回数据严格遵循统一响应格式，确保前端、后端与第三方系统的一致性。

5.1 通用说明

• 协议：HTTPS（强制）
• 接口风格：RESTful
• 数据格式：JSON
• 认证机制：JWT / Session Token
• 字符编码：UTF-8
• 时区标准：所有时间字段使用 ISO 8601（UTC）格式

5.2 响应格式标准

项目定义了三种标准响应格式：成功响应、错误响应、分页响应。所有 API 必须严格遵循以下格式。

5.2.1 成功响应

{
"success": true,
"data": { },
"meta": {
"timestamp": "2025-10-14T10:00:00Z",
"requestId": "req_k8pQxJ2mN5vL9wRt"
}
}

5.2.2 错误响应

{
"success": false,
"error": {
"code": "VALIDATION_ERROR",
"message": "请求参数验证失败",
"details": [
{ "field": "email", "message": "邮箱格式不正确" }
]
},
"meta": {
"timestamp": "2025-10-14T10:00:00Z",
"requestId": "req_m3nH7vK2pL9xQ5wT"
}
}

5.2.3 分页响应

{
"success": true,
"data": {
"items": [ ],
"pagination": {
"page": 1,
"pageSize": 20,
"totalPages": 5,
"totalItems": 100
}
},
"meta": {
"timestamp": "2025-10-14T10:00:00Z",
"requestId": "req_v7wRtK8pQ9xJ2mN5"
}
}

5.3 接口分组与主要 API

5.3.1 用户与账户模块

5.3.2 航班搜索与预订模块

5.3.3 订单管理模块

5.3.4 通知模块

5.4 UI 页面与接口关系

5.5 认证与安全

• 所有接口（除注册 / 登录）必须携带有效的 JWT Token

• Token 放在 HTTP Header：Authorization: Bearer <token>

• 后端接口应验证 Token 的有效性与权限

• requestId 自动生成，用于日志链路追踪

  ---

6. 数据需求

5. 数据需求（Data Requirements）

本章节定义系统运行过程中需要管理的主要数据实体、表结构、约束与关系。数据涵盖用户、旅客、航班、舱位、订单、支付和通知等核心业务领域，为航班搜索、下单、支付、订单管理、库存扣减和消息通知等功能提供数据支持。

5.1 数据实体概览

5.2 用户与旅客数据表

users（用户表）

travelers（旅客表）

5.3 航班相关数据表

airports（机场表）

索引

• UNIQUE(iata_code)
• INDEX(city), INDEX(country), INDEX(is_deleted)

业务规则

• iata_code 全局唯一、3 位大写字母
• 所有文本字段使用英文存储，前端做国际化
• 查询必须过滤 is_deleted = FALSE

airlines（航空公司表）

索引

• UNIQUE(iata_code)
• INDEX(is_deleted)

业务规则

• 航司代码与航班号前两位一致
• 软删除，不物理删除

flights（航班表）

索引

• flight_number
• departure_airport_id, arrival_airport_id, departure_datetime
• airline_id
• is_deleted
• 组合索引 (departure_airport_id, arrival_airport_id, departure_datetime, is_deleted)

业务规则

• 出发、到达机场不可相同
• 所有时间存 UTC
• 搜索航班时使用组合索引

flight_seat_classes（舱位表）

索引

• flight_id
• UNIQUE(flight_id, class_type)
• class_type

业务规则

• 下单时减少 available_seats
• 取消/退款时回补库存
• 支持动态价格调整

5.4 订单与支付数据表

（orders、order_passengers、payments、notifications 的结构与之前一致，这里略）

5.5 数据关系

• users ↔ travelers：一对多
• flights ↔ airports：多对一（出发/到达）
• flights ↔ airlines：多对一
• flights ↔ flight_seat_classes：一对多
• users ↔ orders：一对多
• orders ↔ flights：多对一
• orders ↔ order_passengers：一对多
• orders ↔ payments：一对多
• users ↔ notifications：一对多

5.6 一致性与约束

• 库存一致性：下单与舱位 available_seats 更新必须在事务中进行
• 余额与支付一致性：用户余额更新与 payments 表同步
• 外键完整性：航班、机场、航司关系通过外键保证
• 软删除：航班、航司、机场逻辑删除，避免历史数据丢失
• 时间一致性：UTC 存储，前端转换

5.7 生命周期管理

5.8 性能与扩展性

• 航班搜索依赖组合索引，支持高并发查询
• 舱位表支持舱位维度的动态定价和并发扣减
• 机场/航司为静态基础数据，可缓存
• 分库分表可基于航班日期或订单号 UUID 前缀进行扩展