企业官网建设流程全解析

简介：一套基于PHP+MySQL的企业招聘网站源码，适合需要快速构建人才网或希望深入掌握Web招聘系统开发流程的开发者、企业技术团队及高校学生。源码完整实现了企业与求职者两大核心角色，涵盖注册登录、职位发布、简历投递、简历筛选、收藏下载、面试流程跟踪、后台信息审核等主要模块，清晰展示了招聘类系统的用户角色分工、数据表关联与业务逻辑分层，并覆盖了从需求分析、数据库设计到部署上线的常见开发环节。压缩包共2000个文件，大小38.23MB，以PHP业务脚本为主，并包含前端HTML页面、CSS样式表、JavaScript交互文件以及PNG/JPG/GIF等大量图片素材；整体目录结构分明，便于直接部署、修改与二次开发。资源还附有数据库设计说明和从环境搭建到上线维护的完整开发思路，能够帮助读者在真实项目中快速上手，也可作为毕业设计或企业建站的参考方案。目前已有487人学习，值得有PHP开发基础的学习者下载研究。

1. 企业招聘网站源码与人才网源码：先立模型，再谈部署

直接搜“企业招聘网站源码 人才网源码”的人，要的不是一份需求文档，而是一套能部署、能改、能往上叠业务的功能代码。招聘源码和普通企业站源码最大的差异在于：它有至少三个角色在同时操作同一批数据，企业发职位、求职者传简历、管理员做审核，数据流一旦设计错，后面所有功能都会跟着返工。

这个标题下真正值钱的部分，不是前端页面做得有多花哨，而是数据模型和权限边界。常见的失败案例是把企业和求职者全部塞进一张 user 表，用 type 字段区分，结果职位表、简历表、投递记录全挂在同一张用户主键上，后期想做人才搜索和精准推荐，索引都没法建。所以这篇直接按“数据模型 → 搜索实现 → 部署上线 → 交付排错”的顺序讲，适合接单开发、独立建站以及想快速搭招聘平台的 PHP 或 Java 工程师参考。

2. 拆透企业招聘网站的数据模型：角色、职位、简历与投递关系

招聘网站源码的业务核心不在页面，而在几张表之间的关系设计上。把角色、职位、简历、投递记录这四块理清楚，后端接口怎么写都不会乱。市面上常见的 php 源码多基于 ThinkPHP 或 Laravel，Java 源码则偏好 Spring Boot 加 MyBatis，但底层表结构的设计逻辑是共通的。

2.1 用户角色分离：为什么不能靠一张 user 表打天下

很多初版招聘源码会把用户表设计成类似user(id, username, password, type, company_name, real_name, ...)的形态，所有角色共用一张表，再用type区分。这个做法在一开始的 CRUD 阶段很顺手，但一进入业务扩展就暴露问题：企业要维护营业执照、公司规模、融资阶段，求职者要维护期望薪资、工作年限、技能标签，两类字段完全不同。

如果硬塞在同一张表里，大量字段对某一类角色永为空值，索引效率会越来越差。而且简历表、职位表都通过user_id去关联这张混合表时，查询条件里必须反复带上type，否则一个求职者 ID 就能查到企业数据。

我一般会拆成三张表：sys_user只做认证，存账号名、密码哈希、角色和状态；company存企业扩展信息；candidate_profile存求职者扩展信息。sys_user是纯认证表，不承载业务属性，后续接微信登录、SSO、管理员端都方便。

CREATE TABLE `sys_user` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `username` VARCHAR(64) NOT NULL, `password_hash` VARCHAR(255) NOT NULL, `role` TINYINT NOT NULL DEFAULT 2 COMMENT '1=管理员 2=求职者 3=企业', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '0=禁用 1=正常', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这张表的要点是role只负责告诉系统“这个账号属于哪个端”，具体端内的业务数据放到关联表里。查询企业信息时先确认sys_user.role = 3，再通过company.user_id取详情，职责清晰，索引也能各用各的。

2.2 核心三表：job、resume 与 job_application 的字段设计

以人才网源码最常见的业务场景来看，job表承载企业的招聘需求，resume表承载求职者的完整履历，job_application记录双方之间的投递动作。这三张表的设计直接决定了后面搜索模块能不能建索引、投递状态能不能做聚合统计。

job表的重点是把薪资拆成salary_min和salary_max，而不是存一个“8-15K”的字符串。字符串在展示上没问题，但按薪资范围筛人才时，要么用 LIKE 匹配，要么写一堆字符串截断逻辑，性能和安全都吃亏。用两个整型字段，查询salary_max >= 8000 AND salary_min <= 15000就能直接走索引。

CREATE TABLE `job` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `company_id` INT UNSIGNED NOT NULL, `title` VARCHAR(120) NOT NULL, `salary_min` INT DEFAULT 0 COMMENT '月薪下限，单位元', `salary_max` INT DEFAULT 0 COMMENT '月薪上限，单位元', `work_city` VARCHAR(64) DEFAULT '', `degree_required` VARCHAR(30) DEFAULT '', `experience_required` VARCHAR(30) DEFAULT '', `description` TEXT, `status` TINYINT NOT NULL DEFAULT 1 COMMENT '0=下架 1=招聘中', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_company_id` (`company_id`), KEY `idx_city_salary` (`work_city`, `salary_max`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

idx_city_salary是城市加薪资的联合索引，经典的人才筛选条件是“北京、10K 以上”，这个索引能直接把扫描范围缩小到单个城市。这里要注意联合索引的字段顺序，等值条件work_city放前面，范围条件salary_max放后面，MySQL 才能同时利用两个字段。

resume表的核心是snapshot_text字段。求职者上传的简历文件可能是 Word 或 PDF，系统解析后把纯文本内容存入这个字段，搜索时直接在全文字段上匹配。这个字段和skill_tags、job_expectation配合，可以让企业端的人才搜索在一个查询里同时命中技能标签、意向职位和简历正文。

CREATE TABLE `resume` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `candidate_id` INT UNSIGNED NOT NULL, `title` VARCHAR(120) NOT NULL, `skill_tags` VARCHAR(255) DEFAULT '', `job_expectation` VARCHAR(120) DEFAULT '', `salary_expectation` VARCHAR(50) DEFAULT '', `work_experience` TEXT, `education_background` TEXT, `attachment_path` VARCHAR(255) DEFAULT '', `snapshot_text` MEDIUMTEXT, `updated_at` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_candidate_id` (`candidate_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

投递记录表要单独拎出来讲，是因为很多源码把“投递”做成在 job 表里加一个apply_count计数，再在简历表里加一个applied_job_ids字段，这是典型的反范式设计。投递动作应该是一张独立的关系表，job_id和resume_id各建索引，这张表天然支持“这个职位收到了多少简历”和“这个求职者投了哪些公司”两类查询。

CREATE TABLE `job_application` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `job_id` INT UNSIGNED NOT NULL, `resume_id` INT UNSIGNED NOT NULL, `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0=待查看 1=已查看 2=约面试 3=不合适', `message` VARCHAR(255) DEFAULT '', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_job_id` (`job_id`), KEY `idx_resume_id` (`resume_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

status字段就是投递状态机。这里不建议把约面试的日期、面试官信息直接塞进job_application，面试流程本身会扩展，单独建interview表会更干净。初版源码保持四张表足够支撑整个招聘流程跑通。

2.3 简历快照：企业端人才搜索的底层依赖

企业端搜简历时，期望的是输入“PHP 开发 三年经验”，把所有匹配的求职者捞出来。如果只靠resume表的几个结构化字段，work_experience里的具体项目描述就搜不到，而这块往往是判断候选人能力的关键信息。

常规做法是在简历上传后做一次文本抽取，把 DOCX、PDF 转成纯文本，写入snapshot_text。搜索接口的查询条件直接匹配skill_tags + job_expectation + snapshot_text。这里有一个容易踩的坑：不要把新简历的文本抽取做成同步逻辑，上传接口会变得很慢，常见做法是丢进消息队列或定时任务，简历先保存，解析完再回填。

注意：snapshot_text字段上限是 MEDIUMTEXT，约 16MB，足够放一份完整简历的文本内容。解析出来的文本如果包含大量排版空白，入库前要做preg_replace('/\s+/', ' ', $text)这类压缩处理，否则全文索引的存储开销会明显变大。

3. 人才搜索引擎实现：从 LIKE 到全文索引的选型与参数

招聘网站源码里，企业端每天打开最多的页面不是职位管理，而是“人才搜索”。这一章把搜索模块的演进路径讲清楚：小数据量怎么用 LIKE 撑住，什么时候换 MySQL 全文索引，再往上走该考虑什么组件。

3.1 LIKE 查询的边界：为什么%关键词%不能一直用

WHERE skill_tags LIKE '%PHP%'这个写法在数据量小时看不出问题，但它的致命缺陷在索引失效。%放在关键词前面时，MySQL 无法使用 B+ 树索引做快速定位，只能全表扫描。`

当resume表到达十万行级别，每次人才搜索都扫一遍全表，数据库 CPU 会明显吃紧。用EXPLAIN SELECT ... WHERE skill_tags LIKE '%PHP%'查看执行计划，type列是ALL，也就是全表扫描，rows逼近表总行数。这时与其研究怎么优化 LIKE，不如直接换检索方案。

但也有一个例外。搜索条件里如果只拿简历标题做前缀匹配，LIKE 'PHP%'是可以走索引的，只有后缀匹配和包含匹配才必然失效。所以早期项目可以把“按标题搜”和“按内容搜”拆开，前者用 LIKE，后者走全文索引。

3.2 用 MySQL 全文索引撑起早期人才搜索

当数据量到了几十万行，又不想为了搜索单独引入一套 Elasticsearch 时，MySQL 5.7 以上的全文索引是性价比最高的方案。InnoDB 全文索引天然支持中文分词，关键是要用 ngram 解析器，它对中文按连续的两个字符切分，比如“PHP开发”会被切成“PHP”“开”“发”三个 token。

先为resume表添加全文索引：

ALTER TABLE `resume` ADD FULLTEXT INDEX `idx_resume_fulltext` (`resume_title`, `skill_tags`, `snapshot_text`) WITH PARSER ngram;

ngram 的默认分词长度是 2，也就是ngram_token_size=2，这个值在 MySQL 配置文件中调整。设为 2 时，单字搜索会被忽略，搜索“PHP”没问题，搜索“P”就没有结果。对招聘场景来说，用户输入的都是“PHP”“前端”“会计”这种双字以上的关键词，默认值可以不动。

检索语句使用MATCH ... AGAINST的布尔模式：

SELECT id, resume_title, skill_tags, salary_expectation FROM `resume` WHERE MATCH (resume_title, skill_tags, snapshot_text) AGAINST ('+PHP +三年' IN BOOLEAN MODE) LIMIT 20;

布尔模式下+表示关键词必须出现，-表示不能出现，不加符号时相当于 OR 关系。查询“PHP 三年”时，如果希望候选人必须同时满足两个条件，就用+PHP +三年，否则搜出来的结果会包含大量只写了一个关键词的简历，噪音很大。分词后的匹配是等价的，所以对“三年经验”这种完整短语，建议在代码里先对输入做分词再拼条件，而不是整个短语丢进去。

3.3 再往上走：Elasticsearch 的同步与查询长什么样

当简历量达到几百万级别，或者开始需要按“工作年限 3-5 年 且 期望薪资 15K-20K 且 技能包含 Redis”这种组合条件搜索时，MySQL 全文索引就不够吃了。此时把简历数据同步到 Elasticsearch，是一个成熟的演进路线。

同步方案在新老系统中都很常见：一张sync_record表记录每次同步的游标，定时任务每五分钟拉取updated_at大于游标的增量简历，批量写入 ES。删除操作要额外处理，否则 ES 里会残留已下线的简历。

ES 侧的索引 mapping 大致是：

{ "settings": { "analysis": { "analyzer": { "ik_smart": { "type": "custom", "tokenizer": "ik_smart" } } } }, "mappings": { "properties": { "resume_title": { "type": "text", "analyzer": "ik_smart" }, "skill_tags": { "type": "text", "analyzer": "ik_smart" }, "snapshot_text": { "type": "text", "analyzer": "ik_smart" }, "salary_expectation": { "type": "keyword" }, "work_years": { "type": "integer" }, "updated_at": { "type": "date" } } } }

搜索语句用bool查询组合条件，must是必须匹配的文本条件，filter是结构化过滤条件，能做缓存，性能比全部塞进must好：

{ "query": { "bool": { "must": [ { "match": { "skill_tags": "PHP" } } ], "filter": [ { "term": { "work_city": "北京" } }, { "range": { "salary_expectation": { "gte": "10K" } } } ] } } }

提示：如果项目初期就明确要做人才推荐和语义搜索，可以直接从 ES 起步，省去从 MySQL 全文索引迁移的步骤。但代价是需要额外维护一套集群，单机部署至少要 2GB 内存给 ES JVM。

4. 企业招聘网站源码的部署路径：伪静态、上传安全与初始化

源码拿到手之后，最怕的就是按照默认配置直接丢到服务器上，页面能打开就以为上线了。企业招聘网站源码的部署有几个特定环节，每一步都和后续运营稳定性挂钩。

4.1 源码目录拆解：入口文件、应用目录与上传目录

下载到的源码包解压后，第一个动作是确认目录结构里哪几个目录能被外部直接访问。以 ThinkPHP 系源码为例，public/通常是唯一需要暴露给 Nginx 的根目录，application/、runtime/、config/都在public/之外。如果你看到源码包里所有目录都能通过 URL 直接访问，比如http://ip/application/database.php，说明这份源码的部署方式不对，需要调整站点根目录。

正确的做法是让 Nginx 的root指向public/目录。这样即使有人猜路径，也访问不到application下的配置代码。上传目录一般位于public/uploads/，这个目录需要开放写入权限，但要单独做安全限制。

4.2 Nginx 伪静态与 PHP 运行参数配置

ThinkPHP 系的 URL 默认是index.php?s=/job/detail/id/1这种形式，体验不好，也会暴露框架特征。部署时配置伪静态，将 URL 重写成简洁路径，同时把真实入口隐藏掉。

server { listen 80; server_name talent.example.com; root /var/www/talent/public; index index.php index.html; location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s=$1 last; } } location ~ \.php$ { include fastcgi_params; fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }

这段配置里，if (!-e $request_filename)判断请求的文件或目录是否真实存在，不存在就交给入口文件处理。SCRIPT_FILENAME必须指向磁盘上的真实路径，否则 PHP-FPM 会返回空白页。部署后访问/job/detail/1，如果页面正常，说明伪静态规则生效。

PHP-FPM 的php.ini里有两个参数值得单独调。upload_max_filesize要调到 10M 以上，否则求职者上传的 PDF 简历会被静默丢弃；post_max_size要大于upload_max_filesize，因为上传请求的 body 里除了文件还有表单字段。这两个参数漏配，是招聘网站“上传简历失败”的高频原因。

4.3 初始化数据库与创建管理员账号的常用命令

源码包里的 SQL 文件通常要手动导入。导入前先建库，注意字符集必须和源码配置文件保持一致，招聘网站因为简历内容包含大量人名和特殊符号，建议统一使用utf8mb4：

mysql -uroot -p -e "CREATE DATABASE IF NOT EXISTS talent DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;" mysql -uroot -p talent < talent.sql

如果 SQL 文件超过 50MB，mysql命令导入会明显变慢，这时改用source方式或分片导入。导入后检查sys_user表里是否已有管理员账号，如果没有，需要手动插入一条。密码字段是哈希值，不要直接写明文。

INSERT INTO `sys_user` (`username`, `password_hash`, `role`, `status`) VALUES ('admin', '$2y$10$e0MYzXyjpJS7Pd0RVvHwHePFHcN8Pc0B1CzWzY6mGQOB7OxUj7g3S', 1, 1);

生成这个哈希可以用 PHP 命令行工具：

php -r "echo password_hash('YourPassword123', PASSWORD_BCRYPT), PHP_EOL;"

把输出的哈希替换到 SQL 语句里再执行。直接往数据库插管理员是常规做法，但要记得执行完删掉命令行记录或执行记录，避免密码哈希残留在 shell history 中。

4.4 上传目录安全加固：阻止脚本文件执行

招聘网站的上传目录是最容易出问题的位置。攻击者如果找到了文件上传接口的漏洞，传一个 PHP 马上去，紧接着访问/uploads/shell.php就能直接执行命令。所以无论在源码层面做了多少校验，Web 服务器层面一定要加上“上传目录禁止执行 PHP”的规则。

location ~* /uploads/.*\.(php|php5|phtml)$ { deny all; }

这段规则放到 Nginx 配置的server块里，作用是把uploads目录下所有 PHP 文件的访问直接返回 403。上传目录里只应该存放静态文件，禁止执行脚本是底线。同样值得做的是给上传文件重命名为无扩展名或随机文件名，但 Web 服务器层的拦截是第一道关，两条都做才算完整。

注意：如果源码使用宝塔面板进行源码建站，面板的 Nginx 配置里也有类似的上传目录防护选项，但默认不一定会开启。手动确认一下伪静态规则和上传目录的 PHP 禁用状态，比依赖面板默认值更稳妥。

5. 交付后最容易翻车的三个问题：权限越权、附件直链与慢查询

招聘网站源码部署完成、功能验收通过，不代表就结束了。上面这三个问题在交付后一到两周内最容易冒出来，每一个都可能让客户直接发火。提前修掉它们，比事后道歉省心得多。

5.1 IDOR 越权检测：注册两个账号换着访问

越权漏洞在招聘网站里尤其危险。企业账号登录后访问/candidate/detail/id/1，如果后端只校验了“已登录”而没有校验“这个企业是否被允许查看该简历”，那就能看到全站所有求职者的姓名、电话、工作经历。求职者端同理，改一下投递记录的 ID 就能看到别人的面试反馈。

检测方法简单粗暴：注册两个企业账号 A 和 B，用 A 发布职位并收藏一份简历，然后退出登录，用 B 访问 A 的数据对象 URL，能打开就说明存在越权。修复时在控制器里先查归属：

public function view($id) { $application = Db::name('job_application')->find($id); if (!$application || $application['company_id'] !== session('company_id')) { return json(['code' => 403, 'msg' => '无权访问']); } // 正常返回数据 }

不能只在前端隐藏按钮，后端每个详情接口、每个列表接口都要做同样的归属判断。这里尤其注意“列表接口返回了本不该出现的字段”的情况，例如企业端收简历列表的 SQL 里多 select 了求职者手机号，即使页面没显示，接口返回的 JSON 里也能看到，属于典型的信息泄露。

5.2 简历附件下载如何做到鉴权与防盗链

简历附件如果直接存成public/uploads/resume/2024/xxx.pdf，任何人都可以通过拼接 URL 下载，根本不需要登录，这会直接导致求职者隐私批量泄露。正确做法是把附件移出公开目录，存到 Web 根目录之外的位置，下载时通过 PHP 脚本校验权限后输出文件内容。

public function download($resumeId) { if (!$this->checkPermission($resumeId)) { http_response_code(403); exit; } $file = STORAGE_PATH . '/resume_files/' . $resumeId . '.pdf'; if (!is_file($file)) { http_response_code(404); exit; } header('Content-Type: application/pdf'); header('Content-Disposition: attachment; filename="resume-' . $resumeId . '.pdf"'); readfile($file); }

checkPermission里至少要判断：当前登录用户是否是简历所有者，或者是否收到了该候选人主动投递的职位。这两个条件满足一个才允许下载。既然附件已经不能直接访问，就不存在防盗链的问题了。

5.3 用慢查询日志直接定位人才搜索的性能瓶颈

最后一个是性能排查手段。招聘网站部署后最容易被投诉的是“搜人很慢”，这时候不要靠感觉猜，直接看数据库的慢查询日志。

slow_query_log = ON slow_query_log_file = /var/log/mysql/mysql-slow.log long_query_time = 1

long_query_time=1表示执行超过 1 秒的 SQL 都会被记录。让客户复现一次“搜索速度很慢”的操作，然后从日志里抓取对应语句：

mysqldumpslow -s t -t 20 /var/log/mysql/mysql-slow.log

-s t按查询耗时排序，-t 20只显示前 20 条。如果排名前列的是WHERE snapshot_text LIKE '%xxx%'，说明还在用 LIKE 搜简历全文，直接按第三章的方式换成全文索引即可。如果查询里已经用了MATCH ... AGAINST但仍然慢，查看执行计划确认索引是否被选中，以及ngram_token_size是否导致了超大索引。慢查询日志是招聘网站源码上线后的通用体检工具，每次版本更新后跑一遍，比任何监控面板都直观。

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