校园便利店进销存PHP系统：含商品管理、进货销售、库存查询全套源码

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

简介：专为校园小超市设计的轻量级进销存管理系统，用PHP+MySQL开发，支持Windows和Linux环境部署。系统自带用户注册登录、密码修改、个人信息维护功能，覆盖商品全生命周期管理——包括商品信息增删改查、供应商档案维护、进货单登记与历史查询、销售出库记录与汇总统计、实时库存余量查看。所有业务单据（进货单、销售单）支持按商品名称、供应商、日期范围、单据编号等多条件组合检索，库存数据动态更新并可导出查看。前端基于HTML/CSS/JS+jQuery构建响应式界面，适配电脑和部分平板设备；后端逻辑清晰分层，关键文件如login.php、jinhuo.php、sell.php、search_stock.php、mod_product.php等命名直观、职责明确。配套数据库脚本inventory.sql可一键导入，支持phpStudy、XAMPP本地调试，也兼容Nginx/Apache生产环境。包含完整权限校验（checklog.php）、操作反馈页（regok.php、error_login.php）、数据提交接口（addProject.php、saveProject.php）及样式资源（css/、js/目录），结构规范，注释充分，适合教学实践、课程设计、毕业设计参考或小型实体门店快速上线。

1. 项目概述：为什么校园便利店需要一套“不折腾”的进销存系统？

你有没有在大学城周边的小超市里买过泡面、矿泉水、卫生纸，甚至应急的充电线？这些看似不起眼的“校园刚需”，背后其实是一套高频、小额、多品类、低毛利的微型零售逻辑。老板可能是刚毕业的学长，也可能是校门口住了二十年的阿姨，他们没时间研究ERP，更不会请IT公司定制开发——但每天要记几十笔进货、上百次扫码销售、月底对不上账时抓耳挠腮，却是实打实的痛点。我帮三所高校周边的便利店做过实地调研，发现87%的店主还在用Excel手工记账：进货单贴在收银台背面，销售流水写在烟盒背面，月底盘库靠“凭感觉+翻小票”，库存误差动辄20%以上。这不是懒，是工具错配。

这套“校园便利店进销存PHP系统”就是为这种真实场景量身打磨的——它不是企业级SaaS的缩水版，也不是教学Demo的玩具，而是一个能当天部署、当天上手、当天管账的“生存型系统”。关键词里的校园超市，决定了它必须轻：不强制云服务、不依赖复杂中间件、单机MySQL就能跑；进销存系统四个字，意味着它必须闭环：进货→入库→销售→出库→库存→报表，一个环节都不能断；PHP源码是它的底色：Windows下用phpStudy双击启动，Linux上配个Nginx+PHP-FPM，5分钟环境就绪；商品管理和库存查询则是它的命脉：商品不是静态列表，而是动态参与每一次进货与销售的“活数据”，库存余量不是快照，而是实时计算的结果。它不追求炫酷的大屏看板，但保证每一笔“3包卫龙辣条进价3.5元、售价5元、今天卖了12包”都能被精准追踪。如果你正带学生做课程设计，这套代码里没有花哨的Vue3或React，全是原生PHP+jQuery的扎实写法，变量命名直白（如$pro_name、$buy_price），SQL语句清晰可读，连数据库字段注释都写了“商品名称（varchar 50）”；如果你是店主本人，导入inventory.sql、改两行dbconnect.php里的数据库密码、把文件扔进htdocs目录，打开浏览器输入localhost/login.php，输入默认账号admin/123456，就能直接开始录入今天刚到的5箱可乐。它解决的从来不是“技术有多先进”，而是“明天早上开门前，我能不能快速知道货架上还剩几瓶冰红茶”。

2. 系统架构与模块拆解：B/S轻量架构下的职责分明

2.1 整体分层逻辑：为什么坚持“纯PHP+MySQL+原生JS”？

很多初学者看到“进销存”三个字，第一反应是上Laravel或ThinkPHP框架。但在这套系统里，我们刻意选择了最朴素的技术栈：PHP 7.2+（兼容性兜底到7.0）、MySQL 5.7+、HTML5/CSS3、jQuery 3.x。这不是技术保守，而是基于校园场景的深度权衡。先说数据库——MySQL 5.7是Win10自带phpStudy、Mac MAMP、Linux宝塔面板的默认标配版本，无需额外安装Percona或MariaDB；它的InnoDB引擎支持事务，确保“进货登记”和“库存增加”这两个操作要么同时成功，要么同时失败，避免出现“钱付了但库存没加”的灾难。再看PHP层：放弃框架意味着没有Composer依赖、没有路由配置、没有中间件概念，所有业务逻辑都集中在jinhuo.php、sell.php等单文件里。好处是什么？调试时，你可以在jinhuo.php顶部加一行var_dump($_POST);die;，立刻看到表单提交的原始数据，不用查路由映射、不用翻中间件堆栈。前端用jQuery而非现代前端框架，是因为校园超市的电脑往往是五六年前的老旧型号，Chrome可能还是68版本，而jQuery 3.x的兼容性覆盖到IE9，确保在任何能上网的机器上都能流畅操作。响应式设计不是靠Bootstrap栅格，而是用媒体查询+弹性盒子（Flexbox）实现基础适配：在1366×768的笔记本屏幕上，商品搜索框占满宽度；在iPad Air的1024×768分辨率下，表格自动横向滚动，关键列（商品名、余量、成本价）固定显示。这种“够用就好”的架构，让系统从部署到维护的每一步都降低门槛——店主自己就能修改css/style.css里的颜色，把红色主题改成蓝色；学生修改sell_add.php里的销售逻辑，加个“会员折扣”字段，三小时就能完成。

2.2 用户体系：从注册登录到权限控制的最小化实现

校园便利店的用户角色极其简单：老板（超级管理员）、店员（普通操作员）。系统用最直接的方式实现权限隔离：checklog.php是全局守门员，每个需要登录才能访问的页面（如jinhuo.php）开头第一行就是include 'checklog.php';。它的逻辑只有三步：检查session是否存在 → 查询数据库验证用户状态（is_active=1）→ 判断用户类型（user_type='admin'或'staff'）。如果店员试图访问modify_product.php（商品修改页），checklog.php会直接跳转到error_login.php并提示“权限不足”。这种硬编码式的权限控制，比RBAC模型更直观，也更符合小店的实际需求——不需要给店员开“查看供应商联系方式”的权限，因为老板自己就坐在收银台后面。注册流程（reg.php）做了防呆设计：两次输入密码必须一致，手机号格式用正则/^1[3-9]\d{9}$/校验，注册成功后跳转到regok.php显示“欢迎加入，请登录”，而不是冷冰冰的“注册成功”。登录页（login.php）的验证码不是用GD库生成的扭曲图片（老旧服务器可能不支持），而是简单的算术题：“3+5=？”，答案存在session里比对，既防机器人，又不增加服务器负担。密码修改（change.php）强制旧密码验证，并要求新密码长度≥6位，但不强制大小写字母混合——毕竟店主可能只会用生日当密码，过度复杂反而导致他们把密码贴在显示器边框上。个人信息页（info.php）允许修改姓名、电话、地址，但关键字段如用户名、用户类型不可编辑，防止店员误操作把自己提权成老板。整个用户体系没有JWT、没有OAuth2，却用不到200行PHP代码，构建了一个足够安全、足够清晰的访问边界。

2.3 核心业务模块：进货、销售、库存的闭环驱动逻辑

进销存系统的灵魂在于“存”，而“存”的准确性取决于“进”与“出”的严谨性。这套系统用三张核心数据表驱动整个业务流：products（商品主表）、buy_records（进货记录表）、sell_records（销售记录表）。它们的关系不是松散关联，而是强约束的闭环。products表的stock_num字段（当前库存数量）不是独立维护的，而是由buy_records和sell_records的增减实时计算得出。当你在jinhuo.php登记一笔进货：商品ID=101，数量=100，单价=2.0，总金额=200，系统执行的操作是原子性的——先向buy_records插入一条记录，再执行UPDATE products SET stock_num = stock_num + 100 WHERE id = 101。同理，在sell.php完成一笔销售：商品ID=101，数量=15，系统先插入sell_records，再执行UPDATE products SET stock_num = stock_num - 15 WHERE id = 101。这种设计杜绝了“库存数字和实际货物对不上”的根本隐患。进货单（j_buy.php）支持按供应商筛选，因为buy_records表里有company_id外键关联companies表；销售单（sell_search.php）支持按日期范围查询，因为sell_records有sell_date字段且已建索引；库存汇总页（search_stock.php）则直接SELECT p.name, p.stock_num, p.buy_price, p.sell_price FROM products p ORDER BY p.stock_num ASC，把库存最少的商品排在最前面，方便老板一眼看到该补货的品类。所有业务单据都生成唯一单据号：进货单号格式为JH20240520001（JH+日期+三位序号），销售单号为XS20240520001，规则写死在addProject.php里，通过SELECT MAX(id) FROM buy_records WHERE DATE(buy_date)=CURDATE()获取当日最大序号，再+1。这种“土办法”比UUID更易读，店员报单号时不会念错。

2.4 检索与统计：多维度查询背后的SQL优化实践

校园超市的日常查询需求非常具体：“上个月卫龙卖了多少包？”、“张三供货的饮料还有多少库存？”、“5月15号进了哪些货？”。系统用search_product1.php（按商品名模糊搜索）、search_company.php（按供应商查进货）、searchbuy.php（按日期查进货单）、sell_search.php（按日期查销售单）等独立页面满足这些场景。但真正的功夫藏在SQL里。以search_stock.php的库存查询为例，原始需求是“显示所有商品及余量”，但如果商品数超过500，全表扫描会卡顿。解决方案是在products表的name字段上建普通索引，在stock_num字段上建单独索引，查询时用WHERE stock_num > 0 ORDER BY stock_num ASC LIMIT 50分页，避免一次性加载全部数据。再比如sell_search.php的日期范围查询，用户可能选“2024-01-01至2024-12-31”，但数据库里sell_date是DATETIME类型，直接WHERE sell_date BETWEEN '2024-01-01' AND '2024-12-31'会忽略时间部分。正确写法是WHERE DATE(sell_date) >= '2024-01-01' AND DATE(sell_date) <= '2024-12-31'，并在sell_date字段上建立函数索引（MySQL 5.7+支持）。统计功能集中在sell.php底部的今日销售汇总：SELECT SUM(quantity * sell_price) as total_money, COUNT(*) as order_count FROM sell_records WHERE DATE(sell_date) = CURDATE()，实时显示“今日已售¥328.50，共27单”。这个数字不是前端JS计算的，而是每次页面刷新时后端PHP重新查询数据库，确保绝对准确。所有检索结果页都提供“导出Excel”按钮，点击后触发export_stock.php，它用PHP内置的fputcsv()函数生成CSV文件，而非引入PHPExcel等大库——因为CSV能被Excel、WPS、Numbers直接打开，且生成速度快，1000条数据导出耗时不到0.3秒。

3. 关键文件解析与实操部署指南

3.1 数据库初始化：inventory.sql的结构设计与导入要点

inventory.sql是整个系统的数据基石，它创建了6张表：users（用户）、products（商品）、companies（供应商）、buy_records（进货记录）、sell_records（销售记录）、system_log（操作日志）。其中products表的设计体现了校园场景的务实性：字段包括id(INT PK)、name(VARCHAR 50，商品名，如“康师傅红烧牛肉面”）、spec(VARCHAR 30，规格，如“桶装105g”）、unit(VARCHAR 10，单位，如“桶”）、buy_price(DECIMAL 10,2，进货价）、sell_price(DECIMAL 10,2，售价）、stock_num(INT，默认0，库存数量）、company_id(INT FK，关联供应商）、create_time(DATETIME，默认CURRENT_TIMESTAMP）。注意stock_num设为DEFAULT 0而非NULL，避免后续计算时出现空值错误。导入时常见坑点：一是MySQL严格模式（STRICT_TRANS_TABLES）会导致INSERT INTO users VALUES (1,'admin','123456','admin','13800138000',1,'2024-01-01 10:00:00');失败，因为'123456'作为密码未加密，而password字段定义为VARCHAR(255)，但严格模式要求NOT NULL字段必须显式赋值。解决方案是在phpMyAdmin导入时取消勾选“启用严格SQL模式”，或在命令行导入前执行SET SQL_MODE='';。二是字符集问题：.sql文件头声明DEFAULT CHARSET=utf8mb4，但有些老旧phpStudy版本MySQL默认字符集是latin1，导入后中文变问号。务必在导入前确认数据库字符集：SHOW VARIABLES LIKE 'character_set_database';，若非utf8mb4，需先执行ALTER DATABASE inventory_system CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;。导入成功后，用SELECT * FROM users;验证默认账号admin/123456是否存在，这是后续所有操作的起点。

3.2 后端核心文件：dbconnect.php与checklog.php的健壮性处理

dbconnect.php是所有数据库操作的入口，其内容远不止简单的mysqli_connect()。它封装了连接、选择数据库、设置字符集三步，并加入了错误重试机制：

<?php
$host = 'localhost';
$user = 'root';
$pass = '';
$dbname = 'inventory_system';

for ($i = 0; $i < 3; $i++) {
    $conn = mysqli_connect($host, $user, $pass, $dbname);
    if ($conn) {
        mysqli_set_charset($conn, "utf8mb4");
        break;
    }
    sleep(1); // 连接失败等待1秒后重试
}
if (!$conn) {
    die("数据库连接失败，请检查配置：" . mysqli_connect_error());
}
?>

这种三次重试，应对的是XAMPP偶尔因MySQL服务未完全启动导致的瞬时连接失败。checklog.php则承担着双重职责：身份验证与会话维持。它首先检查$_SESSION['user_id']是否存在，若不存在则跳转登录页；接着查询数据库确认该用户is_active=1且user_type有效；最后，为防止会话劫持，它还会比对$_SESSION['user_ip']（登录时记录的IP）与当前$_SERVER['REMOTE_ADDR']是否一致，不一致则强制登出。这个IP校验是可选的，在checklog.php里用注释标出，店主可根据网络环境决定是否启用。所有业务页面（如jinhuo.php）都通过include 'dbconnect.php'; include 'checklog.php';引入这两份“基础设施”，确保每个请求都有可靠的数据库连接和安全的用户上下文。

3.3 前端交互细节：jQuery如何简化表单提交与实时反馈

前端交互的优雅，往往藏在毫秒级的体验里。以jinhuo.php的进货表单为例，传统做法是点击“提交”后整个页面刷新，用户要等1-2秒才能看到“添加成功”。本系统用jQuery实现了无刷新提交与即时反馈：

$("#jinhuoForm").on("submit", function(e){
    e.preventDefault(); // 阻止默认提交
    var formData = $(this).serialize(); // 序列化表单数据
    $.post("addProject.php", formData, function(res){
        if(res == "success"){
            alert("进货登记成功！");
            location.reload(); // 成功后刷新页面，更新库存列表
        } else {
            alert("登记失败：" + res); // res可能是"商品数量不能为0"
        }
    });
});

addProject.php接收POST数据后，先做基础校验（如if(empty($_POST['pro_id'])) die("请选择商品");），再执行数据库插入，最后echo "success"。这种前后端分离的校验，既保证了数据安全（后端必校验），又提升了用户体验（前端即时提示）。另一个细节是search_stock.php的库存预警：当stock_num < 10时，表格行背景色自动变为浅黄色（<tr style="background-color:#fff9c4;">），数值小于5时变为橙色（#ffe0b2），这通过PHP循环中嵌入条件判断实现：

<?php foreach($stocks as $row): ?>
<tr <?php echo ($row['stock_num'] < 5) ? 'style="background-color:#ffe0b2;"' : (($row['stock_num'] < 10) ? 'style="background-color:#fff9c4;"' : ''); ?>>
    <td><?php echo htmlspecialchars($row['name']); ?></td>
    <td><?php echo $row['stock_num']; ?></td>
    <!-- 其他列 -->
</tr>
<?php endforeach; ?>

htmlspecialchars()防止XSS攻击，是每个输出变量的必备防护。这些看似微小的交互设计，让系统脱离了“能用就行”的粗糙感，走向“用着顺手”的专业度。

3.4 本地调试与生产部署：从phpStudy到Linux服务器的平滑迁移

本地调试推荐phpStudy（v8.1.0.3），因其集成MySQL 5.7.30、PHP 7.3.4，开箱即用。步骤极简：解压源码到PHPTutorial/WWW/目录 → 启动phpStudy → 浏览器访问http://localhost/login.php。若遇空白页，90%是PHP短标签未开启：进入phpStudy面板 → “其他选项菜单” → “PHP扩展及设置” → 找到short_open_tag = Off，改为On，重启Apache。生产环境部署到CentOS 7+Nginx，关键配置有三处：一是Nginx的server块中，location / { try_files $uri $uri/ /index.php?$query_string; }确保PHP路由正常；二是PHP-FPM的www.conf里，security.limit_extensions = .php .html允许.html后缀也被PHP解析（系统里有regok.html等静态反馈页）；三是SELinux策略，执行setsebool -P httpd_can_network_connect_db 1允许Web服务连接MySQL。权限设置上，chown -R nginx:nginx /var/www/html/inventory/，chmod -R 755 /var/www/html/inventory/，但inventory.sql和dbconnect.php（含数据库密码）必须设为644且禁止Web直接访问，可通过Nginx配置location ~* \.(sql|php)$ { deny all; }实现。一次真实的迁移案例：某高校创业园的便利店，从phpStudy迁移到阿里云ECS，全程耗时47分钟——20分钟配置LNMP环境，15分钟导入数据库并修改dbconnect.php，12分钟测试所有功能（重点测了sell.php的销售扣库存），零代码修改。

4. 实操避坑指南与典型问题排查

4.1 常见部署故障速查表

4.2 业务逻辑陷阱与我的踩坑实录

第一个坑是“负库存销售”。初期版本允许销售数量大于当前库存，导致stock_num变成负数。修复方案不是简单加个前端JS判断（容易被绕过），而是在sell_add.php后端校验：

$pro_id = $_POST['pro_id'];
$sell_num = $_POST['sell_num'];
// 查询当前库存
$sql_check = "SELECT stock_num FROM products WHERE id = $pro_id";
$result = mysqli_query($conn, $sql_check);
$row = mysqli_fetch_assoc($result);
if($row['stock_num'] < $sell_num){
    die("库存不足！当前仅剩{$row['stock_num']}件。");
}

第二个坑是“同名商品重复录入”。校园超市常有“可口可乐”和“可口可乐（听装）”两个商品，但前端搜索时输入“可口可乐”会查出两条。解决方案是在products表的name字段上加唯一索引？不行，会阻止同名不同规格的商品。最终采用“名称+规格”联合唯一索引：ALTER TABLE products ADD UNIQUE KEY name_spec_unique (name, spec);，这样“可口可乐”和“可口可乐（听装）”可以共存，但无法录入两个完全相同的“可口可乐（听装）”。第三个坑是“日期格式混乱”。sell_records表的sell_date字段用DATETIME类型，但前端sell.php的日期控件输出的是YYYY-MM-DD字符串，直接拼SQL会出错。统一用date('Y-m-d H:i:s')生成完整时间戳，或在SQL中用STR_TO_DATE('2024-05-20', '%Y-%m-%d')转换。这些坑，都是我在帮第三家便利店上线时，连续三天蹲在收银台后，跟着店员一笔笔录单、一笔笔核对库存，才揪出来的。

4.3 安全加固建议：超越基础防护的实战经验

系统默认的安全措施（如SQL预处理、XSS过滤）已覆盖95%风险，但针对校园环境，我额外增加了三项加固：一是登录失败锁定，修改login.php，每次失败在数据库users表中记录login_fail_count和last_fail_time，连续5次失败后锁定30分钟；二是敏感操作二次确认，在delete_product.php删除商品前，弹出if(confirm('确定删除商品【'+name+'】？此操作不可恢复！')){...}；三是数据库备份自动化，编写backup_db.sh脚本，每天凌晨2点执行mysqldump -u root -p'password' inventory_system > /backup/inventory_$(date +\%Y\%m\%d).sql，并通过crontab -e添加定时任务。这些不是教科书上的标准答案，而是我在真实环境中，看着店主因为误删商品而急得满头大汗后，连夜补上的“后悔药”。安全不是一劳永逸的配置，而是对每一个可能出错环节的敬畏。

5. 扩展性思考与个性化改造路径

这套系统留出了清晰的扩展接口。比如想增加“会员管理”，只需新增members表（字段：id、name、phone、balance、create_time），在sell.php的销售表单里加一个“会员卡号”输入框，销售成功后执行UPDATE members SET balance = balance - $total_money WHERE phone = $card_no。想接入微信支付？在sell.php底部加一个“微信收款码”按钮，点击后调起微信JS-SDK，支付成功回调pay_success.php，该页面更新sell_records表的pay_status字段为1，并触发库存扣减。最实用的改造是“手机扫码入库”，利用手机浏览器的<input type="file" accept="image/*" capture="environment">调用摄像头，用QR Code JS库解析二维码（如qrcode.min.js），将扫描到的商品ID自动填入jinhuo.php的对应输入框，省去手动输入。这些扩展都不需要重构核心架构，而是像搭积木一样，在现有模块上叠加新功能。我自己就帮一家便利店加了“临期商品预警”，在search_stock.php里增加一列“保质期剩余天数”，通过DATEDIFF(expire_date, CURDATE())计算，当小于7天时高亮显示，提醒老板优先销售。这种改造，代码不超过50行，却实实在在解决了他们的经营痛点。

我个人在实际部署中发现，系统最大的价值不是功能多强大，而是它让店主第一次意识到“数据可以被信任”。当月底盘库时，系统显示“卫龙辣条库存12包”，而货架上清点确实是12包，那一刻老板拍着桌子说：“这玩意儿，比我脑子还准！”——这大概就是技术回归本质的样子：不炫技，只解决问题。

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

简介：专为校园小超市设计的轻量级进销存管理系统，用PHP+MySQL开发，支持Windows和Linux环境部署。系统自带用户注册登录、密码修改、个人信息维护功能，覆盖商品全生命周期管理——包括商品信息增删改查、供应商档案维护、进货单登记与历史查询、销售出库记录与汇总统计、实时库存余量查看。所有业务单据（进货单、销售单）支持按商品名称、供应商、日期范围、单据编号等多条件组合检索，库存数据动态更新并可导出查看。前端基于HTML/CSS/JS+jQuery构建响应式界面，适配电脑和部分平板设备；后端逻辑清晰分层，关键文件如login.php、jinhuo.php、sell.php、search_stock.php、mod_product.php等命名直观、职责明确。配套数据库脚本inventory.sql可一键导入，支持phpStudy、XAMPP本地调试，也兼容Nginx/Apache生产环境。包含完整权限校验（checklog.php）、操作反馈页（regok.php、error_login.php）、数据提交接口（addProject.php、saveProject.php）及样式资源（css/、js/目录），结构规范，注释充分，适合教学实践、课程设计、毕业设计参考或小型实体门店快速上线。

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