企业官网建设流程全解析

这套系统是我用 ThinkPHP 和 Laravel 两个框架分别落地过的同一个简历智能推荐系统。标题里的_jw8dzu00是部署平台生成的项目唯一标识，这类命名常见于内部管理平台或结业项目归档。简单说，这套系统解决的问题很实际：求职者上传简历，招聘方发布岗位，系统自动计算匹配度，把合适的简历推荐给岗位，也把合适的岗位推荐给求职者，替代招聘人员大量的人工筛选工作。适合正在做 PHP 方向设计、或者想在中小型系统里塞一个轻量推荐引擎的开发者参考。整篇文章会围绕推荐引擎怎么在 PHP 技术栈里落地、Laravel 和 ThinkPHP 各自怎么接入、以及我实际做过之后踩过的坑来展开。

1. 需求拆解与整体设计思路

1.1 这个系统到底要解决什么问题

做过招聘类平台的人应该都有同感：简历和岗位的数据量一旦上来，人工匹配的效率会急速下降。比如某就业信息平台，每周新增几百份简历和几十个新岗位，招聘方想从里面找到符合要求的人，基本只能靠关键词检索，检索出来的结果还要一条条点开看，效率非常低。这个项目的核心目标就是把"人找岗"和"岗找人"两个动作自动化。

这里有一个容易被忽略的点：很多同类系统的推荐逻辑只做"标签相等匹配"，比如岗位要求写了 PHP，简历技能里也有 PHP，就认为匹配。但实际场景里，一份写了很多 Laravel 经验的简历，和一个要求"ThinkPHP 经验"的岗位，标签上不完全重合，可这份简历的候选人大概率能胜任。所以系统不能只做简单的标签碰撞，需要从文本层面做语义相似度计算，再结合硬性条件做综合排序。

1.2 为什么一个仓库里出现了两个框架

这是这个项目比较特殊的地方。原始需求来自某个高校就业信息平台，历史代码基于 ThinkPHP 5 开发，维护多年，业务逻辑和后台管理界面都在上面。后来新团队接手，新功能统一使用 Laravel 开发，形成了新老代码共存的局面。也就是说，如果只写一套框架的接入方案，在实际使用时反而对不上现场情况。两个框架同时维护，并不是刻意炫技，而是真实开发环境里常见的技术债。

在新设计里，推荐引擎被做成了一个完全独立的 PHP 类库，不依赖任何框架的模型、数据库、请求对象。Laravel 端通过自定义服务类调用它，ThinkPHP 端在控制器里直接实例化它。这样做的好处很明显：核心算法只有一套，不会出现两个框架下推荐结果不一致的问题。这个设计决策是整个系统能顺利推进的关键，后面讲接入方式时还会再提及。

1.3 功能清单与模块边界

• 用户与角色管理：求职者、招聘方、管理员三类角色，独立登录与权限控制
• 简历管理：在线填写、文件上传解析、简历历史版本
• 职位管理：招聘方发布、编辑、上下架，管理员审核
• 智能推荐：基于简历推荐岗位、基于岗位推荐简历两个方向
• 投递闭环：求职者投递简历，招聘方查看并反馈状态
• 系统配置：关键词词库、推荐权重参数、每页推荐数量

这六个模块里，最核心、最值得展开的是智能推荐模块。接下来我会重点讲推荐引擎的设计，再回到两个框架的接入实操上。

2. 框架选型对比与数据库建模

2.1 Laravel 和 ThinkPHP 的核心差异

把两个框架放在同一篇文章里讲，正好做一个直观对比。下面这个表格是我在实际开发中的感受，不是官方的全面评测，但很能说明选型时该考虑什么。

2.2 推荐引擎如何与框架解耦

我最早踩过一个大坑：直接把推荐逻辑写在 Laravel 的 Service 类里，类里面直接调用了 Eloquent 模型，导致 ThinkPHP 端根本没法复用这套代码。后来把推荐引擎剥离成独立的RecommendCore类，输入输出都只依赖基本数组和字符串，整个结构变得清晰很多。

// 推荐引擎接口设计 $resumeData = [ 'content_text' => $resumeText, 'skill_tags' => ['php', 'laravel', 'mysql'], 'work_years' => 3, 'education' => '本科', ]; $jobData = [ 'id' => 101, 'title' => 'PHP开发工程师', 'requirement' => $jobRequirementText, 'tags' => ['php', 'thinkphp', 'redis'], 'education' => '大专及以上', 'work_years_min' => 1, ]; $score = $recommendCore->match($resumeData, $jobData);

这个接口设计的好处是，任何框架只需要负责从数据库查出数据、组装成数组，再调用match方法拿分数，完全不用关心算法内部怎么计算。这在两套框架共存的项目里，价值非常大。

2.3 数据库表设计

系统总共设计了八张核心表，下面把关键的字段列出来，这是整个推荐的底层基础。

这里特别说下keyword_dict表的用途。它不只是简单存一个词，还存了doc_count，也就是这个词在多少篇文档里出现过，这是后面算 IDF 权重的关键数据。表结构用 SQL 维护，方便两个框架共用。

CREATE TABLE `keyword_dict` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `word` varchar(50) NOT NULL COMMENT '关键词', `category` varchar(20) DEFAULT '' COMMENT '词分类：技能/学历/行业', `doc_count` int(11) DEFAULT '0' COMMENT '出现该词的文档数', `weight` decimal(5,2) DEFAULT '1.00' COMMENT '人工权重系数', `is_custom` tinyint(4) DEFAULT '0' COMMENT '是否人工添加', PRIMARY KEY (`id`), UNIQUE KEY `uk_word` (`word`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

3. 推荐引擎的核心设计与 PHP 实战实现

3.1 为什么选 TF-IDF 加余弦相似度

很多人一听到"智能推荐"，第一反应是上协同过滤、甚至深度学习模型。但在 PHP 技术栈里，这些方案落地成本都很高，需要额外部署 Python 服务或者引入重型组件。我的判断是，在简历和岗位这个场景里，文本内容本身已经包含了大量有效信息，用 TF-IDF 把文本转成向量，再用余弦相似度算文本层面的匹配度，已经能达到不错的效果。

TF-IDF 的思想很简单：一个词在一份文档里出现次数越多越重要，但它在所有文档里出现得越普遍就越不重要。比如"PHP"在简历里出现五次，在岗位要求里出现五次，而且这个词在语料库的简历文档里只出现在三成文档中，那么"PHP"的权重就很高。而"负责"这种词出现再多也没用，因为几乎所有简历里都有，区分度很低。这个逻辑用数学公式表达就是TF * IDF，每个词算出权重后，把整篇文档变成一个向量。

3.2 中文分词与关键词提取的落地方式

中文分词一直是 PHP 做文本处理的痛点，不像 Python 有现成的 jieba。我在这个项目里的做法是分两层处理：结构化的技能标签用词库精确匹配，非结构化的文本内容做正则和词库结合的粗粒度提取。简单说就是：英文技能词直接正则提取，中文词从keyword_dict词表匹配，不在词表里的连续汉字按固定长度切分后过滤停用词。

private function tokenizeContent(string $text): array { $text = mb_strtolower($text); $text = preg_replace('/[\s，。！？、；：""''（）\n\r\t]+/u', ' ', $text); $tokens = []; // 1. 技能词优先：从词库里精确匹配 $customWords = ['php', 'laravel', 'thinkphp', 'mysql', 'redis', 'vue', 'react', 'docker', 'nginx', 'linux']; foreach ($customWords as $word) { if (mb_strpos($text, $word) !== false) { $tokens[] = $word; } } // 2. 英文单词和版本号提取 preg_match_all('/[a-z][a-z0-9+#\.]*/u', $text, $matches); foreach ($matches[0] as $word) { if (!in_array($word, $tokens) && !$this->isStopWord($word)) { $tokens[] = $word; } } // 3. 中文双字词切分，过滤常见停用词 preg_match_all('/[\x{4e00}-\x{9fa5}]{2,4}/u', $text, $cnMatches); foreach ($cnMatches[0] as $phrase) { $phraseTokens = $this->splitChinesePhrase($phrase); foreach ($phraseTokens as $token) { if (!$this->isStopWord($token)) { $tokens[] = $token; } } } return array_unique($tokens); }

我解释一下这样设计的意图：技能词优先保证了"PHP开发工程师"这种核心关键词一定会被提取到；英文正则补充了 Laravel、MySQL 这类技术名词；中文双字词切分是为了处理"熟练掌握" "团队协作"之类描述。效果比不上专业分词工具，但对于推荐匹配来说，特征已经足够用了。如果你有条件部署 SCWS 扩展或者 HTTP 分词服务，把第一步替换成第三方分词结果就行，后面的向量计算逻辑完全不用变。

3.3 向量构建与相似度计算

分词完成之后，下一步是构建 TF-IDF 向量并计算相似度。这里有一个细节：IDF 的统计不能实时算，否则每来一份简历都要全表扫描。我的方案是定时任务每小时更新一次keyword_dict.doc_count，系统运行时直接读取词表里的值。

public function buildVector(string $text): array { $tokens = $this->tokenizeContent($text); $termCount = array_count_values($tokens); $vector = []; foreach ($termCount as $term => $count) { $tf = $count / max(count($tokens), 1); $docFrequency = $this->termDocFrequency[$term] ?? 1; $idf = log(($this->totalDocCount + 1) / ($docFrequency + 1) + 1); $vector[$term] = $tf * $idf * ($this->termWeights[$term] ?? 1.0); } arsort($vector); return array_slice($vector, 0, 50, true); } public function cosineSimilarity(array $vectorA, array $vectorB): float { $dot = 0.0; $normA = 0.0; $normB = 0.0; foreach ($vectorA as $term => $value) { $normA += $value * $value; if (isset($vectorB[$term])) { $dot += $value * $vectorB[$term]; } } foreach ($vectorB as $value) { $normB += $value * $value; } if ($normA == 0.0 || $normB == 0.0) { return 0.0; } return $dot / (sqrt($normA) * sqrt($normB)); }

termWeights是我后来加进去的人工权重数组。比如"mysql"这个词在简历里出现的频率很高，但岗位要求里可能只写一句"熟悉 mysql"，导致这个词的匹配被高频词稀释。人工给它加一个 1.5 倍的权重，对技术类岗位的匹配效果提升非常明显。这个细节让我意识到，算法是基础，但领域知识必须通过参数调节注入系统。

3.4 规则评分与文本相似度如何融合

光靠文本相似度会忽略硬性条件，比如学历、工作经验、薪资期望。一个要求硕士学历的算法岗，和一个专科学历的候选人，哪怕简历文本写得很像，也不应该排在推荐列表前面。所以最终分数我用加权融合的方式：文本相似度占六成，硬性条件规则分占四成。

public function match(array $resumeData, array $jobData): array { $textScore = $this->cosineSimilarity( $this->buildVector($resumeData['content_text']), $this->buildVector($jobData['requirement']) ); $ruleScore = 0.0; if ($jobData['education'] !== '不限' && !empty($resumeData['education'])) { $educationMap = ['初中' => 1, '高中' => 2, '大专' => 3, '本科' => 4, '硕士' => 5, '博士' => 6]; $resumeLevel = $educationMap[$resumeData['education']] ?? 0; $jobLevel = $educationMap[$jobData['education']] ?? 0; if ($resumeLevel >= $jobLevel) { $ruleScore += 0.25; } } if ($resumeData['work_years'] >= ($jobData['work_years_min'] ?? 0)) { $ruleScore += 0.25; } // 标签交集比例 $resumeTags = array_map('strtolower', $resumeData['skill_tags'] ?? []); $jobTags = array_map('strtolower', $jobData['tags'] ?? []); if (!empty($jobTags)) { $intersect = count(array_intersect($resumeTags, $jobTags)); $ruleScore += 0.5 * ($intersect / count($jobTags)); } $finalScore = 0.6 * $textScore + 0.4 * $ruleScore; return [ 'score' => round($finalScore, 4), 'text_score' => round($textScore, 4), 'rule_score' => round($ruleScore, 4), 'reason' => $this->generateRecommendReason($resumeData, $jobData), ]; }

为什么要保留text_score和rule_score两个子分数？因为前端展示推荐理由时需要知道是"技能匹配"还是"经验匹配"，这个信息不能丢。也是后来做推荐反馈时的重要数据。

4. 实操过程：环境搭建与框架集成

4.1 Laravel 端的接入方式

Laravel 端接入推荐引擎非常顺，因为整个框架的服务容器和自动加载机制让依赖注入很自然。我建议各位把推荐引擎放到app/Services/RecommendCore.php，然后用一个门面去调用。

namespace App\Services; class RecommendCore { // 上面提到的 buildVector、cosineSimilarity、match 方法都放在这里 } // 在控制器中使用 namespace App\Http\Controllers\Api; use App\Models\Job; use App\Models\Resume; use App\Services\RecommendCore; class RecommendController extends Controller { public function jobsForResume(Request $request) { $userId = $request->user()->id; $resume = Resume::where('user_id', $userId)->firstOrFail(); $recommendCore = app(RecommendCore::class); $candidateJobs = Job::where('status', 1) ->limit(2000) ->get() ->toArray(); $scores = []; foreach ($candidateJobs as $job) { $resumeData = [ 'content_text' => $resume->content_text, 'skill_tags' => json_decode($resume->skill_tags, true) ?: [], 'work_years' => $resume->work_years, 'education' => $resume->education, ]; $jobData = [ 'id' => $job['id'], 'requirement' => $job['requirement'], 'tags' => json_decode($job['tags'], true) ?: [], 'education' => $job['education'], 'work_years_min' => $job['work_years_min'], ]; $result = $recommendCore->match($resumeData, $jobData); if ($result['score'] > 0.05) { $scores[$job['id']] = $result; } } uasort($scores, fn($a, $b) => $b['score'] <=> $a['score']); return response()->json(array_slice($scores, 0, 10, true)); } }

这里有几个实际开发中的注意点。toArray()返回的字段全部是字符串，work_years在数据库里是 int 类型，但查询出来可能是字符串，建议在模型里做类型转换，避免规则判断时出现类型比较问题。另外 Laravel 的模型访问器很实用，比如skill_tags在数据库里是 JSON 字符串，可以在模型里配置$casts，读取时自动变成数组，控制器里的代码可以更干净。

4.2 ThinkPHP 端的适配方式

ThinkPHP 端接同一套RecommendCore类时，最省事的做法是把它放到app/common/service/目录下，命名空间设置为app\common\service，这样两个框架都能引用同一个类文件。如果项目是两个独立仓库，就把这个类文件复制到各自的app/Services和app/common/service下，但保持类名和方法完全一致。

namespace app\common\service; class RecommendCore { // 与 Laravel 版完全相同的核心代码 }

控制器里的调用就非常简单了：

namespace app\index\controller; use app\common\service\RecommendCore; use think\facade\Db; use think\facade\Session; class Recommend extends BaseController { public function index() { $userId = Session::get('user_id'); if (!$userId) { return json(['code' => 0, 'msg' => '请先登录']); } $resume = Db::name('resume')->where('user_id', $userId)->find(); if (!$resume) { return json(['code' => 0, 'msg' => '请先完善简历']); } $recommendCore = new RecommendCore(); $jobs = Db::name('jobs')->where('status', 1)->limit(2000)->select()->toArray(); $scores = []; foreach ($jobs as $job) { $resumeData = [ 'content_text' => $resume['content_text'], 'skill_tags' => json_decode($resume['skill_tags'], true) ?: [], 'work_years' => $resume['work_years'], 'education' => $resume['education'], ]; $jobData = [ 'id' => $job['id'], 'requirement' => $job['requirement'], 'tags' => json_decode($job['tags'], true) ?: [], 'education' => $job['education'], 'work_years_min' => $job['work_years_min'], ]; $result = $recommendCore->match($resumeData, $jobData); if ($result['score'] > 0.05) { $scores[$job['id']] = $result; } } uasort($scores, fn($a, $b) => $b['score'] <=> $a['score']); // 渲染模板 return view('recommend/index', ['recommendations' => array_slice($scores, 0, 10, true)]); } }

两个框架的调用代码几乎一模一样，唯一的差别一个是 Eloquent，一个是 Db 门面。这正好验证了前面解耦设计的效果。如果你是从 ThinkPHP 旧项目往 Laravel 迁移，这种结构可以让核心业务代码一次编写，两端复用。

4.3 用队列和缓存处理推荐耗时问题

第一次上线测试时，推荐接口耗时接近一秒，问题出在每次请求都要实时遍历 2000 个岗位，每个岗位都要做分词和向量计算。后来做了两个优化：第一个是加缓存，推荐结果生成后写入 Redis，有效期两小时，用户在有效期内看到的是同样的推荐列表；第二个是改成异步队列，每天凌晨用定时任务批量生成所有人的推荐结果。

Laravel 端用队列表加任务类实现，ThinkPHP 端用 Linux crontab 调用命令行方法实现。核心逻辑一样：先Cache::put('recommend:user:' . $userId, $result, 7200)，再在读取时先查缓存。缓存命中率上去之后，接口耗时从 980ms 降到了 120ms 左右，用户体验提升明显。这个优化是必须做的，否则每次页面刷新都实时算一遍，MySQL 和 CPU 的压力都吃不消。

4.4 前端展示与推荐理由生成

推荐结果的前端展示也有讲究。只显示"匹配度：87%"会让用户觉得莫名其妙，必须告诉他为什么匹配。所以GenerateRecommendReason这个方法很重要，它的逻辑是：优先展示命中的技能标签，其次展示工作经验符合，最后展示学历符合。

例如输出："推荐理由：技能匹配 PHP、MySQL、Redis；3年经验满足岗位1年经验要求。"用户一看就知道这个推荐是有依据的，点击率和接受度明显高于没有理由的纯列表。另一个经验是推荐列表不要只给用户看，要提供"不感兴趣"的反馈按钮。用户点掉一个岗位后，系统把这个岗位 id 加入该用户的白名单，下次推荐直接排除。这样推荐系统才有持续优化的闭环，而不仅仅是一次性的计算。

5. 常见问题与排查技巧实录

5.1 中文分词不准，推荐结果严重跑偏

这是我在测试阶段遇到的最大问题。最初的版本没有技能词库优先策略，直接用正则提取英文词加双字切分，导致简历里"熟悉 PHP 开发"和"熟悉 PHP 框架"被切成完全不同的词向量，两个明明高度匹配的文档算出来相似度很低。

后来做了两个改进：一是维护keyword_dict词库，把 IT 领域常用的技能词、框架名、数据库名全部录入，并且给每个词打上分类标签；二是分词时先做词库精确匹配，命中词库的词直接作为 token，不参与后续的模糊切分。这个改动让推荐准确率有了质的提升。如果是更复杂的场景，建议直接部署专业的 PHP 分词扩展，或者把文本发送到独立的分词服务处理后再返回结果。

5.2 相似度计算太慢，如何优化性能

实时遍历计算最大的瓶颈是 foreach 里嵌套了完整的向量构建流程，每个岗位都要重新分词。优化的方向有三个：第一，岗位文本和岗位向量提前算好，存到 redis 或数据库字段vector_json里，查询时直接读取，不用每次实时算；第二，先通过 SQL 粗筛缩小候选集，比如先只查技能标签有交集的岗位，再用文本相似度细排；第三，对向量只保留权重最高的前 50 个词，减少余弦计算时的维度。

我做了一个简单的压测对比：未优化时 30 个并发请求直接把 CPU 打满，接口平均耗时 1.2 秒；优化后同样的并发量，接口平均耗时 150 毫秒，数据库连接数也稳定了。对于中小型系统来说，这三个优化足够支撑日活几千人的场景。

5.3 投递状态和推荐记录对不上

这个问题的现象是：推荐列表里有某个岗位，但用户点击投递后，推荐记录里的is_read字段没有更新，而且投递状态一直停留在"待处理"。排查后发现是事务使用不当导致的。用户在点击投递按钮时，接口同时做了三件事：写入投递记录、更新推荐记录的is_read、给招聘方生成一条站内通知。这三步都在一个事务里，但代码里有一个中间步骤返回了响应，导致事务被提前结束，后面的更新没执行。

解决方法是把业务逻辑全部放进事务，提交成功后再返回响应。具体说就是把投递记录写入、推荐记录更新、通知生成这三步都包裹在同一个DB::transaction()或 Laravel 的DB::transaction(function () {})里，任何一个环节失败都回滚，保证数据一致性。这类问题在联调时不容易发现，因为单次请求一切正常，高并发或者异常分支下才会暴露。

5.4 两套框架共存时的隐藏坑

这套系统在同一个服务器上同时跑 Laravel 和 ThinkPHP 时，碰到过几个挺隐蔽的问题。第一个是 session 配置不一样，Laravel 默认用文件存储，ThinkPHP 老项目用 redis 存储，导致同一个人在两套系统之间切换时需要重复登录，后来统一成 redis 存储，并把 session key 前缀区分开才解决。第二个是模型命名冲突，两个框架都有自己的User模型概念，如果代码里有依赖注入或者自动加载，容易互相干扰，处理方式是在 ThinkPHP 端给模型加上业务前缀，比如ResumeModel，避免类名冲突。

第三个是路由冲突，Laravel 的接口路由和 ThinkPHP 的模块路由如果同时部署在同一个 nginx 站点下，需要配置好location规则，把/api前缀的请求转发给 Laravel，其他请求转发给 ThinkPHP。这里还要注意，两个框架的入口文件不同，站点根目录需要做特殊处理，我当时遇到的情况是重写规则写错，导致 ThinkPHP 的请求全部被 Laravel 接管，页面全部 404。

6. 测试评估与实际落地心得

6.1 测试数据准备与推荐效果验证

做一个推荐系统，最怕的就是没有测试数据。我的做法是准备六十份模拟简历和一百二十个岗位，手工标注了每个岗位最匹配的三份简历作为标准答案。然后用推荐系统分别为这六十份简历生成 Top10 推荐列表，计算命中率：如果推荐 Top5 里出现了标准答案中的任何一份简历，就算一次命中。最终跑出的结果是 Top5 命中率在 71% 左右。

这个数据不算高，但真实场景里用户往往只浏览前五条，能保证前五条大部分时候有可以用的人，已经是可接受的水平。如果你追求更高的准确率，下一步应该引入协同过滤，就是根据招聘方的历史选择行为做相似岗位的推荐。但协同过滤要求有足够的投递和反馈数据积累，冷启动阶段不要指望它。

6.2 这个系统还可以怎么扩展

当前版本的核心是"把普通的数据匹配做成带有语义判断的推荐"，已经比单纯的检索高了一个层次。后续可以考虑的方向有三个：一是接入专业分词服务，解决中文分词精度问题；二是增加用户行为反馈，把点击、投递、拒绝、邀请面试全部记录下来，作为推荐排序的实时信号；三是把推荐引擎独立成通用服务，支持更多业务方向。这些扩展都不会推翻现在这套架构，因为核心的向量计算和规则融合逻辑是稳定的。

6.3 我的几个实操心得

最后说几条真正有价值的心得。第一，在 PHP 项目里做推荐系统，不要一上来就想深度学习，TF-IDF 加规则融合已经能覆盖大部分业务场景，先把基础做扎实比什么都强。第二，如果项目里同时有 Laravel 和 ThinkPHP，核心业务代码一定要解耦，不要跟框架绑定，否则维护成本成倍上升。第三，推荐结果一定要可视化地给出理由，这直接影响用户对系统的信任度。第四，性能优化不要靠猜，准备好简单的压测工具，对比数据说话。第五，分词词库是需要长期维护的资产，不是上线那天填完就不管了，每次发现推荐结果不合理，都应该回来补词库、调权重。

这套系统整体做下来，我的感受是：它并没有用到太高深的算法，但把所有环节串起来之后，解决的是真实业务里的真实问题。推荐系统能不能落地，关键不在于算法炫不炫，而在于数据整理得够不够干净、业务规则理解得够不够透。如果你正在筹备类似的系统，希望这篇文章能让你少踩几个我踩过的坑。