企业官网建设流程全解析

简介：一套基于PHP构建的学生管理系统Web网站源码，面向教育机构、教师以及初中级PHP开发者，主要解决学生档案、课程、专业和管理员信息的高效维护问题。系统采用PHP+MySQL实现数据存取，前端由HTML、CSS、JavaScript构成，功能涵盖学生信息增删改查、课程管理、专业管理、管理员管理，并具备专业人数统计分析能力。压缩包共47个文件，以33个PHP页面/脚本为主，搭配jQuery、ECharts等JS组件，以及CSS样式、SQL数据库脚本、htaccess环境配置、说明文档等，构成了完整的项目目录。文件结构清晰，包体仅1.66MB，部署轻量，适合配合phpstudy等本地环境快速运行。目前已有156人学习下载。项目除常规增删改查外，还包含登录检查、密码修改、忘记密码、日志写入等细节模块，可供初学者参考实际业务中如何组织PHP文件、设计数据库表，也能为学校或教师提供一套可直接改造的轻量级管理工具。

1. 基于 PHP 开发的学生管理系统 Web 网站：先把需求看穿再动手

开学第一周，教务办公室最常见的场景是这样的：几台电脑上各存一份 Excel，班主任交上来的合班表格式五花八门，学号有文本有数字，身份证号被自动截断，等要把成绩按班级汇总时，只能靠人工肉眼比对。基于 PHP 开发的学生管理系统 Web 网站，就是把这件事从「人肉维护 Excel」变成「浏览器里统一录入、统一查询、统一管理」的一套轻量方案。本文不讨论高深架构，只讲一个能真正跑起来的学生管理系统长什么样：技术选型、数据库设计、增删改查、登录权限、上线部署。适合三类人：练手课设的在校生、第一次独立做完整 Web 项目的初级开发者、以及想给办公室搭一个内部小系统的老师或行政人员。

这类系统的价值不在于用了多新的技术，而在于「够用、能改、不贵」。PHP 恰好站在这个位置上：请求来、查库、渲染页面，三步走完一次完整业务，没有框架强迫你遵守一堆约定。下面这套方案按原生 PHP + PDO + MySQL 的路径来拆，整条链路你自己能掌控每一行代码，出了问题也找得到根因。文章会覆盖环境怎么搭、表怎么建、学生增删改查怎么写、登录权限怎么控，以及上线后最容易翻车的那几个细节。先把这个系统拆清楚，再决定你是要照做、改造还是在此基础上加功能。

2. 环境搭建与技术选型：PHP 为什么还是这类管理系统的最优选

2.1 为什么还选 PHP：一张表看清适用边界

很多人一听「学生管理系统还用 PHP 写」，第一反应是「这技术是不是太老了」。这个判断要分开看：PHP 确实不是新潮技术，但学生管理系统这类业务——表单提交、数据存储、列表展示、权限控制——本质上就是 PHP 最擅长的请求-响应模型。你不需要 WebSocket 实时推送，不需要高并发队列，不需要复杂的微服务拆分。这类系统的瓶颈永远在「教务老师用得顺不顺手」和「改需求时改得快不快」，而不是并发天花板。

我一般会给选型列这样一张对比表，帮助新手做决定：

这套对比的结论很直接：如果你做的就是一个「学校内部用」或「课设展示」的学生管理系统，原生 PHP 是成本最低、最可控的路径。它不需要编译步骤、没有容器依赖、改一个文件刷新浏览器就能看到效果。框架当然可以引入，但原生写一遍，你才能理解框架帮你省掉的到底是什么；直接套框架而不知道底层逻辑，遇到问题就会变成「黑匣子式调试」。这篇按原生 PHP + PDO 讲，等你能独立跑通后再决定要不要换成框架。

2.2 本地环境准备：从零装出一个能跑 PHP 的最小环境

常见做法是装一个集成环境，把 Apache、PHP、MySQL 一次配好，比如 XAMPP 或 phpStudy 这类工具，装完启动两个服务就能开始写代码。第一步先确认 PHP 版本，版本决定了你后续能不能用现代的写法：

# 终端执行，确认 PHP 版本 php -v

如果输出的是 PHP 7.4 及以上，可以直接往下走；如果是 5.x，后面多数代码会跑不起来，因为 PHP 7 已经彻底移除了mysql_*系列函数。建议换一个集成环境自带的 PHP 8 版本，免得在环境上耗时间。启动 Apache 和 MySQL 后，在项目目录放一个探针脚本，确认 PHP 与数据库驱动是否就绪：

<?php // probe.php：确认 PHP 版本、PDO 扩展和 MySQL 驱动是否就绪 $checks = [ 'php_version' => PHP_VERSION, 'pdo_mysql' => extension_loaded('pdo_mysql') ? 'OK' : 'MISSING', 'file_uploads'=> ini_get('file_uploads') ? 'ON' : 'OFF', ]; foreach ($checks as $key => $value) { echo $key . ': ' . $value . PHP_EOL; }

把probe.php放到 Web 根目录下的项目目录里，浏览器访问http://localhost/项目目录/probe.php。重点看两个输出：php_version是否大于等于 7.4，pdo_mysql是否为 OK。如果pdo_mysql显示 MISSING，就去集成环境的扩展管理里开启这个扩展，然后重启 Apache。这一步就是后续所有代码能跑通的地基，别跳过。

2.3 项目骨架与统一配置：三个文件撑起一个可维护的项目

环境就绪后，先把项目目录结构定下来。我不建议新手一开始就套 MVC 三层，那会让「文件该放哪」变成比「业务怎么写」还难的问题。按下面这个扁平结构就够用，等文件超过二十个再考虑按模块拆目录：

student-system/ ├── index.php # 入口，登录后跳转到列表页 ├── login.php # 登录表单页 ├── logout.php # 退出登录 ├── config.php # 数据库连接参数 ├── db.php # PDO 连接封装 ├── auth.php # 登录与角色权限检查 ├── student_list.php # 学生列表（分页） ├── student_form.php # 新增/编辑学生表单 ├── action_student_save.php # 保存学生数据 ├── action_student_batch_delete.php # 批量删除学生 ├── views/ # 拆出来的 HTML 模板 └── assets/ ├── style.css └── app.js

配置文件和连接封装是骨架里最不能省的两个文件。把数据库参数集中放在config.php，比在每个脚本里各写一份连接串更安全、更好维护：

<?php // config.php —— 所有环境相关的配置集中在这里 return [ 'db' => [ 'host' => '127.0.0.1', 'port' => 3306, 'dbname' => 'student_system', 'username' => 'root', 'password' => 'local_dev_password', 'charset' => 'utf8mb4', ], 'app' => [ 'debug' => true, // 开发期 true，上线必须改成 false 'timezone' => 'Asia/Shanghai', ], ];

config.php里我只强调一个习惯：开发环境可以用 root 空密码图省事，但代码里不要写死密码字符串，更不要每次在多个文件里复制粘贴。把debug开关留在这里，等上线时全局改一处即可。下一步db.php连接封装，所有脚本统一require db.php，数据库就只连着这一份，出了问题排查链路会短很多。

3. 数据库建模：四张表撑起整个学生管理系统

3.1 从 Excel 思维到关系模型：学生、班级、成绩、管理员

很多人建表的第一反应是把 Excel 的列直接翻译成字段，于是「班级」成了学生表里的一个文本字段，每个学生后面跟着一串「2024级计算机1班」。这样做短时间没问题，但等你要按年级统计、按专业筛选，或修改一个班级的名称时，就会发现所有学生行都得跟着更新。正确做法是拆分实体：班级信息单独一张表，学生表只存class_id外键。

学生管理系统最少需要四张表：班级表class、学生表student、成绩表score、管理员账号表admin_user。建表顺序有讲究，先建被引用的表，再建引用别人外键的表：

CREATE DATABASE student_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE student_system; -- 班级表 CREATE TABLE class ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, class_name VARCHAR(50) NOT NULL COMMENT '班级名称，如 2024级计算机1班', grade VARCHAR(10) NOT NULL COMMENT '年级，如 2024', major VARCHAR(50) DEFAULT '' COMMENT '专业', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='班级表'; -- 学生表 CREATE TABLE student ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, student_no CHAR(10) NOT NULL COMMENT '学号', name VARCHAR(30) NOT NULL COMMENT '姓名', gender ENUM('男','女') NOT NULL COMMENT '性别', birth_date DATE DEFAULT NULL COMMENT '出生日期', class_id INT UNSIGNED NOT NULL COMMENT '所属班级', phone VARCHAR(20) DEFAULT '' COMMENT '联系电话', status TINYINT NOT NULL DEFAULT 1 COMMENT '1在籍 0离校', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_student_no (student_no), KEY idx_class_id (class_id), CONSTRAINT fk_student_class FOREIGN KEY (class_id) REFERENCES class(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生表'; -- 成绩表 CREATE TABLE score ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, student_id INT UNSIGNED NOT NULL COMMENT '学生ID', course_name VARCHAR(50) NOT NULL COMMENT '课程名称', score DECIMAL(5,1) NOT NULL COMMENT '成绩', exam_date DATE DEFAULT NULL COMMENT '考试日期', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, KEY idx_student (student_id), CONSTRAINT fk_score_student FOREIGN KEY (student_id) REFERENCES student(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='成绩表'; -- 管理员账号表 CREATE TABLE admin_user ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, username VARCHAR(30) NOT NULL COMMENT '登录名', password_hash VARCHAR(255) NOT NULL COMMENT '密码哈希', role ENUM('admin','teacher','student') NOT NULL DEFAULT 'student' COMMENT '角色', status TINYINT NOT NULL DEFAULT 1 COMMENT '1启用 0禁用', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_username (username) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='管理员账号表';

这里有几个刻意为之的设计点。数据库默认字符集用utf8mb4，不是为了花哨，而是它能完整支持中文和 emoji，MySQL 老版本的utf8字符集在存生僻字时容易报错，这是很多中文系统乱码的隐藏源头。表引擎统一用 InnoDB，因为你要用外键和事务，MyISAM 虽然读起来快一点，但不支持外键约束，删除学生的顺序一旦错乱，数据完整性就崩了。学号加UNIQUE唯一索引，这是业务规则「一个学号只对应一个人」在数据库层面的硬约束，不能只靠代码里 if 判断，因为并发请求可能同时绕过。

3.2 索引设计：先想清楚怎么查再谈优化

学生管理系统最常用的查询有三个：按学号精确查一个学生、按班级筛选列表、按姓名模糊搜索。索引设计围绕这三个场景走就够了，不要贪多：

-- 学号唯一索引在建表时已加，无需重复 ALTER TABLE student ADD KEY idx_name (name);

为什么不给gender加索引？因为它只有「男」「女」两个取值，区分度太低，索引扫描反而可能比全表扫还慢。这是新手最容易踩的坑：看到查询里有用到哪个字段就给哪个字段加索引，结果索引建了一堆，写入速度下降，查询也没变快。学生表数据量在几万行以内时，主键和学号索引已经覆盖主要场景；等数据量上来，再考虑组合索引，比如(class_id, status)用于按班级和状态联合筛选。索引是数据库性能的杠杆，但不是在每根柱子上都放一个支点。

3.3 PDO 连接封装与初始化数据：从第一行代码就防 SQL 注入

连接封装是整套代码安全性的地基。用 PDO 的预处理机制，而不是直接拼接 SQL 字符串，这是底线。db.php的写法如下：

<?php // db.php —— 全局唯一的数据库连接入口 $config = require 'config.php'; $dbConfig = $config['db']; $dsn = sprintf( 'mysql:host=%s;port=%d;dbname=%s;charset=%s', $dbConfig['host'], $dbConfig['port'], $dbConfig['dbname'], $dbConfig['charset'] ); try { $pdo = new PDO($dsn, $dbConfig['username'], $dbConfig['password'], [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, PDO::ATTR_EMULATE_PREPARES => false, ]); } catch (PDOException $e) { // 不要在生产环境输出真实异常信息 $logDir = __DIR__ . '/logs'; if (!is_dir($logDir)) { mkdir($logDir, 0755, true); } error_log('[' . date('Y-m-d H:i:s') . '] ' . $e->getMessage() . PHP_EOL, 3, $logDir . '/db_error.log'); exit('数据库连接失败，请稍后重试'); }

三个 PDO 属性各有意义。ERRMODE_EXCEPTION让 SQL 出错时抛异常而不是返回 false，配合外层 try/catch，错误能统一落到日志文件，而不是半截 HTML 页面里打印出来。FETCH_ASSOC让查询结果直接返回「字段名 => 值」的关联数组，比FETCH_NUM的数字下标好读得多。EMULATE_PREPARES => false是让 MySQL 真正走服务端预处理，避免某些边界场景下 PDO 把预处理「模拟」成字符串拼接，这是防注入的关键一档。

接着初始化一条管理员账号。密码必须用password_hash()生成哈希而不是存明文：

<?php // create_admin_password.php —— 生成初始密码哈希，执行一次后删除 echo password_hash('admin123', PASSWORD_DEFAULT), PHP_EOL;

把输出的长字符串填到下面的 SQL 里执行：

INSERT INTO admin_user (username, password_hash, role) VALUES ('admin', '$2y$10$...这里填生成的哈希...', 'admin');

这里解释一下为什么不能省事存 md5：md5('admin123')是固定值，所有用同一密码的账号哈希都相同，一旦数据库泄露，攻击者可以用彩虹表直接反查出明文密码。password_hash每次生成的哈希都不同且自带盐，password_verify可以无损验证。后面登录那章会用到配套函数，现在先把账号建好。

4. 学生信息管理的增删改查：分页、表单与删除的完整代码链路

4.1 列表与分页：第一步避开 LIMIT 参数化这个隐藏坑

学生列表页是所有操作的入口，核心是「条件筛选 + 分页 + 联查班级名」。这里最容易踩的坑不是 SQL 写错，而是 LIMIT 在 PDO 里不能作为预处理参数绑定——MySQL 的预处理协议不允许把 LIMIT 后面的数字用占位符替代，老版本 PDO 甚至也不支持。所以分页变量必须经过intval强转后直接拼接，这是少数「必须拼接但不会注入」的合法场景：

<?php // student_list.php —— 学生列表 require 'db.php'; $page = max(1, (int)($_GET['page'] ?? 1)); $pageSize = 10; $offset = ($page - 1) * $pageSize; // 筛选条件：按班级筛选 $where = ''; $params = []; if (!empty($_GET['class_id'])) { $where = 'WHERE s.class_id = :class_id'; $params['class_id'] = (int)$_GET['class_id']; } // 查询总数用于计算总页数 $countSql = "SELECT COUNT(*) FROM student s $where"; $stmt = $pdo->prepare($countSql); $stmt->execute($params); $total = (int)$stmt->fetchColumn(); $totalPages = max(1, ceil($total / $pageSize)); // 查询当前页数据，关联班级名 $listSql = "SELECT s.id, s.student_no, s.name, s.gender, s.phone, c.class_name FROM student s LEFT JOIN class c ON s.class_id = c.id $where ORDER BY s.id DESC LIMIT $pageSize OFFSET $offset"; $stmt = $pdo->prepare($listSql); $stmt->execute($params); $list = $stmt->fetchAll();

两个地方要解释清楚。第一，WHERE子句里的:class_id用预处理参数绑定，而LIMIT和OFFSET用的是变量拼接，因为这种情况下的变量已经过max(1, ...)和括号里的(int)强转，只剩数字，没有注入通道。第二，LEFT JOIN而不是INNER JOIN的原因是：当某条学生记录的class_id因为异常而指向一个不存在的班级时，LEFT JOIN查出来后班级名是 null，但学生还在列表里，方便你发现问题，而不是静默少一行数据。分页链接渲染时，page用max(1, ...)兜底，避免手动在 URL 里输入负数页码或非数字参数时 SQL 报错。

4.2 新增与编辑：学号查重为什么必须落在数据库层

新增和编辑可以共用一个表单页、共用一个保存脚本。这里最容易出问题的是学号唯一性校验——只在前端用 JavaScript 查一次没用，用户绕过页面直接提交请求时，数据库才是最后防线。保存脚本的完整逻辑如下：

<?php // action_student_save.php —— 新增/编辑学生 require 'db.php'; session_start(); // 假设已经通过登录检查，下面第5章会讲 auth.php $id = (int)($_POST['id'] ?? 0); $studentNo = trim($_POST['student_no'] ?? ''); $name = trim($_POST['name'] ?? ''); $gender = $_POST['gender'] ?? ''; $classId = (int)($_POST['class_id'] ?? 0); if ($studentNo === '' || $name === '' || !in_array($gender, ['男', '女'], true)) { exit('学号、姓名、性别不能为空，请检查后重试'); } // 学号查重：排除当前记录本身 $checkSql = 'SELECT id FROM student WHERE student_no = :no AND id != :id'; $stmt = $pdo->prepare($checkSql); $stmt->execute([':no' => $studentNo, ':id' => $id]); if ($stmt->fetch()) { exit('该学号已经存在，请检查输入'); } if ($id > 0) { // 编辑 $sql = 'UPDATE student SET student_no=:no, name=:name, gender=:gender, class_id=:class_id WHERE id=:id'; $stmt = $pdo->prepare($sql); $stmt->execute([ ':no' => $studentNo, ':name' => $name, ':gender' => $gender, ':class_id' => $classId, ':id' => $id, ]); } else { // 新增 $sql = 'INSERT INTO student (student_no, name, gender, class_id) VALUES (:no, :name, :gender, :class_id)'; $stmt = $pdo->prepare($sql); $stmt->execute([ ':no' => $studentNo, ':name' => $name, ':gender' => $gender, ':class_id' => $classId, ]); } header('Location: student_list.php'); exit;

查重 SQL 里的id != :id是编辑场景的精髓：新增时id为 0，不影响查重；编辑时排除自己这条记录，否则改学号时永远提示「已经存在」。性别字段用in_array白名单校验，而不是preg_match去猜输入合法值——白名单的意思是「只有我明确允许的值才通过」，比黑名单过滤安全得多。另外注意所有字段都经过trim去掉首尾空格，否则用户误输入「 张三」会真实地存进数据库，之后查「张三」找不到，这就是典型的脏数据来源。

4.3 删除与批量操作：逻辑删除和物理删除怎么选

删学生这件事在管理系统里比想象中敏感：学生删掉后，关联的成绩表怎么办？如果score表有外键指向student(id)，直接 DELETE 会报外键约束错误，而且历史成绩被物理删除意味着数据彻底消失。我的建议是，除非课设明确要求物理删除，否则一律用「逻辑删除」——给student表的status字段置 0，列表查询默认只看status = 1：

<?php // action_student_batch_delete.php —— 批量逻辑删除 require 'db.php'; session_start(); $ids = isset($_POST['ids']) ? array_map('intval', (array)$_POST['ids']) : []; if (empty($ids)) { exit('未选择任何学生'); } $marks = implode(',', array_fill(0, count($ids), '?')); $sql = "UPDATE student SET status = 0 WHERE id IN ($marks)"; $stmt = $pdo->prepare($sql); $stmt->execute($ids); header('Location: student_list.php'); exit;

这里的核心在$marks这一句：有多少个 ID，就生成多少个?，然后execute($ids)把整型数组按顺序绑定进去。为什么不能直接把$_POST['ids']拼进 SQL？因为那是把用户输入当代码执行，是最典型的注入点。array_map('intval', ...)先强转一遍再拼占位符，双保险；这里即使不用预处理也不会有注入风险，但统一走预处理，代码风格一致，后续加别的条件不容易漏。

逻辑删除带来的额外好处是「后悔药」：删错了只要UPDATE student SET status = 1 WHERE id = ...就能无损恢复。物理删除则是数据库层面把整行抹掉，连恢复的余地都没有。界面上「删除」按钮加一层confirm('确认删除？')的二次确认，这是交互习惯，不是安全机制——真正保护数据的是刚才的status设计。列表查询里加WHERE s.status = 1，这就是第 3 章说要建(class_id, status)组合索引的原因。

5. 登录、权限与高频报错排查：把入口和边界管住

5.1 Session 登录态与密码哈希：不用 md5 是实现底线

管理系统不能裸奔，第一个要做的防护就是登录。登录的核心不是「有密码就能进」，而是「登录后服务端能可靠地记住你是谁」。这里用 Session 而不是把用户 ID 塞进 Cookie——Cookie 存在用户浏览器里，可以被篡改；Session ID 存在 Cookie 里，但用户数据存在服务器上。登录处理脚本：

<?php // action_login.php —— 登录处理 require 'db.php'; session_start(); $username = trim($_POST['username'] ?? ''); $password = $_POST['password'] ?? ''; $stmt = $pdo->prepare('SELECT id, username, password_hash, role FROM admin_user WHERE username = :u AND status = 1'); $stmt->execute([':u' => $username]); $user = $stmt->fetch(); if ($user && password_verify($password, $user['password_hash'])) { // 重新生成会话ID，防止会话固定攻击 session_regenerate_id(true); $_SESSION['user_id'] = $user['id']; $_SESSION['role'] = $user['role']; header('Location: student_list.php'); exit; } exit('用户名或密码错误');

session_regenerate_id(true)是很多教程会漏掉的安全细节：登录成功后，旧的会话 ID 可能已经被攻击者提前知道，重新生成新 ID 会让旧 ID 失效，这是防「会话固定攻击」的标准动作。密码验证用password_verify($password, $user['password_hash'])，它和注册时的password_hash()是一对，不要自己写什么 md5 双重加密，PHP 官方这套已经是最成熟的方案。还有一点：登录失败时只输出统一的「用户名或密码错误」，不要告诉用户「用户名不存在」——那等于给攻击者做用户名枚举，是信息泄露。

5.2 角色权限隔离：一个 auth.php 拦截所有后台页面

学生系统通常有三种角色：管理员能管所有数据、老师能看能录成绩但不能删学生、学生只能看自己的信息。这个需求用统一的权限拦截文件最省事：

<?php // auth.php —— 登录检查与角色权限判断 function requireLogin(): void { if (empty($_SESSION['user_id'])) { header('Location: login.php'); exit; } } function requireRole(string ...$roles): void { requireLogin(); if (!in_array($_SESSION['role'], $roles, true)) { exit('权限不足，该操作被拒绝'); } }

用法是在每个入口脚本的最顶部加一行：

<?php // student_form.php 顶部 require 'auth.php'; requireRole('admin', 'teacher');

「权限不足」的输出不用做得太花哨，关键是拦截动作要发生在业务逻辑之前。很多课设翻车的场景是：登录页做了，但student_delete.php忘了检查 Session，结果没登录的人直接在浏览器地址栏输入文件名也能删数据。权限判断必须集中在auth.php，每个文件头部require一次，而不是在某个公共文件里「顺便检查」——你无法保证所有入口都记得引那个公共文件，但require 'auth.php'写在每个入口的第一行，这份责任就跟代码可见地绑在一起了。

5.3 五个高频坑：现象、原因、解决

做学生管理系统时被问得最多的，集中在这五类问题上，每一条都是能让人卡一个小时以上的「玄学」现象：

第一类：页面所有中文变成「??」或「éľ」乱码。现象是浏览器显示的内容完全不可读。原因是字符集在四个环节里至少有一个不一致：数据库表字符集、连接字符集、PHP 文件保存编码、HTML 页面声明。解决方法是统一四件套：建库时用utf8mb4（第 3 章已写）、db.php的 DSN 里带charset=utf8mb4、PHP 文件用 UTF-8 无 BOM 编码保存、页面头部输出<meta charset="utf-8">。缺一个，乱码就可能以各种姿势出现。

第二类：表单提交后$_POST里是空的。现象是打印$_POST输出array(0)。原因通常是<form>标签忘了写method="post"，或者表单里的输入框没有name属性——PHP 只认name不认id。解决方法是检查表单开标签和每个input的name。还有一个隐蔽原因：表单里有disabled的字段，它不会被提交，这不是错误，是规则。

第三类：页面报错「Call to undefined function mysql_query」。现象是一段老代码直接抛致命错误。原因是 PHP 7 移除mysql_*系列函数，而你还在用十年前的书上的写法。解决方法是把mysql_connect、mysql_query、mysql_fetch_array全部改成第 4 章的 PDO 写法。没有任何兼容层能让这些老函数复活，也不必复活。

第四类：登录成功后刷新页面就掉线。现象是登录完跳到列表页，一刷新又回到登录页。原因通常是你在localhost和127.0.0.1之间来回切换访问——Session 的 Cookie 是按域名绑定的，这两个地址在浏览器看来是不同站点，Session ID 对不上。解决方法是统一用一个地址访问，或者检查php.ini里session.save_path指向的目录是否可写；如果 Session 文件写不进去，登录成功后新开页面还是会当你不存在。

第五类：分页点第 2 页，显示的还是第 1 页内容。现象是 URL 上page=2，但数据和第一页相同。原因是 SQL 里用了LIMIT 10而忘了OFFSET，或者$offset计算错误。解决方法是确认分页计算是$offset = ($page - 1) * $pageSize，并把page参数强转成int，第 4.1 节已经给出了完整写法。这类问题单看代码很难发现，我会在 SQL 里顺手加一行注释标注当前页和偏移量，调试时直接输出来对比。

6. 从本地到公网：部署清单、数据备份与两个性能习惯

本地跑通只是第一步，真正让别人能访问，需要把项目搬到一台公网服务器上。部署过程不复杂，但顺序错一步就可能浪费半天。下面这张清单是我每次部署这类系统都会逐项打勾的：

部署时最容易被忽略的是debug开关。本地开发时开着方便看报错，上了生产环境还开着等于把服务器目录结构、数据库连接信息直接暴露给访问者，这是很多内网系统被黑的起点。正确做法是保持debug=false，所有错误通过error_log写到日志文件，前端用户看到的是统一的「页面开了小差」提示，而不是一屏红色堆栈。

两个性能习惯值得现在就养成。第一，列表页不要写SELECT *，第 4 章写的是SELECT s.id, s.student_no, s.name, ...，只查要展示的字段。SELECT *会把birth_date、created_at这些不展示的字段全捞出来，浪费内存和带宽。第二，当学生数据量超过几万行时，LIMIT/OFFSET分页的OFFSET越深越慢，因为 MySQL 要跳过前面所有行。替代方案是游标分页：记住上一页最后一条的 ID，下一页用WHERE id < :last_id ORDER BY id DESC LIMIT 20来查，虽然页码跳转会麻烦一点，但性能稳定，不会随着翻页变慢。

这类系统上线后最容易栽的跟头，是数据库账号还用着root和空密码。到现在我都保留一个习惯：任何项目部署前，在数据库里新建一个专用账号，只授予当前库的增删改查权限，然后在config.php里存那个账号而不是 root。这个习惯帮我在好几个项目里避免了数据裸奔——代码泄露不代表数据权限泄露，最小权限是一道虽然简单但一直有效的边界墙。这套从环境、建库、增删改查到部署的路径，你可以直接照着走一遍，也可以在此基础上加成绩管理、课表、公告这些模块，骨架已经完全够用。希望帮到你。

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