简介：学生报名系统源码 v2012 是一套面向学校、培训机构及招生单位的 PHP 报名管理程序，功能覆盖报名登记、考场分配与准考证打印等环节，适合需要快速搭建报名流程的中小型机构使用。压缩包为 zip 格式，大小约 2.37MB，包内以 PHP 程序代码与 MySQL 数据库文件为主，www 目录存放程序主体，database 目录提供可导入的数据库脚本，部署时只需修改 config 下的数据库连接配置即可运行。系统支持分区管理，可登记报名号、姓名、性别、出生年月、毕业学校、身份证号、家庭住址、父母姓名、联系电话等信息，并集成摄像头拍照功能；工作人员可手动分配考场座位号，随后打印准考证，还能汇总数据并导出为 Excel 表格，便于后续统计与归档。目前已有 523 人学习关注，适合希望低成本实现报名信息采集与考务管理的读者参考使用。
1. 学生报名系统源码 v2012：一份 PHP 老项目的落地拆解
上周有个做教务外包的朋友甩给我一个压缩包，说客户要一套「能跑起来的学生报名系统」，预算不高、时间更紧，问我这套标着 v2012 的 PHP 源码能不能直接用。我解压看了一眼目录结构，心里大概有数了：典型的 LAMP 时代产物，index.php入口、config.php放数据库连接、admin/和user/两套界面、include/里塞着公共函数，没有 Composer、没有框架、没有模板引擎，纯原生 PHP 拼 HTML。这类 PHP 源码在报名、登记、信息采集场景里其实很常见，逻辑直白、改起来门槛低，适合预算有限又要快速交付的小型项目。但它能不能用，取决于你会不会先把它当黑匣子拆一遍——数据库怎么建、入口怎么走、权限怎么卡、老语法在新 PHP 上会不会翻车。这篇就按我实际拆包的顺序，把这份源码从结构到跑通、再到踩坑，完整过一遍。
2. 拆包先看骨架：目录结构与数据库入口
拿到一份原生 PHP 源码，我一般不会急着往服务器上扔，先在本地把目录树和关键文件过一遍。这一步决定了后面部署时你会不会在「为什么首页白屏」上耗掉半天。学生报名系统这类项目，核心就三件事：数据存哪、页面怎么渲染、表单提交后落到哪张表。把这三条线摸清，剩下的都是体力活。
2.1 目录树里哪些文件是真正要动的
解压后典型的结构大致是这样（不同打包版本文件名可能略有出入，以你手上实际为准）：
student_signup_v2012/ ├── index.php # 前台首页 / 报名入口 ├── config.php # 数据库连接与全局常量 ├── signup.php # 报名表单提交处理 ├── list.php # 报名名单展示 ├── admin/ │ ├── login.php # 后台登录 │ ├── index.php # 后台首页 │ ├── manage.php # 报名记录管理 │ └── export.php # 导出（部分版本有） ├── include/ │ ├── db.php # 数据库操作封装 │ ├── func.php # 公共函数 │ └── check.php # 登录态校验 ├── css/ js/ images/ # 静态资源 └── install/ # 安装向导（部分版本带）真正需要你动手改的其实就四个：config.php（连库参数）、include/db.php（看它用什么方式连库）、signup.php（表单字段和入库逻辑）、admin/login.php（后台账号从哪来）。其余文件基本是展示层，改改文案和样式就行。我习惯先把config.php打开，因为整个系统的「血条」都在这。
2.2 config.php 与数据库连接：先看清它怎么连
原生 PHP 项目连库无非两种：mysql_*老函数，或者mysqli/PDO。v2012 这个年代的包，大概率是mysql_*或者早期mysqli。打开config.php你会看到类似这样的东西：
<?php // config.php 典型内容（字段名以实际为准） $db_host = 'localhost'; $db_user = 'root'; $db_pass = '123456'; $db_name = 'student_signup'; $db_charset = 'utf8'; // 部分版本在这里直接建立连接 $conn = mysql_connect($db_host, $db_user, $db_pass); mysql_select_db($db_name, $conn); mysql_query("SET NAMES 'utf8'"); ?>这段代码的含义很直白：主机、账号、密码、库名四个参数，加上字符集设置。你要改的就是前四个，指向你自己的数据库。这里有个关键判断——如果它用的是mysql_connect这一族函数，那在 PHP 7.0 以后是直接报错的，因为整个mysql_*扩展在 PHP 7 被移除。这不是配置问题，是语法层面的不兼容，后面避坑章节会专门讲怎么处理。
参数说明上，$db_charset建议统一设成utf8mb4，别用utf8。报名系统里学生姓名、备注、地址这些字段，遇到生僻字或者带 emoji 的输入，utf8三字节存不下会截断甚至乱码，utf8mb4才是完整的四字节 UTF-8。建库时也要对应：
CREATE DATABASE student_signup DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;建库语句里utf8mb4_general_ci是排序规则，ci表示大小写不敏感，对报名这种场景够用。如果你后面要做姓名拼音排序之类的，可以换utf8mb4_unicode_ci，差别在排序精度，一般项目感知不到。
2.3 建表：从 signup.php 反推字段
很多打包源码不带.sql文件，或者带了但字段和代码对不上。稳妥做法是打开signup.php，看它INSERT语句里到底写了哪些字段，再照着建表。典型报名表长这样：
CREATE TABLE `signup_record` ( `id` int(11) NOT NULL AUTO_INCREMENT, `stu_name` varchar(50) NOT NULL COMMENT '姓名', `stu_no` varchar(30) NOT NULL COMMENT '学号/证件号', `gender` tinyint(1) DEFAULT '0' COMMENT '性别 0未知 1男 2女', `phone` varchar(20) DEFAULT NULL COMMENT '联系电话', `major` varchar(100) DEFAULT NULL COMMENT '报考专业/方向', `remark` text COMMENT '备注', `create_time` int(11) DEFAULT NULL COMMENT '提交时间戳', PRIMARY KEY (`id`), UNIQUE KEY `uk_stu_no` (`stu_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里有两个设计点值得说。第一，stu_no加了唯一索引，防止同一个人重复报名，这是报名系统最基本的约束，很多老源码恰恰漏了，导致后台一堆重复记录。第二，create_time用int存时间戳而不是datetime，是老项目的常见习惯，好处是排序和计算方便，坏处是可读性差，导出时要自己转格式。你如果接手后要改，建议保留原字段类型别乱动，否则signup.php里的time()写入逻辑和后台的格式化函数都得跟着改，牵一发动全身。
建完表，把config.php的四个参数填对，浏览器访问index.php，能出页面、能提交一条测试数据、后台能看到，这条主链路就算通了。通不了的话，先看 PHP 错误日志，别靠猜——这是后面排查章节反复要用的习惯。
3. 跑通主链路：报名提交、后台登录与权限校验
骨架看清了，接下来是把「学生填表 → 数据入库 → 管理员查看」这条链路真正跑起来。这一步的难点不在写代码，而在老项目的登录态和权限校验往往写得很随意，你得先看懂它的「锁」是怎么上的，才知道哪里能改、哪里一改就崩。
3.1 signup.php 的提交处理：字段校验与入库
打开signup.php，结构通常是「判断是否 POST → 取$_POST字段 → 简单校验 → 拼 SQL 插入 → 跳转」。原生写法大概是这样：
<?php require_once 'config.php'; if ($_SERVER['REQUEST_METHOD'] === 'POST') { // 取参并做基础过滤 $name = trim($_POST['stu_name'] ?? ''); $no = trim($_POST['stu_no'] ?? ''); $phone = trim($_POST['phone'] ?? ''); $major = trim($_POST['major'] ?? ''); // 必填校验：姓名和学号不能空 if ($name === '' || $no === '') { die('姓名和学号不能为空'); } // 手机号简单格式校验（11 位数字） if ($phone !== '' && !preg_match('/^1\d{10}$/', $phone)) { die('手机号格式不正确'); } // 入库：注意这里用预处理，别直接拼字符串 $stmt = $conn->prepare( "INSERT INTO signup_record (stu_name, stu_no, phone, major, create_time) VALUES (?, ?, ?, ?, ?)" ); $ts = time(); $stmt->bind_param('ssssi', $name, $no, $phone, $major, $ts); $stmt->execute(); header('Location: list.php'); exit; } ?>逻辑说明：先trim去掉首尾空格，避免用户手滑多打空格导致「看起来一样其实不同」的重复记录；必填项和手机号做前置校验，把明显错误挡在入库前；入库用prepare+bind_param预处理，而不是把变量直接拼进 SQL 字符串。参数说明上，bind_param的第一个参数是类型串，s表示字符串、i表示整数，顺序必须和占位符一一对应，写错了不会报错但会存进错误的值，这是很隐蔽的坑。
提示：老源码里大量存在
"INSERT ... VALUES ('$name', '$no')"这种直接拼接，一旦用户输入带单引号就会 SQL 报错，严重的还能被注入。你接手后哪怕不改别的，入库这一处也建议换成预处理，成本很低。
3.2 后台登录与 check.php：登录态到底存在哪
后台入口在admin/login.php，登录成功后一般会$_SESSION['admin'] = ...或者写 cookie。校验逻辑集中在include/check.php，每个后台页面顶部require一下。典型写法：
<?php // include/check.php session_start(); if (empty($_SESSION['admin_id'])) { header('Location: login.php'); exit; } ?>这段很短，但决定了整个后台的安全边界。你要确认两件事：一是session_start()有没有在每个用到 session 的页面之前调用，漏了会导致登录态读不到、一直跳回登录页；二是登录成功时到底往 session 里写了什么键，check.php判断的键必须和写入的键完全一致，差一个字母就是「登录成功但进不去后台」的经典翻车。
后台账号通常存在admin表里，密码可能是明文也可能是md5。如果是明文，第一件事就是改成password_hash存储：
<?php // 登录校验时用 password_verify，替代 md5 比对 $row = $stmt->fetch_assoc(); if ($row && password_verify($input_pass, $row['password'])) { $_SESSION['admin_id'] = $row['id']; header('Location: index.php'); exit; } ?>password_hash生成的哈希带盐、算法可升级，比md5安全得多。迁移时把老账号的明文或 md5 密码重置一遍即可，报名系统后台账号数量很少，手工重置成本可以接受。
3.3 权限边界：前台和后台别共用一套校验
一个容易忽略的点：前台list.php展示报名名单，如果它没有做任何限制，等于把所有人的姓名、电话公开了。老源码里这种情况不少见，因为作者默认「名单就是给大家看的」。实际交付时你得判断业务需求——如果名单只给管理员看，list.php也要加登录校验；如果确实要公开展示，至少把手机号中间四位打码。
<?php // 手机号脱敏展示 function maskPhone($phone) { if (strlen($phone) !== 11) return $phone; return substr($phone, 0, 3) . '****' . substr($phone, 7); } ?>这个函数放在include/func.php里，展示时调用即可。参数上substr($phone, 0, 3)取前三位，substr($phone, 7)取后四位，中间替换成星号。别小看这一行，很多项目上线后被反馈「电话泄露」，回头补就是这么补的。
主链路跑通、权限边界理清，这套源码的「能用」部分就成立了。接下来是真正决定它能不能长期跑的环节——老语法在新环境下的兼容问题。
4. 老 PHP 源码的兼容改造：从 mysql_* 到 mysqli 的迁移
v2012 这个年份的 PHP 源码，最大的现实障碍不是功能，而是运行环境。现在随便一台服务器装的都是 PHP 7.x 或 8.x，而这份代码大概率是按 PHP 5.3/5.4 写的。直接扔上去，轻则一堆 Deprecated 警告，重则白屏。这一章讲怎么用最小改动把它拉起来，而不是重写。
4.1 先判断它到底卡在哪：错误日志是第一现场
部署后白屏，别急着改代码，先把错误显示打开。在入口文件顶部临时加：
<?php ini_set('display_errors', 1); ini_set('display_startup_errors', 1); error_reporting(E_ALL); ?>刷新页面，报错会直接打出来。常见的有三类：Call to undefined function mysql_connect()（扩展被移除）、Deprecated: mysql_* is deprecated（PHP 5.5+ 的警告）、Parse error（老语法如短标签<?在新配置下不认）。看清是哪一类，再对症下药。这个习惯我强调很多次——错误日志是黑匣子，猜是猜不出来的。
4.2 mysql_* 到 mysqli 的批量替换策略
如果确认是mysql_*被移除，有两条路：装回老扩展（不现实，PHP 7 起没有），或者改代码。改代码也分两种：全量换成mysqli，或者换成PDO。我一般选mysqli，因为函数名和参数顺序跟mysql_*最接近，改动量小。
对应关系大致是：
| 老函数 | 新写法（mysqli 面向过程） |
|---|---|
mysql_connect() | mysqli_connect() |
mysql_select_db() | mysqli_select_db() |
mysql_query() | mysqli_query() |
mysql_fetch_array() | mysqli_fetch_array() |
mysql_real_escape_string() | mysqli_real_escape_string() |
mysql_error() | mysqli_error() |
批量替换可以用编辑器的全局替换，但要注意顺序：先替换长函数名（mysql_real_escape_string），再替换短的（mysql_query），否则mysql_前缀会被误伤。替换完还要处理连接变量——mysqli_*系列函数第一个参数要传连接对象，而老代码很多是全局$conn，得确认每个调用点都能拿到。
<?php // 改造后的 db.php 片段 $conn = mysqli_connect($db_host, $db_user, $db_pass, $db_name); if (!$conn) { die('数据库连接失败: ' . mysqli_connect_error()); } mysqli_set_charset($conn, 'utf8mb4'); ?>mysqli_set_charset替代了老的SET NAMES查询，更规范。参数上第二个参数写utf8mb4，和建库时保持一致，否则中文还是可能乱。
4.3 短标签与已废弃语法的清理
老代码里常见<?短标签（不是<?php），在short_open_tag=Off的环境下会原样输出或报错。全局搜<?替换成<?php即可，注意别误伤<?=（这个是输出短标签，PHP 5.4+ 默认支持，可以保留）。另外ereg、split这类函数在 PHP 7 也被移除，对应换成preg_match、explode。
<?php // 老写法：ereg('^1[0-9]{10}$', $phone) // 新写法： if (!preg_match('/^1\d{10}$/', $phone)) { // 校验失败处理 } ?>ereg换preg_match时，正则要加上分隔符（这里是/.../），这是最容易漏的一步，漏了直接报「Unknown modifier」。改完这些，再跑一遍主链路，大部分白屏和警告就消了。
5. 避坑与排查：五条血泪记录
这套源码我在本地和测试机上反复折腾过几轮，下面五条是真实会卡住人的地方，按「现象 → 原因 → 解决」记下来，你照着对号入座能省不少时间。
5.1 首页白屏但日志没报错
现象：访问index.php一片空白，error_log里也没有新记录。原因多半是display_errors关了、error_reporting又没开全，错误被吞了；也可能是文件编码带 BOM，输出前有隐藏字符导致 header 跳转失败。解决：按 4.1 临时打开错误显示；用编辑器把文件转成「UTF-8 无 BOM」；确认index.php第一行不是空行或空格。
5.2 提交报名后中文变问号
现象：表单填中文，入库后查出来是???或乱码。原因通常是三处字符集不一致：数据库/表是utf8、连接没设utf8mb4、页面<meta charset>写错。解决：建库建表统一utf8mb4，连接用mysqli_set_charset($conn,'utf8mb4')，HTML 头写<meta charset="utf-8">，三处对齐基本就不会乱。
5.3 后台登录成功却一直跳回登录页
现象：账号密码对，点登录后页面闪一下又回登录页。原因一般是check.php判断的 session 键和登录时写入的键不一致，或者session_start()在某个页面被重复调用/漏调用。解决：全局搜$_SESSION[把所有键列出来对齐；确认每个后台页面顶部require 'check.php'且check.php里session_start()只调一次（用session_status()判断更稳）。
5.4 重复报名记录一堆
现象：同一个人提交两次，后台出现两条。原因：表上没加唯一索引，代码里也没做「先查后插」。解决：给stu_no加UNIQUE KEY，插入时用INSERT ... ON DUPLICATE KEY UPDATE或者先SELECT判断；同时前端提交按钮加防重复点击（提交后禁用）。
5.5 导出 Excel 打开是乱码
现象：后台导出名单，用 Excel 打开中文全是乱码。原因：导出的 CSV 没加 BOM，Excel 默认按本地编码解析。解决：输出前先echo "\xEF\xBB\xBF";写入 UTF-8 BOM，再输出 CSV 内容；或者直接导.xlsx（需要额外库，老项目一般不上）。
<?php // 导出 CSV 加 BOM，兼容 Excel header('Content-Type: text/csv; charset=utf-8'); header('Content-Disposition: attachment; filename="signup.csv"'); echo "\xEF\xBB\xBF"; // UTF-8 BOM // 后续 fputcsv 输出... ?>这五条覆盖了部署、编码、登录、数据、导出五个高频面，基本能挡住新手 80% 的翻车。
6. 交付前的加固与验证：一套可复用的自检清单
源码能跑不等于能交付。我每次把这类老项目交给客户前，都会走一遍固定自检，重点不在功能多全，而在「边界有没有守住」。下面这套清单你可以直接抄。
先做安全面：所有入库点是否都换成了预处理（搜mysql_query和字符串拼接的INSERT）；后台密码是否已从明文/md5 迁到password_hash；list.php这类展示页有没有做脱敏或登录限制；上传目录（如果有）是否禁止执行 PHP。再做数据面：stu_no唯一索引在不在；create_time时区对不对（date_default_timezone_set('Asia/Shanghai')别忘了）；导出字段和后台展示字段是否一致。
验证方法上，我习惯用三条测试数据走一遍：一条正常数据、一条带单引号的数据（O'Neil这种，测注入和转义）、一条超长中文（测字段长度和编码）。三条都能正确入库、正确展示、正确导出，主链路才算过关。
| 检查项 | 通过标准 | 常见失败表现 |
|---|---|---|
| 入库方式 | 全部预处理 | 带引号数据报错 |
| 密码存储 | password_hash | 数据库可见明文 |
| 名单展示 | 脱敏或鉴权 | 手机号全量暴露 |
| 字符集 | 三处 utf8mb4 一致 | 中文乱码 |
| 重复提交 | 唯一索引生效 | 同人多条记录 |
最后说个我自己的习惯。早年我图快，拿到源码改完配置就直接部署，结果有次客户现场演示，一条带单引号的姓名直接把页面打崩，当场尴尬。从那以后我每次交付前都强制走一遍上面这套清单，尤其是「带引号测试数据」这一条，雷打不动。这套 v2012 的 PHP 源码本身不复杂，值不值得用取决于你愿不愿意花半天做兼容和加固——愿意，它就是一套能快速落地的报名系统底子；不愿意，它就是个随时会翻车的黑匣子。希望帮到你。
本文还有配套的精品资源，点击获取
