企业官网建设流程全解析

简介：一套基于PHP开发的学生报名系统源码，面向学校、培训机构及需要处理批量报名场景的管理人员。系统按分区组织数据，支持报名号、姓名、性别、出生年月、毕业学校、身份证号、家庭住址、父母姓名、联系电话等信息登记，并可调用摄像头完成现场拍照，便于报名环节一体化采集。后台支持工作人员手动分配考场座位号、按需打印准考证，汇总数据可导出为Excel文件，覆盖从报名采集到考务安排的主要流程，适合中小规模机构快速部署使用。压缩包约2.37MB，内含PHP程序代码目录及MySQL数据库文件，数据库账号、地址、密码集中在manager/config/database.php中修改，导入数据库后即可在本地运行；管理员账号为admin，便于快速登录体验完整功能。目前已有519人浏览学习，对于需要搭建报名系统或学习PHP+MySQL基础开发流程的读者，是一份小巧、完整且可直接使用的参考源码。

1. 2012年的PHP学生报名系统：老代码凭什么还能被翻出来用

每年招生季，总有一些单位被报名信息的Excel来回传递逼疯：最终版名单永远不在手头，去重靠肉眼，统计靠Ctrl+F。这套v2012的学生报名系统正是针对这类场景写的，而且它本身就是一份完完整整的PHP源码——原生PHP加MySQL，前台一个报名表单，后台一个管理列表，带Excel导出和简单验证码，整套代码不依赖任何框架，解压到Apache目录就能跑。适合需要快速上线报名收集页的人，也适合接手维护老PHP项目的人：通过它能看清2012年前后一批PHP业务系统的共同套路。它不炫，但五脏俱全，很多新项目里反复出现的思路，都能在这套老代码里找到原型。

2. 模块与数据流：前台表单到后台导出的完整链路

拿到源码第一步不是急着改数据库，而是顺着请求把系统跑一遍，搞清楚数据从哪来、经过哪些文件、写到哪张表。下面按模块、数据表、请求处理三个层面拆。

2.1 三个端口：报名端、管理端、导出端的职责边界

整个系统的功能其实只有三条线。报名端入口是index.php，收集姓名、性别、报考专业、手机号、邮箱、毕业院校、备注；管理端是admin.php和admin_list.php，管理员登录后能看到报名记录并支持筛选和删除；导出端是admin_export.php，负责把查询结果生成Excel下载到本地。

主流程的数据流是这样的：报名者提交POST请求，index.php拿到$_POST数组扔给validate_student()做后端校验，通过后交给insert_student()写入student表，页面跳转到报名成功提示页。另一边管理员登录后台后，admin_list.php按查询条件从student表捞数据渲染成表格，admin_export.php再把相同数据按列写成Excel。

2012年的后台列表逻辑普遍是条件拼接加字符串SQL：专业下拉框对应major_id等于，时间筛选对应reg_time的between，姓名搜索对应like。老代码没有查询构造器，常见做法是把筛选参数先收集到数组，再用implode拼到WHERE后面，避免一堆if嵌套。这套系统也是同样的路子。

2.2 数据库表设计：四张表把业务边界划清楚

这套源码的数据库核心表是student，另有三张辅助表major、admin、reg_log。student的建表语句是：

CREATE TABLE `student` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(50) NOT NULL COMMENT '姓名', `gender` tinyint(1) NOT NULL DEFAULT '0' COMMENT '性别：0未知/1男/2女', `major_id` smallint(5) unsigned NOT NULL COMMENT '报考专业ID，关联major表的id', `phone` varchar(20) NOT NULL COMMENT '手机号', `email` varchar(100) DEFAULT NULL COMMENT '邮箱', `school` varchar(100) DEFAULT NULL COMMENT '毕业院校', `remark` varchar(500) DEFAULT NULL COMMENT '备注', `ip` varchar(15) DEFAULT NULL COMMENT '报名时记录的IP', `reg_time` datetime NOT NULL COMMENT '报名时间', PRIMARY KEY (`id`), KEY `idx_major` (`major_id`), KEY `idx_reg_time` (`reg_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

几个字段设计值得细看。gender用tinyint而不是enum或varchar，原因很简单：2012年的PHP代码里很多人习惯直接读POST值，用数字存性别可以避免前端提交任意字符串进库，取值时再在显示层做一次映射。phone用varchar(20)而不是bigint，是因为手机号可能带+86前缀或分机号，数字类型反而惹麻烦。reg_time上带索引，因为后台列表页默认就是按报名时间倒序展示，没有这个索引，数据量超过几千条之后列表页会明显变慢。

另外三张表职责很清晰：major表只管专业选项，id加专业名两个字段；admin表存后台管理员账号和MD5密码，这是当年的通行做法；reg_log表记录每次写入student表的操作来源和IP，算是审计日志的原始雏形。major表单独拆出来而不用文本字段写死专业名，是这套代码里最有设计感的一步——改一条major记录，历史数据的筛选和统计都跟着变，不用UPDATE全部学生数据。

2.3 请求处理与“土路由”：index.php怎么把数据接住

老代码的入口文件通常不依赖框架，index.php本身就是路由。核心逻辑简化下来是这一套：

<?php // inc/functions.php 提供 validate_student() 和 insert_student() include_once('inc/functions.php'); if ($_SERVER['REQUEST_METHOD'] === 'POST') { $data = array( 'name' => trim($_POST['name'] ?? ''), 'gender' => intval($_POST['gender'] ?? 0), 'major_id' => intval($_POST['major_id'] ?? 0), 'phone' => trim($_POST['phone'] ?? ''), 'email' => trim($_POST['email'] ?? ''), 'school' => trim($_POST['school'] ?? ''), 'remark' => trim($_POST['remark'] ?? ''), 'ip' => $_SERVER['REMOTE_ADDR'], 'reg_time' => date('Y-m-d H:i:s') ); list($code, $msg) = validate_student($data); if ($code !== 0) { die('校验失败：' . $msg); } $insert_id = insert_student($data); if ($insert_id > 0) { header('Location: success.php?id=' . $insert_id); exit; } die('写入失败，请稍后重试'); }

代码逻辑不复杂：先判断是不是POST请求，然后把$_POST里涉及到的字段按白名单取出来，做trim和intval清洗。这里有个值得抄的习惯——它不是把$_POST整个扔给SQL，而是手动组装一个$data数组，这在2012年的源码里已经算规范了。validate_student返回数组形式的错误码和错误消息，调用方拿到非零code就直接终止，虽然粗暴但堵住了后续的重复校验。

需要特别注意的是，网上流传的变体里，这套代码的数据库驱动可能是mysql_*也可能是mysqli，甚至有混用两种情况。如果看到两套函数同时出现，基本可以判断是某个版本被修过一半，部署时优先信mysqli那部分，因为mysql_*在PHP 7里已经彻底没了。

3. 本地部署与配置：把2012年的代码装进现在的机器

这一章的目标是在五分钟内让系统跑起来。先说环境选型，再走部署步骤，最后用curl和日志验证到底通没通。

3.1 环境选型：为什么先跑PHP 5.6而不是直接上7.4

2012年的PHP源码有个跨不过去的坎：很多变体还在用mysql_*函数，这些函数在PHP 7.0里被整体移除，直接上PHP 7.4会连数据库那段代码一起报fatal error。我的建议是第一步先把环境对齐到PHP 5.6，跑通业务再按第六章的方案迁到PHP 7。

环境搭配上，Apache用2.4，MySQL用5.7或5.5都行，但别上MySQL 8.0。老代码的字符集连接方式和用户认证协议在8.0上大概率报错，排查起来很头疼。Windows下常见做法是用phpStudy这类集成环境，把PHP版本切成5.6，Linux下可以用宝塔面板的软件商店切换。关键点只有一个：PHP 5.6必须能开启GD库、mysqli扩展和session支持。

3.2 部署步骤：解压、导库、改配置四步走

拿到源码后，常规的落地顺序是四步。

第一步，把源码放到Web目录。Windows下phpStudy的默认目录是WWW，解压后保证index.php在站点根目录，不要套一层多余的文件夹。

第二步，导入数据库。把源码里提供的SQL文件在phpMyAdmin或命令行里导入：

mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS student_sign DEFAULT CHARSET utf8;" mysql -u root -p student_sign < student.sql

注意导入前先建库，且指定utf8。如果SQL文件里自带CREATE DATABASE语句则上一条可以省，但很多流出的源码包不带建库语句，直接导入会报No database selected。

第三步，改config.php里的四项参数。多数这种源码的配置文件叫config.php或inc/config.php，内容长这样：

<?php define('DB_HOST', '127.0.0.1'); define('DB_USER', 'root'); define('DB_PASS', 'your_password'); define('DB_NAME', 'student_sign'); define('DB_CHARSET', 'utf8');

第四步，处理PHP的老配置项。2012年的源码大量依赖短标签写法，在php.ini里把short_open_tag设为On，同时打开display_errors方便排错：

short_open_tag = On display_errors = On

short_open_tag影响的是<?这种老式写法，关掉后很多模板文件会直接输出乱码或白屏。这是在老PHP上部署时最容易被忽略的坑之一，顺手在config.php里加一行mysqli连接字符合集设置更稳，细节放在避坑章展开。

3.3 验证部署：用curl和数据库确认系统真能报名

跑起来之后别急着看页面，用命令行快速验证三层是否都通了。

curl -I http://localhost/student_sign/index.php curl -X POST -d "name=test_user&gender=1&major_id=1&phone=13800138000&email=test@test.com&school=某高校&remark=" http://localhost/student_sign/index.php

第一条看HTTP状态码，200说明入口文件正常响应；第二条是模拟一次真实报名请求，POST过去后应该在响应头里看到Location跳转，或者页面里出现“报名成功”的特征字符串。然后进数据库确认：

SELECT id, name, phone, reg_time FROM student ORDER BY id DESC LIMIT 5;

如果库里出现刚才POST过去的数据，说明报名链路已经打通。如果返回500，优先看Apache的error.log和PHP的display_errors，绝大多数情况炸在mysql_*函数不存在或数据库密码配错这两处。

4. 功能定制改造：加字段、改校验、换导出的四个实战点

拿到手光会跑没用，真实业务里几乎都要改。这一章挑四个高频改动场景，从加字段一路讲到导出列调整。

4.1 新增报名字段：五个文件联动改，别漏了导出

假设要加一个“意向城市”字段，按2012年的写法，不是改一个文件就能收工，而是五处联动。student表加字段，index.php表单加输入框，inc/functions.php里的insert_student()加键，后台admin_list.php的表头加一列，admin_export.php的导出映射加一行。漏掉最后一个，就会出现前台能填、后台能看到、但导出Excel里没有这一列的尴尬结果。

先执行SQL：

ALTER TABLE student ADD COLUMN city varchar(50) DEFAULT NULL COMMENT '意向城市' AFTER school;

然后在index.php的表单里，找到school那一行input的结构，照抄改成city：

<!-- index.php 报名表单中，school输入框之后追加以下结构 --> <div class="form-item"> <label>意向城市</label> <input type="text" name="city" id="city" class="input-text" maxlength="50" value="" /> </div>

name和id必须一致，maxlength和数据库字段长度对应。插库函数里，在$data数组补上'city' => trim($_POST['city'] ?? '')。后台列表页找到school那列的th和td，复制一套改成city。最后在导出文件里，找到列映射数组或列拼接处，把city按你期望的列位置插进去。

五处全改完，这个字段才算真正走完“录入－入库－展示－导出”四个环节。很多新手改完前四处就不管导出，等到月底要统计时才反应过来。

4.2 后端校验规则：正则怎么改才不误伤真实手机号

老代码的校验通常集中在validate_student()里，2012年的风格很直白，一串if-else加preg_match就完事。最常见的手机会校验规则是这样：

function validate_student($data) { if (empty($data['name'])) { return array(1, '姓名不能为空'); } if (!preg_match('/^1[3-9]\d{9}$/', $data['phone'])) { return array(2, '手机号格式不对'); } if (empty($data['major_id'])) { return array(3, '请选择报考专业'); } return array(0, 'ok'); }

这条手机号正则今天还能用。如果你想支持固定电话或允许+86前缀，就放宽成/^(?:\+?86)?1[3-9]\d{9}$/，同时把index.php页面里的前端JS正则也同步改掉，两处要保持一致。最容易踩的坑是只改后端不改前端，用户提交时被前端的旧规则先拦一道，会误以为系统坏了。

4.3 导出Excel列顺序：调整映射数组就能完成重排

导出功能在这类源码里是调用类库实现的，常见的有简洁版ExcelWriter或PHPExcel。不少变体在admin_export.php里维护一个二维数组来控制列名和数据行的对应关系，类似这样：

$export_columns = array( '姓名' => 'name', '性别' => 'gender_format', '手机号' => 'phone', '专业' => 'major_name', '报名时间' => 'reg_time' );

想让“报名时间”往前挪，直接调整数组顺序。想让字段值经过格式化，比如把gender的数字映射成“男/女”，我建议在SQL查询里用CASE WHEN生成一列gender_format，而不是在PHP循环里做映射。数据格式化放在SQL层，PHP代码层只负责按列名取值，导出文件反而更稳定，不会因为循环里加了一行逻辑就把单元格格式搞崩。

5. 常见问题与避坑：验证码不显示、中文乱码这些场景的根因与出路

老PHP源码最大的特点就是四处藏着环境敏感点。下面五条是从这类系统里反复踩出来的记录，每条按现象、原因、解决展开。

5.1 验证码不显示：白底一块或报Call to undefined function

现象：前台报名页的验证码图片位置是空白，或者后台日志报Call to undefined function imagecreatetruecolor()。

原因：PHP环境没装或没启用GD扩展。2012年的验证码类几乎全部依赖GD库的imagecreatetruecolor、imagecolorallocate、imagestring函数。phpStudy这类集成环境里PHP 5.6默认往往带着GD，但如果是自己编译过或精简过的PHP，缺GD很常见。

解决：在php.ini里把extension=php_gd2.dll或extension=gd.so前面的注释去掉，重启PHP进程。如果GD开了还是白屏，检查php.ini里session.save_path指向的目录是否可写，不可写时session_start()会抛错，但错误信息往往被display_errors隐藏，白屏就成了表象。

5.2 中文乱码：三处字符集不一致，症状各不相同

现象：页面标题和表单是正常中文，但后台列表和导出Excel里全是乱码。

原因：2012年的PHP源码普遍是UTF-8文件，但MySQL连接字符集和表字符集经常有历史遗留。最常见的是表是gbk、页面是utf8，或者页面输出头写的是utf-8，但数据库连接没指定字符集，导致数据被MySQL按latin1转了一道，入库后就损了。

解决：先统一三处字符集。第一处，config.php里DB_CHARSET定义为'utf8'；第二处，在inc/db.php里建立连接后执行一句SET NAMES utf8：

// inc/db.php 建立连接后，强制设定连接字符集 mysqli_set_charset($conn, 'utf8');

第三处，如果历史数据已经乱码，只能靠ALTER TABLE CONVERT TO CHARACTER SET utf8整表转换，但转换前先导出备份，而且转换不会修复已损坏的数据，乱掉的历史记录要么手工修，要么从原始Excel重新导入。

5.3 数据存不进去：mysql_*函数时代留下的addslashes陷阱

现象：前台提交后页面报“字段不能为空”或SQL执行失败，但表单明明填了内容。

原因：这类源码里常见两种写法。一种是insert_student()内部对$_POST直接使用addslashes()转义，写入前又做了一次trim，如果某个字段被转义出反斜杠，再碰上magic_quotes_gpc=On的环境，字符串会被双重转义，入库后数据带反斜杠，查询时对不上。另一种是validate_student()里用empty()判断，0、空字符串、'0'都被当成空值，如果某个字段允许合法填0就会误伤。

解决：把addslashes去掉，改用mysqli_real_escape_string($conn, $value)做转义，且只对最终要拼进SQL的字符串转义一次。同时检查php.ini里magic_quotes_gpc=Off，PHP 5.4以后默认是Off，但如果你跑的是老集成环境或早期版本，务必确认。

5.4 导出Excel白屏或超时：PHPExcel的内存和执行时间双双告警

现象：点击导出后页面长时间不响应，最后白屏，或者Excel文件生成了但内容不完整。

原因：PHPExcel本身就是重量级方案，处理几百行数据就可能吃掉几十MB内存。老源码里的导出循环如果在查询时没有分页，会把几万条记录一次拉进内存再逐行写单元格，memory_limit和max_execution_time双双被击穿。

解决：常见做法是在导出页面顶部临时调大两个参数：

ini_set('memory_limit', '512M'); ini_set('max_execution_time', '300');

这只是缓解，根治办法是让导出走分批查询，每500条取一次再写Excel，而不是一次性查全量。如果只是导出几千行，临时调大足够；如果是几万行，还是改成分批更踏实。

5.5 报名时间差8小时：时区配置影响的不只是页面

现象：后台列表里reg_time显示的时间比本地时间晚8小时，下午报的名，库里记录是凌晨。

原因：PHP默认时区不是Asia/Shanghai，date('Y-m-d H:i:s')按UTC取值，导致时间字段整体偏移。2012年的代码很少主动调date_default_timezone_set()，这是老系统的通病。

解决：在config.php或公共函数里加一行date_default_timezone_set('Asia/Shanghai');，同时确认MySQL连接里的time_zone参数没被改成UTC。改完重启PHP进程，已入库的错误时间需要手工UPDATE修正，语句按字段加8小时即可。

6. 进阶：把v2012代码迁到PHP 7+，并顺手补上三个安全习惯

跑通之后如果想继续用，别停在PHP 5.6。这一章给一条可行性较高的迁移路径，顺带补三个安全习惯。先从最扎手的开始，把mysql_query改成mysqli。由于函数签名和传参方式不同，常见做法是在inc/db.php里封装一层兼容函数，把全局散落的mysql_*调用全部收敛到统一入口。

// 迁移辅助函数，放到 inc/db.php 里 function db_query($sql) { global $conn; return mysqli_query($conn, $sql); } function db_fetch_all($result) { $rows = array(); while ($row = mysqli_fetch_assoc($result)) { $rows[] = $row; } return $rows; }

然后把源码里mysql_query($sql)替换为db_query($sql)，mysql_fetch_assoc替换为db_fetch_all，遇到mysql_real_escape_string替换为mysqli_real_escape_string($conn, $value)。全部替换后逐页回归，这个工作不复杂但很碎，建议用编辑器的全局搜索功能一次性列出所有调用点，按文件逐个改。

接下来是三个安全点。第一，给所有前台和管理端的表单加CSRF token，老PHP系统普遍没有这个，攻击面很大。第二，把admin表的MD5密码换成password_hash，登录校验用password_verify。2012年的明文或MD5是历史常态，但放在今天就属于裸奔。第三，在reg_log表里补上后台操作的记录，已有的写日志只覆盖了报名来源IP，后台管理员的删除、导出行为没有痕迹，建议在admin_list.php和admin_export.php的action分支里同步insert一条日志。

迁移完别忘回归三个点：报名提交、后台筛选列表、Excel导出。哪个环节出错，先看错误日志里是否还在引用mysql_*，再看字段名和表名是否大小写不一致——Windows上不敏感，一到Linux服务器上就会立刻暴露。

最后说我的习惯。那一次在一台测试机上迁完老代码，忘了跑批量导出，第二天生产环境导出就报了一个内存错误，现场手忙脚乱调参数。从那以后我每次接手这类老代码，都强制先走一遍“报名-后台查看-导出-换一台机器重新部署”的完整链路，数据、环境、权限各测一遍，再交出去。希望帮到你。

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