当前位置：首页 > news >正文

水果生鲜在线商城PHP源码：含前后端完整代码、建库脚本与本地一键部署指南

news 2026/6/9 14:42:56

本文还有配套的精品资源，点击获取

简介：直接可运行的水果类电商网站源码，用PHP开发，MySQL存数据，前端基于HTML/CSS/JS实现，覆盖用户注册登录、商品分类展示、加入购物车、提交订单、查看订单详情、个人资料管理等全流程功能。项目目录结构清晰：www是网站根目录，src存放核心业务逻辑文件（如login-handler.php处理登录、signup_handler.php负责注册、shoplist.php展示商品列表、OrderInfo.php处理订单、profile.php管理个人信息），db目录下有create-table.sql建表语句，config.php统一配置数据库连接参数，Dao.php封装基础数据库操作。配套的项目说明.md写明了运行环境要求（PHP 7.2以上、MySQL 5.6以上、Apache或Nginx）、数据库导入步骤、各模块对应文件说明及常见问题提示。支持XAMPP/WAMP/LNMP等本地集成环境快速部署，无加密无混淆，注释较完整，适合学生做课程设计、毕业设计或PHP初学者练手。

1. 项目概述：这不是一个“玩具 demo”，而是一套能真实跑通电商闭环的PHP教学级生产原型

你有没有试过在毕业设计选题时，翻遍 GitHub 找一个“看起来像样”的电商系统，结果点开全是空壳页面、缺失数据库脚本、或者 login.php 里写着// TODO: 实现密码验证？我带过六届计算机专业课程设计，每年都有至少三分之一的学生卡在“部署不起来”这一步——不是代码写得差，而是缺了最关键的“最后一厘米”：一套真正能从零开始、本地双击启动、所有功能按钮都可点击、订单能生成、数据库能查到记录的完整闭环。这套水果生鲜在线商城源码，就是为解决这个痛点而生的。它不追求炫酷的 Vue3 + TypeScript + 微服务架构，而是用最朴素的 PHP 7.4（兼容 7.2+）、原生 MySQL 5.7、纯 HTML/CSS/JS 前端，把电商最核心的业务流——用户身份建立 → 商品发现 → 决策加购 → 支付前确认 → 订单落库 → 个人履约追踪——全部用可读、可调试、可修改的代码走通。关键词里的“水果电商”不是噱头，商品分类是按苹果、香蕉、橙子、草莓、进口车厘子等真实品类组织的；“PHP源码”意味着你打开 login-handler.php 就能看到 session_start() 后如何比对 $_POST[‘password’] 与数据库中 password_hash() 的结果；“MySQL建库”不是一句“请自行建表”，而是 db/create-table.sql 里明明白白写着CREATE TABLE users (id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) UNIQUE NOT NULL, ...)；“购物车功能”不是 localStorage 模拟，而是 cart_items 表与 users、products 表的三表关联查询；“本地部署”更不是“配置好环境自己摸索”，而是项目说明.md 里连 XAMPP 控制面板截图位置、phpMyAdmin 导入 SQL 的三个必点按钮（“导入”→“选择文件”→“执行”）都写清楚了。它面向的不是想造轮子的资深工程师，而是第一次独立完成 Web 全栈项目的本科生——你需要的不是“高大上”的技术名词堆砌，而是一个能让你在答辩现场流畅演示“我注册、我下单、我查订单、我改地址”的底气。我把它放在学生机房的局域网服务器上跑过一整个学期，200 多个学生同时访问 shoplist.php，Apache 默认配置下 CPU 占用率没超过 35%，这就是“教学级生产原型”的分寸感：足够健壮，又绝不复杂。

2. 整体架构设计与思路拆解：为什么用原生 PHP 而非框架？为什么数据库设计如此“克制”？

2.1 技术栈选择背后的教学逻辑：拒绝黑盒，拥抱可见性

很多初学者一上来就想学 Laravel 或 ThinkPHP，这本身没错，但问题在于：当Auth::attempt()返回 false 时，你真的知道底层发生了什么吗？是密码哈希算法不匹配？是数据库连接超时？还是中间件拦截了请求？这套源码坚持用原生 PHP，核心动机就一个——让每一行代码的因果关系都暴露在阳光下。比如登录处理，login-handler.php 只有 68 行，但它清晰地拆解了五个原子步骤：① 接收 POST 数据并过滤（filter_input(INPUT_POST, 'username', FILTER_SANITIZE_STRING)）；② 根据用户名查用户记录（SELECT * FROM users WHERE username = ?）；③ 验证密码（password_verify($_POST['password'], $user['password'])）；④ 设置会话变量（$_SESSION['user_id'] = $user['id']）；⑤ 跳转到首页（header('Location: /www/index.php')）。没有中间件、没有服务容器、没有自动路由映射，错误就发生在你肉眼可见的第 43 行。这种“低抽象度”设计，对学习者的价值远大于“快速开发”。我让学生对比过：用 Laravel 写登录，他们花 2 小时配环境、查文档、调依赖；用这套源码，20 分钟就能理解整个流程，并亲手把password_verify()换成md5()（虽然不安全，但能立刻看到“密码错误”的提示变化），这种即时反馈才是建立编程直觉的关键。

2.2 数据库设计的“最小完备原则”：8 张表如何覆盖电商主干流程？

看懂一个电商系统的数据库，比看懂代码更能把握业务本质。这套源码的 create-table.sql 定义了 8 张表，不多不少，刚好构成闭环：

表名	核心字段	业务意义	设计巧思
`users`	id, username, email, password, phone, address, created_at	用户身份主表	`username`加了 UNIQUE 约束，避免重复注册；`password`字段类型为 VARCHAR(255)，明确预留 bcrypt 哈希值空间（60 字符）
`categories`	id, name, description, sort_order	商品分类（水果大类）	`sort_order`字段支持后台拖拽排序，前端 shoplist.php 用`ORDER BY sort_order`直接渲染
`products`	id, category_id, name, description, price, stock, image_path, is_active	具体商品（红富士苹果、智利车厘子）	`is_active`字段实现软下架，无需物理删除，订单历史仍可追溯
`cart_items`	id, user_id, product_id, quantity, added_at	购物车明细	`user_id`和`product_id`组成联合索引，高频查询`SELECT * FROM cart_items WHERE user_id = ?`极快
`orders`	id, user_id, total_amount, status, created_at, updated_at	订单主表	`status`用 ENUM(‘pending’,’confirmed’,’shipped’,’delivered’,’cancelled’)，状态流转逻辑全在 OrderInfo.php 中硬编码，清晰无歧义
`order_items`	id, order_id, product_id, quantity, price_at_purchase	订单商品快照	关键！保存下单时的价格（`price_at_purchase`），避免商品调价影响历史订单金额
`order_status_log`	id, order_id, status, note, created_at	订单状态变更日志	每次更新 orders.status，自动 INSERT 一条日志，方便排查“用户说订单卡在待确认”这类问题
`user_addresses`	id, user_id, recipient, phone, province, city, district, detail, is_default	用户收货地址	`is_default`字段确保每个用户有且仅有一个默认地址，profile.php 地址管理页直接驱动

为什么没有“优惠券表”、“积分表”、“物流表”？因为它们不属于“最小可行电商”的主干。教学项目必须做减法——先让users → products → cart_items → orders → order_items这条数据链路 100% 跑通，再谈扩展。我在指导毕设时发现，强行加入优惠券逻辑，会让 70% 的学生陷入“折扣计算时机”（下单前？支付后？）和“库存预占”（优惠券生效是否要锁库存？）的混乱。这套设计用“克制”换来了“确定性”。

2.3 目录结构的意图：src 是“大脑”，www 是“门面”，db 是“基石”

项目目录不是随意堆放，而是按职责严格隔离：

www/—— Web 服务器根目录：这是 Apache/Nginx 真正对外提供服务的入口。index.php是首页，login.php是登录页，所有.php页面都放在这里。它的存在意义是：让开发者一眼看清“用户浏览器最终请求的是哪个文件”。当你在浏览器输入http://localhost/login.php，服务器就是从www/login.php开始执行。这里不放任何业务逻辑，只负责接收请求、调用 src 中的处理器、输出 HTML。
src/—— 业务逻辑中枢：这才是代码的心脏。Dao.php封装了所有数据库操作（增删改查），它内部使用 PDO 预处理语句，杜绝 SQL 注入；login-handler.php不是页面，而是纯粹的“动作处理器”，它被www/login.php表单的action属性调用，处理完跳转，绝不输出任何 HTML；OrderInfo.php是订单模块的“协调员”，它从 Dao 获取订单数据、调用格式化函数、组装给前端的数组。这种分离让代码可测试性极强——你可以单独 requiresrc/Dao.php，用 PHPUnit 写测试用例，而不用启动整个 Web 服务器。
db/—— 数据库基石：create-table.sql是唯一真相源。它不只是建表语句，更是业务规则的书面声明。比如products.stock字段定义为INT NOT NULL DEFAULT 0，这就强制规定了“库存不能为负”，后续所有减库存逻辑（如UPDATE products SET stock = stock - 1 WHERE id = ? AND stock > 0）都必须遵守这个契约。我要求学生每次修改数据库结构，必须先更新db/create-table.sql，再手动在 phpMyAdmin 执行，而不是直接在图形界面点点点——因为只有 SQL 文件才能被 Git 版本控制，才能让团队协作不出现“你的数据库比我多一个字段”的灾难。

提示：不要试图把src/目录放到www/下面！这是新手最大误区。www/是公开可访问的，如果src/Dao.php在www/src/里，攻击者可能直接访问http://localhost/src/Dao.php看到数据库密码。正确做法是将www/设为 Web 根目录，src/和db/放在其同级目录，通过require_once '../src/Dao.php';包含，这样src/目录本身无法被 URL 直接访问。

3. 核心功能模块解析与实操要点：从登录到下单，每一步都在教你“为什么这么写”

3.1 用户认证模块：密码安全不是“加个 password_hash()”就完了

登录注册看似简单，却是安全重灾区。这套源码在signup_handler.php和login-handler.php中埋了三层防护：

第一层：输入净化与基础校验

// signup_handler.php 片段 $username = filter_input(INPUT_POST, 'username', FILTER_SANITIZE_STRING); $email = filter_input(INPUT_POST, 'email', FILTER_SANITIZE_EMAIL); if (strlen($username) < 3 || strlen($username) > 20) { die("用户名长度需在3-20位"); } if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { die("邮箱格式不正确"); }

FILTER_SANITIZE_STRING会移除<script>标签，FILTER_SANITIZE_EMAIL会清理邮箱中的非法字符。这不是过度防御，而是防止用户注册时输入admin<script>alert(1)</script>，然后在后台用户列表页触发 XSS。

第二层：密码哈希与盐值管理

// signup_handler.php 中密码存储 $password_hash = password_hash($_POST['password'], PASSWORD_ARGON2ID, [ 'memory_cost' => 65536, // 64MB 内存 'time_cost' => 4, // 迭代4次 'threads' => 3 // 使用3个线程 ]); // 插入数据库 $stmt = $pdo->prepare("INSERT INTO users (username, email, password) VALUES (?, ?, ?)"); $stmt->execute([$username, $email, $password_hash]);

注意：它用的是PASSWORD_ARGON2ID，而非过时的PASSWORD_BCRYPT。Argon2 是 2015 年密码哈希大赛冠军，抗 GPU 暴力破解能力更强。参数memory_cost=65536意味着需要 64MB 内存计算一次哈希，极大增加攻击者批量破解成本。而login-handler.php中的验证只需一行：

if (password_verify($_POST['password'], $user['password'])) { // 自动识别哈希算法和参数

password_verify()会自动解析$user['password']字符串开头的$argon2id$v=19$m=65536,t=4,p=3$...，无需你手动指定算法。

第三层：会话安全加固

// config.php 中的会话配置（关键！） ini_set('session.cookie_httponly', 1); // 防止 JS 读取 cookie ini_set('session.cookie_secure', 0); // 本地开发设为0，上线后改为1（仅HTTPS传输） ini_set('session.use_strict_mode', 1); // 禁止会话固定攻击 session_start();

session.use_strict_mode=1是杀手锏：当用户首次访问，PHP 生成一个新 session_id；如果攻击者诱骗用户访问?PHPSESSID=abc123，服务器会无视这个 ID，强制分配新 ID，彻底切断会话固定攻击链。

实操心得：我在测试时故意把session.cookie_secure设为 1，结果本地http://localhost登录后立即登出。花了 15 分钟才意识到——这是 HTTPS 强制导致的。教训是：本地开发务必确认config.php中session.cookie_secure为 0，上线前再改为 1，并配置好 SSL 证书。这个细节，90% 的教程都不会提。

3.2 购物车功能：不是 localStorage，而是真正的数据库持久化

很多“教学电商”把购物车存在浏览器 localStorage 里，关掉页面就没了。这套源码的购物车是真·服务端持久化，核心在cart_items表和src/CartManager.php（虽未在描述中提及，但实际存在）。

数据流向图（文字版）：

用户点击"加入购物车" (www/shoplist.php) ↓ AJAX POST 到 src/add-to-cart.php (携带 product_id, quantity) ↓ add-to-cart.php 查询 products 表检查库存 (SELECT stock FROM products WHERE id = ?) ↓ 库存充足？→ INSERT INTO cart_items (user_id, product_id, quantity) VALUES (?, ?, ?) 库存不足？→ 返回 JSON {"success":false, "msg":"库存不足"} ↓ 用户刷新 shoplist.php → 前端 JS 发起 GET 请求到 src/get-cart-count.php → 返回当前购物车商品总数

关键点在于库存检查与插入的原子性。add-to-cart.php中的代码是：

// 开启事务，确保“查库存”和“插购物车”要么都成功，要么都失败 $pdo->beginTransaction(); try { // 1. 查库存（FOR UPDATE 锁住该行，防止并发超卖） $stmt = $pdo->prepare("SELECT stock FROM products WHERE id = ? FOR UPDATE"); $stmt->execute([$product_id]); $stock = $stmt->fetchColumn(); if ($stock < $quantity) { throw new Exception("库存不足"); } // 2. 插入购物车 $stmt = $pdo->prepare("INSERT INTO cart_items (user_id, product_id, quantity) VALUES (?, ?, ?) ON DUPLICATE KEY UPDATE quantity = quantity + VALUES(quantity)"); $stmt->execute([$user_id, $product_id, $quantity]); // 3. 扣减库存（注意：这里是扣减，不是设置） $stmt = $pdo->prepare("UPDATE products SET stock = stock - ? WHERE id = ?"); $stmt->execute([$quantity, $product_id]); $pdo->commit(); } catch (Exception $e) { $pdo->rollback(); die(json_encode(["success"=>false, "msg"=>$e->getMessage()])); }

ON DUPLICATE KEY UPDATE保证了同一个用户对同一商品多次点击“加入购物车”，会自动合并数量（如第一次加 2 个，第二次加 3 个，最终 cart_items.quantity = 5）。而FOR UPDATE锁是并发安全的核心——当两个用户同时抢最后一瓶橙汁时，数据库会排队处理，第二个请求必须等第一个事务提交后才能读到更新后的库存，彻底避免超卖。

注意：FOR UPDATE只在 InnoDB 引擎和事务中有效。如果你用的是 MyISAM，这段代码会静默失效！务必在 phpMyAdmin 中确认products表的引擎是 InnoDB（SHOW CREATE TABLE products;结果中应有ENGINE=InnoDB）。

3.3 订单提交模块：如何保证“用户点了提交，钱没付，订单却生成了”？

订单创建是电商最敏感的环节。OrderInfo.php的逻辑设计体现了对“幂等性”和“状态机”的深刻理解：

订单创建的四步原子操作：
1.校验购物车：检查cart_items中所有商品是否is_active=1且stock >= quantity（再次校验，因为购物车创建后商品可能被下架或售罄）。
2.生成订单号：$order_no = 'ORD' . date('ymdHis') . str_pad(mt_rand(0, 9999), 4, '0', STR_PAD_LEFT);例如ORD2405201030220042，保证全局唯一且可读。
3.插入订单主表：INSERT INTO orders (user_id, total_amount, status) VALUES (?, ?, 'pending')，初始状态为pending（待确认），而非confirmed。
4.转移购物车数据：将cart_items中对应用户的记录，逐条插入order_items表，并记录price_at_purchase（从products.price读取），然后DELETE FROM cart_items WHERE user_id = ?清空购物车。

最关键的是状态流转。用户在www/checkout.php页面点击“提交订单”后，页面跳转到www/order-success.php，但此时订单状态仍是'pending'。真正的“确认支付”动作，是在模拟支付网关回调时由src/payment-callback.php完成的（项目中已预留接口，注释写了“此处应接入支付宝/微信 SDK”）。它会执行：

// payment-callback.php (伪代码) if ($payment_result == 'success') { $pdo->prepare("UPDATE orders SET status = 'confirmed', paid_at = NOW() WHERE order_no = ?")->execute([$order_no]); // 发送短信通知、更新库存（永久扣减）等... }

这种设计的好处是：如果用户点了提交但网络中断，订单停留在pending状态，管理员可在后台看到并手动处理；如果支付成功回调失败，订单不会被误标为confirmed，资金安全有保障。

4. 本地一键部署全流程实录：XAMPP/WAMP/LNMP 下的“三分钟启动指南”

4.1 环境准备：版本确认比安装更重要

别急着下载 XAMPP！先确认你的系统是否满足最低要求：

Windows 用户：右键“此电脑”→“属性”，查看系统类型是 64 位还是 32 位。XAMPP 官网明确标注：“Windows 10/11 64-bit recommended”。如果你是 32 位系统，必须下载旧版 XAMPP（如 7.4.33），因为新版只支持 64 位。
macOS 用户：打开“终端”，输入php -v。如果显示PHP 8.1.x或更高，恭喜，系统自带 PHP 可能已满足要求（但 MySQL 需另装）。如果低于 7.2，老老实实用 Homebrew 安装：brew install php@8.1 mysql。
Linux 用户（Ubuntu）：sudo apt update && sudo apt install apache2 mysql-server php libapache2-mod-php php-mysql。注意：Ubuntu 22.04 默认 PHP 是 8.1，但php-mysql包名在新版是php-mysqlnd，别装错。

提示：在 XAMPP 控制面板启动 Apache 和 MySQL 后，务必打开浏览器访问http://localhost/phpmyadmin/。如果打不开，90% 的原因是端口冲突——Skype、腾讯会议、甚至某些杀毒软件会占用 80 端口。解决方案：在 XAMPP 控制面板，点击 Apache 右侧的Config→Apache (httpd.conf)，找到Listen 80，改成Listen 8080，然后重启 Apache。之后访问http://localhost:8080/phpmyadmin/。

4.2 数据库导入：三步走，避开“表不存在”陷阱

db/create-table.sql是金标准，但直接双击导入常失败。正确姿势：

创建数据库：在 phpMyAdmin 左侧导航栏，点击“新建”，数据库名填fruit_shop（必须和config.php中的DB_NAME一致），排序规则选utf8mb4_unicode_ci（支持 emoji 和中文）。
导入 SQL：点击刚创建的fruit_shop数据库 → 顶部菜单“导入” → “选择文件” → 找到你的db/create-table.sql→ 滚动到底部，确认“格式”是SQL，“字符集”是utf8mb4→ 点击“执行”。
验证导入：导入完成后，左侧数据库列表展开fruit_shop，你应该看到 8 张表（users, categories, products…）。如果只有 1 张或报错，大概率是 SQL 文件编码问题。用记事本打开create-table.sql，另存为 UTF-8 编码（不要选“UTF-8-BOM”）。

实操心得：我遇到过最诡异的问题是——导入成功，但www/login.php报错Table 'fruit_shop.users' doesn't exist。排查半小时，发现config.php里写的数据库名是fruitshop（少了个下划线）。永远相信 SQL 文件，怀疑配置文件。建议在config.php顶部加一行注释：// DB_NAME 必须与 phpMyAdmin 中创建的数据库名完全一致（包括大小写、下划线）。

4.3 代码放置与配置：www 目录的“神圣不可侵犯性”

这是部署成败的临界点：

绝对禁止：把整个压缩包解压到C:\xampp\htdocs\下，得到C:\xampp\htdocs\xFAWkml0gu65DUB6VVnB-master-4072eb3daf91d2a2eb7263ede8d1bcb5ee13178b\www\。这样访问http://localhost/www/login.php才能打开，但www/成了 URL 路径的一部分，所有相对链接（如<img src="images/apple.jpg">）都会错乱。
正确做法：将www/目录下的全部内容（index.php, login.php, css/, js/, images/ 等），复制粘贴到C:\xampp\htdocs\下。同时，将src/,db/,config.php等同级目录和文件，也复制到C:\xampp\htdocs\下。最终htdocs目录结构应为：
htdocs/ ├── index.php # 来自原 www/ 目录 ├── login.php ├── signup.php ├── css/ ├── js/ ├── images/ ├── src/ # 来自原项目根目录 ├── db/ # 来自原项目根目录 ├── config.php # 来自原项目根目录 └── project说明.md
这样，http://localhost/login.php就是正确的 URL，www/只是一个本地文件夹名，不参与 URL 构建。

4.4 首次运行排障：从白屏到首页的 5 分钟急救包

启动 Apache 和 MySQL 后，访问http://localhost/，如果看到白屏或 500 错误，按顺序检查：

检查 PHP 错误日志：XAMPP 日志在C:\xampp\apache\logs\error.log。打开它，看最后几行是否有Fatal error: Uncaught PDOException...。如果有，99% 是config.php数据库连接参数错了。
手动测试数据库连接：在htdocs/下新建一个test-db.php文件：
```php
getMessage(); } ?>

`` 访问http://localhost/test-db.php，如果失败，问题一定在config.php。 3. **检查文件权限（Linux/macOS）**：chmod -R 755 htdocs/，确保 Apache 用户（通常是www-data或_www）有读取权限。ls -l htdocs/应显示-rwxr-xr-x。 4. **关闭 display_errors（生产环境）**：如果error.log里满是Notice: Undefined index，说明config.php中的display_errors = On。在config.php末尾加上ini_set(‘display_errors’, 0);`，错误只写日志，不显示给用户。

5. 常见问题与排查技巧实录：那些让我熬夜到凌晨三点的坑

5.1 “注册成功，但登录时报错：密码错误”——密码哈希的隐形陷阱

现象：signup_handler.php显示“注册成功”，但用相同账号密码登录，login-handler.php总是返回“密码错误”。

排查路径：
- 第一步：登录 phpMyAdmin，查看users表中刚注册用户的password字段。如果值是类似$2y$10$9bZV...（bcrypt），但你的 PHP 版本是 7.3+，而password_hash()默认用的是PASSWORD_ARGON2ID，那么password_verify()会因算法不匹配而失败。
- 第二步：检查signup_handler.php中password_hash()的第一个参数。如果是PASSWORD_ARGON2ID，但你的服务器不支持（phpinfo()中搜索argon2，没有则不支持），就会退化为PASSWORD_BCRYPT，但config.php可能没开启 Argon2 扩展。
-终极解决方案：统一降级为PASSWORD_BCRYPT。修改signup_handler.php：
php // 替换原来的 PASSWORD_ARGON2ID $password_hash = password_hash($_POST['password'], PASSWORD_BCRYPT, ['cost' => 12]);
cost=12表示 2^12=4096 次迭代，安全且兼容所有 PHP 5.5+ 版本。

5.2 “购物车数量总是 0，即使已添加商品”——Session 路径的幽灵

现象：用户登录后，在商品页点击“加入购物车”，页面弹窗显示“已加入”，但右上角购物车图标数字仍是 0。

原因：session.save_path配置错误。PHP 默认把 session 文件存在/tmp，但在 Windows 上，XAMPP 的 session 路径是C:\xampp\tmp。如果这个目录不存在或权限不足，session_start()会静默失败，导致$_SESSION['user_id']为空，src/get-cart-count.php查询cart_items时WHERE user_id = NULL，自然查不到。

修复：
- 打开C:\xampp\php\php.ini，搜索session.save_path。
- 确认其值为C:\xampp\tmp（Windows）或/Applications/XAMPP/xamppfiles/temp（macOS）。
- 手动创建该目录（如果不存在），并赋予完全控制权限（Windows 右键目录→属性→安全→编辑→添加Everyone→勾选“完全控制”）。

5.3 “订单提交后，订单详情页显示空白”——路径引用的绝对与相对之殇

现象：www/OrderInfo.php页面一片空白，查看源码发现<div class="order-details">标签后就没有内容了。

根源：OrderInfo.php中有一行require_once 'src/OrderProcessor.php';。如果OrderInfo.php是通过http://localhost/OrderInfo.php访问的，那么require_once的相对路径基准是htdocs/目录，所以它能找到htdocs/src/OrderProcessor.php。但如果有人通过http://localhost/www/OrderInfo.php访问（比如从旧书签），基准就变成了htdocs/www/，于是它试图加载htdocs/www/src/OrderProcessor.php，文件不存在，PHP 报致命错误，页面中断。

一劳永逸的解法：在所有require_once前，定义一个绝对路径常量：

// 在 config.php 顶部添加 define('ROOT_PATH', dirname(__DIR__)); // __DIR__ 是当前文件所在目录，__DIR__ 的上一级就是项目根目录 // 在 OrderInfo.php 中 require_once ROOT_PATH . '/src/OrderProcessor.php';

这样，无论从哪个 URL 访问，ROOT_PATH永远指向htdocs/，路径永不迷路。

5.4 “图片不显示，全是小图标”——Web 服务器的 MIME 类型失语症

现象：商品图片<img src="images/strawberry.jpg">在浏览器中显示为破损图标。

检查清单：
- ✅images/strawberry.jpg文件确实存在于htdocs/images/目录下。
- ✅ 文件名大小写完全匹配（Linux 服务器区分大小写，Strawberry.jpg≠strawberry.jpg）。
- ✅ 浏览器开发者工具（F12）→ Network 标签，点击图片请求，看 Status 是否为404或403。
- 如果是404，路径错了，检查src属性。
- 如果是403，Apache 拒绝了访问，检查htdocs/images/目录的.htaccess文件（如果有，删掉）或 Apache 配置。
- ✅ 最隐蔽的：Apache 的mod_mime模块未启用。在 XAMPP 控制面板，点击 Apache 右侧Config→Apache (httpd.conf)，搜索LoadModule mime_module，确认前面没有#注释。如果没有，去掉#，重启 Apache。

常见问题速查表（精简版）

问题现象	最可能原因	一句话修复
访问`http://localhost/`显示“403 Forbidden”	`htdocs/`目录下没有`index.php`或`index.html`	把`www/`目录下的`index.php`复制到`htdocs/`根目录
`login.php`提交后跳转到空白页	`login-handler.php`中`header('Location: ...')`后有`echo`或空格	删除`header()`后的所有输出，确保它是响应的第一行
`config.php`修改数据库密码后，所有页面报错	`config.php`文件末尾有多余空格或 BOM 字节	用 Notepad++ 打开，编码→转为 UTF-8 无 BOM 格式，保存
`www/profile.php`显示“Fatal error: Call to undefined function get_user_info()”	`profile.php`忘记`require_once 'src/ProfileManager.php';`	在`profile.php`开头添加`require_once '../src/ProfileManager.php';`（注意路径）
支付回调`payment-callback.php`无法被外部访问	Apache 的`.htaccess`禁止了`.php`文件执行	检查`htdocs/`下是否有`.htaccess`，临时重命名它，测试是否恢复

6. 项目延伸与二次开发指南：从“能跑”到“能用”的进阶路径

这套源码的价值，不仅在于它能跑起来，更在于它为你铺好了通往真实项目的升级之路。我带过的优秀毕业生，都是从这里出发，做出了让企业 HR 主动要简历的作品。

6.1 功能增强：三个“低垂果实”，让项目立刻脱颖而出

果实一：商品搜索与筛选（2 小时可完成）
- 在shoplist.php顶部添加搜索框<input type="text" name="q" placeholder="搜索苹果、香蕉...">。
- 修改src/ProductDao.php中的getProducts()方法，支持WHERE name LIKE ? OR description LIKE ?。
- 前端用 AJAX 加载，避免整页刷新。效果：用户输入“橙”，立刻列出所有含“橙”字的商品，搜索框右侧显示“共 12 个结果”。

果实二：订单状态邮件通知（1 小时）
- 利用 PHP 内置mail()函数（需配置 SMTP）或更简单的PHPMailer库（composer require phpmailer/phpmailer）。
- 在src/OrderProcessor.php的订单创建成功后，添加：
php use PHPMailer\PHPMailer\PHPMailer; $mail = new PHPMailer(true); $mail->setFrom('no-reply@fruitshop.local', '水果商城'); $mail->addAddress($user_email); $mail->isHTML(true); $mail->Subject = '您的订单已创建'; $mail->Body = "订单号：{$order_no}，总金额：{$total}元。我们将在24小时内发货。"; $mail->send();
效果：用户注册邮箱立刻收到一封格式美观的订单确认邮件，专业感倍增。

果实三：后台简易管理（3 小时）
- 新建admin/目录，放置login.php（管理员登录）、dashboard.php（订单列表）、products-edit.php（商品增删改）。
- 复用src/Dao.php的数据库连接，只增加管理员身份校验（if ($_SESSION['role'] !== 'admin') die('无权访问');）。
- 效果：你拥有了一个真实的“小老板后台”，可以随时上下架商品、查看今日订单，答辩时演示“我不仅能买，还能管”。

6.2 技术升级：平滑过渡到现代 PHP 生态

当你的项目稳定运行后，下一步不是推倒重来，而是渐进式升级：

引入 Composer 自动加载：删除所有require_once，在composer.json中定义"autoload": {"psr-4": {"App\\": "src/"}}，运行composer dump-autoload，然后在www/index.php中require_once 'vendor/autoload.php';，之后new App\Dao();即可。
迁移到 MVC 模式：将src/目录重构为app/Controllers/,app/Models/,app/Views/。www/index.php变成单一入口，根据 URL 路由到不同 Controller。这一步让你无缝衔接 Laravel 学习。
API 化改造：将src/中的处理器（如login-handler.php）重写为返回 JSON 的 API 端点（/api/login），前端用 Fetch API 调用。这为未来用 Vue/React 重写前端打下基础。

6.3 毕业设计答辩锦囊：评委最爱听的三个故事

答辩不是代码朗诵，而是讲好“我解决了什么问题”的故事：

故事一：《一个关于并发的深夜》
“在测试购物车时，我发现两个用户同时抢最后一箱草莓，出现了超卖。我研究了数据库锁机制，实现了SELECT ... FOR UPDATE事务，并用 Apache Bench 工具模拟 100 并发请求，验证了库存扣减的准确性。这让我深刻理解了‘理论上的 ACID’和‘工程中的 CAP’的区别。”
故事二：《从白屏到彩蛋》
“项目初期，config.php的一个空格导致全站白屏。我学会了阅读 Apache 错误日志，掌握了phpinfo()和var_dump()的组合技。后来，我在www/目录下添加了一个debug-info.php，一键显示数据库连接状态、PHP 版本、当前会话 ID，这成了我的开发神器。”
故事三：《用户教会我的事》
“我邀请室友当测试员。她第一次注册时，把手机号输成了 QQ 号，系统没拦住。我立刻在signup_handler.php中增加了filter_var($_POST['phone'], FILTER_VALIDATE_INT)校验，并在前端加了type="tel"和pattern属性。这让我明白，‘可用性’不是写在需求文档里的词，而是用户皱眉的那一刻。”