企业官网建设流程全解析

去年帮一个做汽车美容装饰的朋友搭店里的管理系统，前后忙了快一个月。他家店不大，两个工位，六个技师，两百多个会员，之前靠一个本子加微信群排预约，周末基本靠吼。做完那套东西之后我才发现，市面上包括高校毕业设计里经常那个“PHP + Python + Vue 小型汽车装饰美容店管理系统”的题目，本质上就是要解决这种小店从“人肉管理”到“系统管理”的问题。这篇就写一写我自己做完这类管理系统之后，从开题报告思路、技术选型、数据库设计，到代码实现和上线踩坑的完整总结，给正打算做这个选题、准备开题答辩，或者想自己接个小店管理需求的朋友做参考。

这套系统到底能做什么？往小了说，就是会员开卡、车辆建档、预约排班、施工单、结算收银、库存登记这些日常动作的数字化；往大了说，是把一个店每天“谁来了、车什么情况、做了什么项目、花了多少钱、用了什么耗材”这个业务闭环跑起来，店长打开电脑或手机就能看明白。这个项目体量不大，技术上也不要求你上微服务、分布式那套，用 PHP 写后端接口、Vue 写管理页面、Python 做报表和数据处理脚本，刚好是性价比最高的组合。

我下面讲的东西会比较细，包含可以直接抄的建表语句、接口逻辑、Vue页面片段和Python脚本，也包括一些开题答辩时容易被追问的考点。如果你想自己动手做一遍，照着往下走基本不会卡住。

1. 开题报告怎么写得让老师一眼看出你想清楚了

1.1 题目背后真正的用户痛点

很多人写开题报告，上来就写“随着汽车保有量不断增加，汽车美容行业迎来了快速发展”，这句话本身没错，但太空了。答辩老师真正想看的是，你有没有理解这个系统服务的对象到底痛在哪。

我朋友店里的实际情况是这样的：会员开卡用的是纸质登记表，充值时手写余额，时间一久经常出现“会员说卡里还有钱，账本上找不到”的扯皮。预约排班靠微信群，技师和工位能不能排得开全凭店长脑子记，节假日经常撞单。洗车耗材、机油、玻璃水这些没做过出库记录，月底一对库存总是少东西。每个月的营收和利润，要翻收款记录拿计算器加。

把这些问题翻译成系统功能，就是一张清晰的对照表：

开题报告的第一章，你要做的就是把这类场景写具体，写成“任何一个小店老板看了都会点头”的状态，而不是教科书式的行业背景。我当时写的时候直接用了“以一家典型的小型汽车装饰美容店为例”这种切入方式，把上面痛点每条展开两三句话，老师一看就知道你不是在凑字数。

1.2 开题报告各章节的写作思路

开题报告一般包含选题背景与意义、国内外研究现状、研究内容、技术路线、进度安排、预期成果六块。这里逐个说下怎么写能拿高分。

选题背景和意义，不要写太长，重点是“小店的预算和人员素质决定了他们用不起大型ERP，需要一个轻量、便宜、操作简单的系统”。这句话其实就把这个项目的存在价值说清楚了。

国内外研究现状，别一上来就抄大段参考文献。你就去知网搜“汽车美容 管理系统”“PHP 管理系统”这类关键词，挑三篇和题目最相关的，每篇用两三句话讲它做了什么、有什么不足，最后补一句“这些系统大多面向连锁门店，针对小型门店轻量化管理的方案还比较少”，你的选题意义就立住了。

研究内容是开题报告的核心。建议不要按数据库、后端、前端这样写，而是按业务模块写，比如会员储值管理、预约排班调度、施工订单闭环、库存进销存、数据统计报表。模块化的写法，和后面系统设计直接对应，答辩时介绍也顺。

技术路线，这一块要画出系统从页面到数据库的流转过程，并且单独说明 Python 承担的角色。很多同学题目里写了 Python，结果开题报告里从头到尾没出现 Python，答辩时必被问。我的写法是：Vue 负责界面交互，通过 HTTP 请求调用 PHP 接口；PHP 负责业务逻辑和数据库读写；Python 以独立脚本形式运行，承担 Excel 批量导入、月度报表生成、库存预警推送，三者互相配合。

进度安排是最容易拿分也最容易丢分的地方。我建议按 8 到 14 周来排，给一个参考模板：

1.3 技术选型：为什么偏偏是 PHP + Python + Vue

很多同学纠结，毕业设计到底选什么技术栈，怕选简单了被说水，选难了自己搞不定。我的观点很明确，这个题目用 PHP + Python + Vue 是性价比最高的组合，原因有三条。

第一，PHP 做后端的上手成本和部署成本很低。用宝塔面板几分钟就能把 Nginx、PHP、MySQL 搭起来，本地开发用 phpStudy 或者 PHP 内置服务器也能跑。相比 Java 要配 Maven、Spring Boot、IDEA 那一大堆东西，PHP 的学习曲线平缓得多，而且毕业设计阶段写接口够用。

第二，Vue 能让前端界面做得非常漂亮。现在 Vue3 + Element Plus 组件库的成熟度很高，表格、弹窗、表单、日期选择器、统计卡片都是现成的，拼出来的后台管理系统界面不会比商业软件差，答辩视觉效果加分明显。

第三，Python 的存在让系统具备“数据加工能力”。它不一定要抢 PHP 的饭碗做核心接口，而是做那些 PHP 不擅长的活儿，比如用 pandas 生成复杂的对账报表、用 openpyxl 批量读取 Excel 会员资料、定时脚本自动检查库存低于阈值后发通知。这种“各司其职”的架构，既满足了题目要求，又显得你对工程分工有思考。

对比一下其他方案会更有说服力。用 Java + Vue，功能上没问题，但 Spring Boot 的配置复杂度对普通学生来说要消耗大量时间在框架本身。用 Node.js + Vue，后端 JS 一体化上手快，但生态里缺少像宝塔那样对 PHP 友好的运维支撑，答辩时也容易被问“为什么不用更主流的方案”。用 Python + Flask/Django + Vue 当然也可以，但 Python 写大型业务接口在性能和组织上不如 PHP 直观，而且既然题目点名了 PHP，主后端就不要跑偏。

2. 环境搭建与项目骨架：先把地基建稳

2.1 本地开发环境怎么配

先说最常见的 Windows 环境。我推荐直接用 phpStudy，它把 Apache/Nginx、MySQL、PHP 不同版本都集成了，点几下就能切换版本。建议 PHP 版本选 8.1 或 8.2，MySQL 选 5.7 或 8.0，这两个组合稳定性很成熟。记得在 phpStudy 里把 Nginx 的client_max_body_size调大一点，后面导入 Excel 和上传图片时不容易踩坑。

如果你用的是 Mac，而且是最新的 M4 芯片，这里有个容易卡住的地方：phpStudy 官方对 arm 架构的支持不太好，有些版本装不上或无法增加 PHP 版本。我当时的处理办法是放弃图形面板，直接用 Homebrew 安装 PHP 8.1。安装时大概率会遇到类似的报错：library not loaded: @loader_path/../../../../opt/libffi/，这是因为 PHP 编译时依赖的 libffi 路径没找对。解决方法是先执行brew install libffi openssl，然后用brew reinstall php@8.1重新装一次，让 PHP 重新链接这些依赖。

Python 环境建议用 Anaconda 或 Miniconda 管理，Python 版本选 3.10 以上。为什么要用 conda？因为后面 pandas、openpyxl、pymysql 这些包在不同项目间会有版本冲突，conda 能帮你建独立环境，不至于把系统自带的 Python 搞乱。

Node.js 用来跑 Vue 工程，建议直接装 18 或 20 的 LTS 版本，避免某些依赖对高版本 Node 的兼容问题。

2.2 Vue 前端项目初始化和基本配置

前端我建议直接用 Vite 创建 Vue3 项目，不用 Vue CLI 了，Vite 启动快，配置也简单。创建命令就一行：

npm create vite@latest frontend -- --template vue

项目创建好之后，进入目录安装基础依赖：

cd frontend npm install npm install element-plus pinia vue-router axios

这里说一下，如果安装过程出现node-sass相关报错，通常是因为项目中引用了较老的 sass 编译包。解决办法是把node-sass替换成sass（dart-sass），安装完就能编过。Vite 对sass的兼容性比node-sass好很多，而且安装速度快，没有二进制编译地狱。

然后要处理开发环境跨域的问题。PHP 接口默认跑在http://127.0.0.1:8000之类的端口，Vue 跑在5173端口，浏览器会拦截跨域请求。最优雅的方案是在vite.config.js里配置代理：

export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { '/api': { target: 'http://127.0.0.1:8000', changeOrigin: true } } } })

这样前端代码请求/api/login时，Vite 会把请求转发给 PHP 后端。PHP 那边收到的请求也是来自服务器自己的，跨域问题基本消除。上线部署后，再用 Nginx 做同样的反代。

2.3 PHP 后端项目骨架与公共配置

PHP 项目我建议用一个轻量框架。以 ThinkPHP 6 为例，它的中文文档全，目录结构清晰，很多教材和毕业设计都基于它，答辩时被问到也好解释。用 Composer 创建项目：

composer create-project topthink/think backend

然后安装一个多应用模式扩展，把接口按admin（管理端）和api（小程序/手机端）拆开：

composer require topthink/think-multi-app

数据库配置在.env文件里。这一块有个非常容易踩的坑：如果你在 Windows 的 phpStudy 里连接 MySQL 用的是 root 且没有密码，DATABASE_PASSWORD留空即可；但部署到宝塔后，务必要新建一个专用账号并设置复杂密码，宝塔默认 root 密码是随机生成的，别直接复制粘贴到本地连接，会连不上。

后端接口要养成统一返回格式的习惯。我习惯用一个ApiResponse工具类，所有接口返回固定结构：

public static function success($data = [], string $msg = 'ok'): Json { return json([ 'code' => 0, 'msg' => $msg, 'data' => $data ]); } public static function error(string $msg = 'error', int $code = 1): Json { return json([ 'code' => $code, 'msg' => $msg, 'data' => null ]); }

这个结构前后端约定好后，Vue 那边用 axios 拦截器统一处理，代码会干净很多。后面所有接口我都会围绕这个约定来写。

3. 功能模块拆解与数据库设计：系统能不能落地，全看表建得怎么样

3.1 功能模块优先级排序

这项目虽然叫“管理系统”，但你不能上来就想着把所有功能全做完。我和朋友对需求时发现，真正每天高频使用的是四块：会员、车辆、预约、收银。库存和报表是次高频，一周看一次。所以做系统要按 MVP 思路来分优先级。

答辩时你可以这样讲：系统分三期建设，当前实现 P0 和 P1，P2 作为后续扩展方向。这样的表述既显得你有规划意识，又不会给自己挖坑。

3.2 核心表结构设计

数据库设计是整个系统最重要的一环，表建好了，后面写代码就是照图施工。我基于实际项目经验，把关键的几张表列出来。

会员表member，建议核心字段包括id、mobile、name、gender、birthday、balance、points、level、status、created_at。注意balance和points是冗余字段，真正可靠的金额账要依靠流水表，会员表里的余额只是用于页面展示。

储值流水表member_card_record是必须的，字段包括id、member_id、change_amount、change_type、remark、operator_id、created_at。这里change_type用字符串枚举（recharge充值 /consume消费 /refund退款），比用 0、1、2 这种数字清晰得多。会员说“我卡里钱怎么不对了”，一查流水就解释清楚了。

预约表appointment是这个系统的技术难点所在，字段包括id、member_id、car_id、service_item_id、technician_id、pit_id、appointment_date、start_time、end_time、status。预约冲突检测就发生在这张表上，后面代码部分会讲实现。

订单表orders，字段包括id、order_no、member_id、car_id、appointment_id、total_amount、discount_amount、pay_amount、pay_method、status、paid_at。order_no要生成一个唯一单号，我习惯用日期加随机数，比如20250520143012001。

库存表inventory_item和流水表inventory_ledger是配套的，和会员余额一个道理，库存表存当前数量，流水表记录每次入库出库的变动，才能追溯。服务项目和耗材要用一张中间表service_item_material关联，因为一个项目可能消耗多种耗材，一种耗材也可能用于多个项目。

时间字段统一用datetime类型，不要用时间戳整数，方便调试。每张表都建议加created_at、updated_at和deleted_at，记录逻辑删除时间。所有表的主键用bigint自增即可，这个项目规模根本不需要分布式 ID。

3.3 容易漏掉的业务设计细节

第一个容易漏的是“一个会员多辆车”的关系。很多新手只给 member 表加一个car_no字段，这是错误的。正确的做法是单独一张car表，字段包含id、member_id、plate_no、brand、model、mileage，一个会员可以有多辆车。洗车美容业务天然和车绑定，订单要记录“哪个会员的哪辆车”，不然以后查历史很难受。

第二个容易漏的是预约状态流转。预约表的状态不应只有“已预约/已完成”两个值，建议是pending待确认、confirmed已确认、in_service施工中、completed已完成、cancelled已取消。每次状态变更最好都记录操作时间。这样做的好处是，统计每个工位使用率时，你只统计confirmed和in_service状态的预约，能算出真实的工位饱和度。

第三个容易漏的是删除策略。会员如果删除了，那他的历史订单怎么算？我的建议是所有业务表都做逻辑删除，真实数据永远保留，只在界面上隐藏。特别是涉及钱的表，绝对不能用物理删除，否则月底对不上账的时候，你哭都来不及。

4. 核心功能实现与实操记录

4.1 后端登录鉴权：用 JWT 还是 Session

这个小系统我推荐用 JWT。理由很简单，Vue 前端请求 PHP 接口，如果用 Session 会涉及跨域携带 Cookie 的问题，需要额外配置跨域凭证，比较麻烦。JWT 无状态，前端拿到 token 后存起来，每次请求带在请求头里就行。

PHP 端实现 JWT 有两种方式，一种是引入firebase/php-jwt这个库，安全可靠；另一种是自己写一段简单的 base64 签名。毕业设计阶段建议用前一种，答辩时被问安全细节，你可以说“使用的是成熟的 JWT 开源实现，签名算法为 HS256”。

登录接口核心代码如下：

// 控制器方法 public function login(Request $request): Json { $mobile = $request->post('mobile'); $password = $request->post('password'); $user = User::where('mobile', $mobile)->find(); if (!$user || !password_verify($password, $user->password_hash)) { return ApiResponse::error('账号或密码错误'); } $payload = [ 'uid' => $user->id, 'iat' => time(), 'exp' => time() + 7200 ]; $token = JWT::encode($payload, env('JWT_SECRET'), 'HS256'); return ApiResponse::success(['token' => $token, 'user' => $user->hidden(['password_hash'])]); }

注册时密码不要明文存储，用password_hash()加盐哈希，验证时用password_verify()。这个细节写进论文里也是亮点，证明你懂密码安全。JWT_SECRET放在.env文件里，不要写在代码里。

4.2 预约冲突检测：整个系统最见功力的地方

预约模块是最容易被简单实现的，很多人直接在页面上拉起一个时间选择器，提交后不管不顾就入库了。这样做出来的系统实际用不了几天，因为技师和工位冲突会让人抓狂。

正确的做法是提交预约时做三重检查：

第一重：检查该技师在时间段内有没有其他预约。 第二重：检查该工位在时间段内有没有其他预约。 第三重：检查会员同一时间段有没有重复预约。

这三个检查可以抽象成一个方法，核心 SQL 是查询重叠区间：

public function checkConflict(int $technicianId, int $pitId, int $memberId, string $date, string $start, string $end): bool { $hasConflict = Appointment::where('appointment_date', $date) ->where('status', 'in', ['pending', 'confirmed', 'in_service']) ->where(function ($query) use ($technicianId, $pitId, $memberId, $start, $end) { $query->where('technician_id', $technicianId) ->orWhere('pit_id', $pitId) ->orWhere('member_id', $memberId); }) ->where('start_time', '<', $end) ->where('end_time', '>', $start) ->count(); return $hasConflict > 0; }

这段 SQL 的逻辑是经典的区间重叠判定：两个区间不重叠的条件是“一个的开始时间大于等于另一个的结束时间”，所以反过来，重叠的条件就是“开始时间小于对方结束时间 且 结束时间大于对方开始时间”。

预约提交成功后，还要在同一个事务里做两件事：一是生成一条施工任务供技师在手端或看板上查看，二是锁定对应工位的时间段，避免别人再约进去。我在事务里用SELECT ... FOR UPDATE对appointment表加了行锁，防止并发情况下两条预约同时提交导致冲突漏检。虽然这个小系统并发量不高，但这个细节值得写进文档。

4.3 前端预约看板：Vue 业务的集中体现

预约看板是前端最核心的页面，视觉效果很直观：顶部是日期选择器，中间按工位分列，每一列显示当天该工位的预约时间块。我用 Element Plus 的el-calendar做了个基础版，但这个组件自定义粒度有限，后来干脆直接用el-table加自定义样式来渲染时间槽。

核心思路是：打开页面时请求当天全部预约数据，在前端按pit_id分组，再按start_time排序，渲染成每个工位的时间线。

const loadAppointments = async () => { const res = await api.get('/appointment/list', { params: { date: currentDate.value } }) const list = res.data.data || [] pitList.value.forEach(pit => { pit.appointments = list .filter(item => item.pit_id === pit.id) .sort((a, b) => a.start_time.localeCompare(b.start_time)) }) }

页面模板部分，我用一个el-row循环pitList，每个工位一列，列里用卡片式 div 渲染预约块。点击空白时间块弹出新建预约弹窗，点击已有预约块弹出详情和快捷改状态按钮。这种交互模式，店长第一次用就能上手，不需要培训。

4.4 Python 脚本在系统里的真实定位

终于说到 Python 了。我把它定位成“离线的数据生产工具”，不和 PHP 抢实时接口，而是做三类事情。

第一类，Excel 会员数据批量导入。很多老店之前的会员信息都躺在 Excel 里，几百个会员不可能让店主手工录入系统。我写了一个 Python 脚本，用openpyxl读取原始表格，清洗手机号格式、处理缺失字段，然后用pymysql批量插入数据库。核心代码大概长这样：

import pymysql from openpyxl import load_workbook wb = load_workbook('members.xlsx') sheet = wb.active conn = pymysql.connect(host='127.0.0.1', user='root', password='123456', database='car_beauty', charset='utf8mb4') cursor = conn.cursor() for row in sheet.iter_rows(min_row=2, values_only=True): mobile = str(row[0]).strip() name = str(row[1]).strip() if row[1] else '' balance = float(row[2]) if row[2] else 0.0 # 简易校验：手机号长度不为11位则跳过 if len(mobile) != 11 or not mobile.isdigit(): print(f'skip invalid row: {row}') continue cursor.execute( 'INSERT INTO member (mobile, name, balance, created_at) VALUES (%s, %s, %s, NOW())', (mobile, name, balance) ) conn.commit() cursor.close() conn.close()

这段代码看起来简单，但实际跑的时候你会发现 Excel 里的手机号经常被识别成科学计数法，加上.strip()和类型强转非常必要。

第二类，库存预警。我写了一个脚本每天定时扫描inventory_item表里stock <= min_stock的物料，生成一张预警清单，然后推送到企业微信机器人。虽然我朋友店最后没真用这个通知，但脚本逻辑本身简单实用，写到论文里是个亮点。

第三类，月度对账报表。用pandas从订单表里按月汇总，按支付方式、服务项目、技师三个维度生成营收统计，最后输出成 Excel 表格发给店主。这里有一个坑，MySQL 的日期字段用 pandas 读取后是 Timestamp 格式，直接写入 Excel 没问题，但做条件筛选时要先转成字符串或 datetime 类型，否则查不出来。这个就对应了“python类型转换”那个热搜点，用的方法也很直白：

df['paid_at'] = pd.to_datetime(df['paid_at']) df['month'] = df['paid_at'].dt.to_period('M') monthly = df.groupby(['month', 'pay_method'])['pay_amount'].sum()

5. 常见问题与排查技巧实录

5.1 前端连不上后端：先把跨域和网络面板打开

这是最多人卡住的第一关。前端页面打开是空的，控制台报Access-Control-Allow-Origin错误，十有八九是跨域配置没生效。开发阶段的解决方案前面已经写了，Vite 里配proxy。如果配了还报错，排查顺序是：先确认 PHP 服务真的在8000端口跑着，再用浏览器直接访问http://127.0.0.1:8000/api/ping看有没有返回，最后检查 Vite 代理里target的地址和端口是否写错。

上线部署后如果接口 404 或者刷新页面白屏，多半是 Nginx 配置问题。PHP 后端要配置try_files来支持 ThinkPHP 的 pathinfo 模式，Vue 前端要配置try_files $uri $uri/ /index.html;来支持 history 路由，不然一刷新子路由页面就 404。这两条配置在宝塔里都能可视化填上去，网上随便搜都有具体模板。

5.2 PHP 环境的坑：从 track_errors 到 fileinfo

如果你在本地跑一个老项目或照搬老教程的代码，启动 PHP 时会碰到类似fatal error: directive 'track_errors' is no longer available in PHP in Unknown的报错。这个错误的意思是，PHP 8.0 已经把track_errors指令移除了，老教程里通过@符号和$php_errormsg获取错误信息的写法已经失效。解决方法是找到 php.ini 里对应配置并注释掉，同时不要再用$php_errormsg这个超全局变量。

还有一个很常见的坑是Call to undefined function think\session\session_start()或者文件上传时提示Fileinfo extension is not installed。很多 PHP 默认没启用 fileinfo 扩展，但 ThinkPHP 的文件验证、MIME 类型判断会用到它。宝塔面板在 PHP 设置里勾上 fileinfo 扩展，重启 PHP-FPM 就好。

内存限制也是高频问题。导入 Excel 时如果数据量大，PHP 脚本容易报Allowed memory size of 134217728 bytes exhausted。建议在.env或具体控制器里临时调大内存限制：

ini_set('memory_limit', '512M');

另外，用 PHP 做微信支付对接时，签名算法最容易出错。如果你用 PHP 官方的 v3 版微信支付 SDK，签名串拼接时注意Wechatpay-Timestamp和Wechatpay-Nonce是从请求头里取的，别写死。如果前后端都自己算 MD5，要特别注意字符串编码统一用 UTF-8，不然同样是 123456，算出来的 md5 差之千里。

5.3 Vue 依赖和类型转换的琐碎坑

Vue 项目装依赖时最常见的报错是Node Sass could not find a binding for your current Node version，这就是前面说的node-sass的问题。我基本建议所有新项目直接不要用node-sass，统一用sass，两个都在 package.json 里的话，把node-sass删掉重新npm install。

还有一个容易懵的问题是开发环境好好的，构建上线后白屏。大概率原因有两个：一是base路径没配，Vite 默认资源引用根路径/assets/，如果你部署在子目录，就要在vite.config.js里设base: './'；二是路由模式用了createWebHistory，Nginx 没配 fallback，解决办法已经在上面说过了。

pandas 和 Python 这块，有个让我折腾了一阵的问题：从 MySQL 查询出来有时间字段的数据，打印出来全是Timestamp('2024-05-20 14:30:00')格式，写入 Excel 虽然能显示，但和店里的格式对不上。后来统一用dt.strftime('%Y-%m-%d %H:%M')转成字符串，再去 groupby 和写入，格式完全可控。

5.4 联调时容易忽略的“业务状态”问题

除了环境上的技术问题，业务逻辑层面的 Bug 更加隐蔽。我举一个真实例子：会员用储值卡余额结算订单，前端先请求订单接口，后端扣减会员余额并在流水表里写入一条记录。但如果扣减成功、写入流水失败，钱就无缘无故“消失”了。解决办法是在数据库里用事务包住整个操作，任何一个环节失败就整体回滚。ThinkPHP 里这样写：

Db::transaction(function () { // 1. 扣减会员余额 // 2. 写入储值流水 // 3. 更新订单状态 // 4. 减少库存并写入库存流水 });

这四步全部成功，事务才提交，否则自动回滚。类似的还有预约创建和工单生成，也要放在同一个事务里。

另一个容易忽略的是状态机。建议给订单状态、预约状态都建立明确的枚举和流转规则，前端只允许按规则触发，比如“已完成”的订单不允许再取消；“已完成”的预约不能再修改时间。不要给前端太大自由度，否则测试阶段会发现各种奇怪的状态组合。

最后分享几个我做这个项目的真实体会

整个项目从开题到写完论文，我用了差不多 5 周时间，真正写代码其实只占了三周。最大的感受是，这类管理系统的技术含量不在于某个高深算法，而在于你能否把店里的真实业务管理逻辑转换成数据库表和接口设计。只要表结构合理、状态流转清晰、事务用得对，系统基本就稳了。

有一个小技巧想专门提一下：数据库设计完成后，不要急着写代码，先用 Python 脚本把测试数据跑一遍，特别是预约冲突检测、会员余额扣减、库存出库这些有状态变化的场景，把边界情况理清楚。等代码写完了再回头改数据库结构，是最折腾的过程。

如果你正打算做这个题目，我把这套思路完整送给你：开题报告围绕真实痛点写，技术选型强调各司其职，数据库设计重视流水和状态，代码实现把预约冲突检测和事务作为亮点，Python 脚本体现数据加工能力。照着这个节奏走下来，答辩顺利基本没有悬念。