简介这份资源是一份基于PHP的化妆品销售网站毕业设计文档面向计算机相关专业学生及需要完成电商类课程设计或毕业设计的学习者帮助解决从选题、系统分析到功能实现与论文撰写的一整套问题。压缩包内共1个docx文件约475KB内容为完整的毕业设计论文初稿涵盖摘要、引言、系统架构与开发工具、需求与可行性分析、业务流程与数据流分析、系统功能与数据库设计、前后台模块详细实现、系统测试及总结等章节。文档以B/S架构为基础采用PHP搭建网站配合Sublime Text开发工具与Navicat for MySQL数据库具体涉及会员注册登录、购物车、订单处理、产品浏览收藏、商品管理、用户管理等功能模块。目前已有38人学习下载适合作为电商网站开发类课题的参考案例读者可从中获取系统设计思路、数据库表结构规划、功能模块实现方法以及论文写作框架便于快速理解项目全貌并迁移到自己的设计任务中。1. 从一份“初稿”说起PHP 化妆品销售网站到底要解决什么问题很多人拿到“基于 PHP 的化妆品销售网站的设计与实现”这个题目第一反应是套模板找个开源商城改改皮肤把商品图换成口红和精华论文里贴几张截图就交差。但真正做过的人知道化妆品这个品类对系统的要求跟卖书、卖数码完全不是一回事。它有三个绕不开的特点SKU 属性极其复杂同一款粉底有十几个色号、多个容量、保质期和批次必须可追溯、促销玩法密集满减、赠品、小样、套装拆卖。这些需求直接决定了数据库怎么设计、购物车怎么存、订单怎么拆。这份“初稿”要落地的其实是一套能跑通“浏览—加购—下单—支付回调—后台发货”闭环的 PHP 应用。它适合两类人一是正在做课程设计或毕业设计的同学需要一套结构清晰、能讲清楚设计理由的实现二是刚接手小型电商项目的 PHP 开发者想用最低的依赖成本把业务跑起来。技术栈上常见做法是 PHP 7.4 或 8.x 搭配 MySQL 5.7/8.0前端用原生 HTML jQuery 或轻量框架服务器用 Nginx PHP-FPM。不追求高并发但要求逻辑正确、边界清楚、能复现。这一章先把“化妆品销售网站”和普通商城的差异点摆出来后面几章再逐个拆解数据库、购物车、下单流程和后台管理。读完之后你应该能自己判断哪些开源方案能直接用哪些地方必须自己写。2. 化妆品销售网站的数据库设计与 PHP 环境搭建2.1 为什么化妆品 SKU 不能只用一张商品表普通商品表products(id, name, price, stock)在化妆品场景下会立刻崩掉。一支口红有 12 个色号每个色号独立库存、独立条码如果全塞进一张表要么字段爆炸要么用逗号拼接色号——后者查询和扣库存都会变成灾难。正确做法是拆成三层SPU标准产品单位代表“某品牌某系列口红”、SKU具体可售单元代表“该口红 #330 色号 3.5g”、属性表颜色、容量、肤质适用。-- SPU商品主体只描述共性 CREATE TABLE spu ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(120) NOT NULL, brand_id INT NOT NULL, category_id INT NOT NULL, description TEXT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- SKU真正参与库存和价格计算 CREATE TABLE sku ( id INT PRIMARY KEY AUTO_INCREMENT, spu_id INT NOT NULL, sku_code VARCHAR(64) UNIQUE NOT NULL, color VARCHAR(32), volume VARCHAR(32), price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, batch_no VARCHAR(64), expire_date DATE, INDEX idx_spu (spu_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;逻辑说明spu表负责前台列表页和详情页的展示聚合sku表负责加购、下单、扣减库存。batch_no和expire_date是化妆品特有的字段用于临期预警和批次追溯。参数上price用DECIMAL(10,2)而不是FLOAT避免浮点误差导致对账差几分钱sku_code加唯一索引防止运营重复录入。2.2 用 Docker 在本地拉起 PHP MySQL 环境手工装 PHP、扩展开一堆、再配 Nginx 太慢常见做法是用 Docker Compose 一次性拉起。下面这份配置可以直接抄目录结构是docker-compose.yml和src/放代码。version: 3.8 services: php: image: php:8.1-fpm volumes: - ./src:/var/www/html depends_on: - mysql nginx: image: nginx:1.24 ports: - 8080:80 volumes: - ./src:/var/www/html - ./nginx.conf:/etc/nginx/conf.d/default.conf depends_on: - php mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: cosmetics ports: - 3306:3306 volumes: - ./data:/var/lib/mysql启动命令是docker compose up -d然后进容器装扩展docker compose exec php docker-php-ext-install pdo_mysql mysqli。注意 MySQL 8.0 默认认证插件是caching_sha2_password老版本 PHP 的mysqli可能连不上稳妥做法是在my.cnf里加default-authentication-pluginmysql_native_password或者直接用 PDO 并确认pdo_mysql已启用。2.3 连接数据库与基础配置的 PHP 写法?php // config/db.php $dsn mysql:hostmysql;dbnamecosmetics;charsetutf8mb4; $options [ PDO::ATTR_ERRMODE PDO::ERRMODE_EXCEPTION, // 出错抛异常别静默 PDO::ATTR_DEFAULT_FETCH_MODE PDO::FETCH_ASSOC, PDO::ATTR_EMULATE_PREPARES false, // 用真预处理防注入 ]; try { $pdo new PDO($dsn, root, root123, $options); } catch (PDOException $e) { error_log(DB connect failed: . $e-getMessage()); exit(数据库连接失败); }ATTR_EMULATE_PREPARES false是关键参数它让 MySQL 真正执行预处理语句而不是 PHP 本地拼接能有效防 SQL 注入。charsetutf8mb4保证中文商品名和 emoji 描述不乱码。连接失败时写error_log而不是直接输出异常详情避免把数据库账号暴露给前端。3. 购物车、下单与支付回调的 PHP 实现3.1 购物车存 Session 还是存数据库这是化妆品网站最容易被问到的选型问题。Session 购物车实现快但用户换设备就丢数据库购物车能跨端同步但每次加购都要写库。实际项目里我一般用“未登录存 Session、登录后合并入库”的混合方案游客加购写$_SESSION[cart]登录瞬间把 Session 里的条目合并进cart表之后统一走数据库。?php // 登录后合并购物车 function mergeCart(PDO $pdo, int $userId, array $sessionCart): void { $stmt $pdo-prepare( INSERT INTO cart (user_id, sku_id, qty) VALUES (?, ?, ?) ON DUPLICATE KEY UPDATE qty qty VALUES(qty) ); foreach ($sessionCart as $skuId $qty) { $stmt-execute([$userId, $skuId, $qty]); } unset($_SESSION[cart]); }ON DUPLICATE KEY UPDATE依赖cart表上(user_id, sku_id)的唯一索引这样同一 SKU 重复加购会累加数量而不是插两条。参数qty在入库前必须做整数校验和上限判断比如单 SKU 最多 99 件防止恶意刷单。3.2 下单时如何安全扣减库存下单的核心是“扣库存 生成订单 清购物车”三件事必须放在一个事务里。化妆品大促时超卖是高频事故根源就是没加行锁或没做条件更新。?php $pdo-beginTransaction(); try { // 条件更新库存足够才扣返回受影响行数 $upd $pdo-prepare( UPDATE sku SET stock stock - ? WHERE id ? AND stock ? ); $upd-execute([$qty, $skuId, $qty]); if ($upd-rowCount() 0) { throw new RuntimeException(库存不足: sku . $skuId); } // 写订单主表和明细表 $pdo-prepare(INSERT INTO orders (user_id, total, status) VALUES (?, ?, 0)) -execute([$userId, $total]); $orderId $pdo-lastInsertId(); $pdo-prepare(INSERT INTO order_item (order_id, sku_id, qty, price) VALUES (?, ?, ?, ?)) -execute([$orderId, $skuId, $qty, $price]); $pdo-commit(); } catch (Throwable $e) { $pdo-rollBack(); error_log($e-getMessage()); exit(下单失败请重试); }WHERE id ? AND stock ?这个条件更新是防超卖的关键它把“判断”和“扣减”合成一条原子语句比先SELECT再UPDATE可靠得多。rowCount() 0说明库存不够或 SKU 不存在直接抛异常回滚。订单状态status用整数枚举0 待支付、1 已支付、2 已发货、3 已完成、4 已取消方便后续状态机扩展。3.3 支付回调的幂等处理支付平台回调可能重复推送如果每次回调都改订单状态、加积分、发短信就会重复执行。标准做法是给回调加唯一流水号落库前去重。?php // 回调入口 notify.php $raw file_get_contents(php://input); $data json_decode($raw, true); $tradeNo $data[trade_no] ?? ; // 幂等表trade_no 唯一索引 $ins $pdo-prepare(INSERT IGNORE INTO pay_log (trade_no, raw) VALUES (?, ?)); $ins-execute([$tradeNo, $raw]); if ($ins-rowCount() 0) { exit(success); // 已处理过直接返回成功 } // 首次处理更新订单状态 $pdo-prepare(UPDATE orders SET status 1 WHERE id ? AND status 0) -execute([$data[order_id]]); exit(success);INSERT IGNORE配合trade_no唯一索引实现幂等rowCount() 0表示这条回调之前来过。更新订单时加AND status 0保证只有待支付订单能被改成已支付避免已取消订单被回调“复活”。回调接口必须返回支付平台约定的成功标识这里是success否则平台会持续重推。4. 后台管理、跨浏览器兼容与常见排错4.1 后台商品与订单管理的 PHP 接口设计后台不需要花哨核心是商品 CRUD、订单列表和发货操作。接口用统一的 JSON 返回格式前端好处理。?php // api/order_list.php header(Content-Type: application/json; charsetutf-8); $page max(1, (int)($_GET[page] ?? 1)); $size min(50, max(1, (int)($_GET[size] ?? 20))); $offset ($page - 1) * $size; $total $pdo-query(SELECT COUNT(*) FROM orders)-fetchColumn(); $stmt $pdo-prepare( SELECT o.id, o.total, o.status, o.created_at, u.username FROM orders o JOIN users u ON u.id o.user_id ORDER BY o.id DESC LIMIT ? OFFSET ? ); $stmt-bindValue(1, $size, PDO::PARAM_INT); $stmt-bindValue(2, $offset, PDO::PARAM_INT); $stmt-execute(); echo json_encode([ code 0, data $stmt-fetchAll(), total (int)$total, ], JSON_UNESCAPED_UNICODE);分页参数必须做边界限制page最小为 1size最大 50防止有人传size999999把库拖垮。LIMIT和OFFSET用bindValue显式指定PDO::PARAM_INT因为 PDO 默认会把它们当字符串加引号导致 SQL 语法错误。JSON_UNESCAPED_UNICODE让中文商品名不被转成\uXXXX前端直接可读。4.2 跨浏览器支持表单、AJAX 与事件绑定的坑“跨浏览器支持的设计与实现”在化妆品网站里最常出问题的是三处fetch在旧版浏览器缺失、addEventListener与attachEvent差异、以及表单submit被重复绑定。现代项目直接放弃 IE但如果是课程设计环境里有旧内核浏览器就得做降级。// 兼容写法优先 fetch降级 XMLHttpRequest function postJSON(url, data, cb) { if (window.fetch) { fetch(url, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify(data) }).then(r r.json()).then(cb); } else { var xhr new XMLHttpRequest(); xhr.open(POST, url, true); xhr.setRequestHeader(Content-Type, application/json); xhr.onreadystatechange function () { if (xhr.readyState 4 xhr.status 200) { cb(JSON.parse(xhr.responseText)); } }; xhr.send(JSON.stringify(data)); } }加购按钮要用事件委托绑在父容器上而不是给每个按钮单独绑否则商品列表异步渲染后新按钮没有事件。表单提交前e.preventDefault()阻止默认跳转再用上面的postJSON发请求。注意Content-Type必须是application/jsonPHP 端才能用php://input正确读取用$_POST是读不到的。4.3 常见报错与排查路径现象可能原因排查动作页面空白无输出PHP 致命错误被关闭显示开display_errorsOn看error_log中文商品名乱码连接字符集不是 utf8mb4检查 DSN 和表字符集加购后购物车为空Session 未启动或跨域丢 Cookie确认session_start()在输出前调用支付回调不生效回调地址不可达或返回非 success看支付平台回调日志和pay_log表库存扣成负数用了先查后扣而非条件更新改成UPDATE ... WHERE stock ?排查顺序建议从日志入手Nginx 的error.log看 502/504PHP 的error_log看异常MySQL 的慢查询日志看锁等待。化妆品大促时如果出现大量下单超时优先怀疑sku表的行锁竞争可以考虑按 SKU 分片或引入 Redis 预扣库存。5. 用 Redis 预扣库存与压测验证下单链路当 SKU 只有几百个、并发不高时第 3 章的条件更新足够用。但化妆品秒杀场景下同一支口红可能几千人同时抢MySQL 行锁会让请求排队甚至超时。进阶做法是把库存预热到 Redis用 Lua 脚本原子扣减成功后再异步落库。?php // 预扣库存Redis Lua 保证原子性 $lua LUA local stock redis.call(GET, KEYS[1]) if not stock then return -1 end if tonumber(stock) tonumber(ARGV[1]) then return 0 end redis.call(DECRBY, KEYS[1], ARGV[1]) return 1 LUA; $result $redis-eval($lua, [sku:stock:{$skuId}, $qty], 1); if ($result 1) { // 预扣成功投递到队列异步创建订单 $redis-lPush(order:queue, json_encode([sku_id $skuId, qty $qty])); } elseif ($result 0) { exit(库存不足); } else { exit(库存未预热); }Lua 脚本在 Redis 里单线程执行GET和DECRBY之间不会被打断这是它比 PHP 层加锁更可靠的原因。返回值约定1 成功、0 不足、-1 未预热PHP 端据此分流。预扣成功后不要直接写 MySQL而是丢进队列由消费者慢慢落库削峰填谷。注意 Redis 库存和 MySQL 库存要对账常见做法是定时任务比对差异并告警。验证这套链路是否可靠最直接的办法是压测。用ab或wrk对下单接口打并发观察三个指标成功率、超卖数量、平均响应时间。# 200 并发、总共 2000 次请求POST 下单接口 ab -n 2000 -c 200 -p order.json -T application/json http://localhost:8080/api/order.php-n是总请求数-c是并发数-p指定 POST 数据文件-T指定 Content-Type。压测后去数据库执行SELECT sku_id, stock FROM sku和SELECT sku_id, SUM(qty) FROM order_item GROUP BY sku_id两者相加应等于初始库存差一件都说明有超卖。如果成功率低但没超卖多半是锁竞争导致超时可以调大 Redis 连接池或把队列消费者从单进程改成多进程。压测数据不要在生产库跑本地 Docker 环境足够暴露逻辑问题。本文还有配套的精品资源点击获取
