企业官网建设流程全解析

1. 为什么大学生找兼职需要一套"推荐系统"而不是"信息发布栏"

刚接到这个课题的时候，我第一反应是：这不就是做一个信息发布平台吗？套个小程序壳子，后端放个后台管理，学生登录进去刷列表，看到合适的岗位就报名，完事。但等我真去跟几个在校学生聊了一遍使用场景，才发现事情没那么简单。

大学生找兼职这件事，表面上是个信息对接问题，实际上是四五种不确定性的叠加：岗位是不是真实、时薪是否合理、通勤时间能不能接受、工作时间跟课表冲不冲突、去了之后会不会被放鸽子。信息发布栏只是把这些不确定性扔给学生自己消化，而推荐系统要做的，是在学生看到信息之前就把一部分冲突过滤掉，把匹配度更高的岗位优先推给他。这也是为什么哪怕技术不复杂，也值得用"推荐"的思路来做。

1.1 大学生兼职场景的真实痛点

我梳理了大概三十多份用户调研记录，发现学生端的痛点非常集中，基本可以归纳成下面这五类：

第一是渠道散。QQ群、学校公告栏、中介朋友圈、本地生活论坛、学长学姐口口相传，信息碎片化到让人崩溃。A同学跟我说过，他为了找个周末兼职，加了六个群，每天刷几百条消息，真正能投的没几个。

第二是信息真实度完全不可控。很多兼职信息是从本地中介转了好几手的，岗位描述写得很诱人，实际去了发现薪资缩水、工作内容对不上，有的甚至要交所谓的建档费、工牌费。

第三是匹配维度缺失。传统信息平台只有"按城市、按工资"两个筛选条件，但兼职最重要的三个匹配维度是时间、距离和技能。学生周一到周五上午有课，只能做下午或周末的岗位；很多学生没车，通勤超过四十分钟基本就不会考虑了；会PS、会写文案、会剪视频的学生，其实能胜任一些远程或线上兼职，却被线下岗位刷掉了。

第四是岗位生命周期混乱。一个招聘信息发出去之后，可能已经招满或者取消了，但平台还挂着，学生投了简历石沉大海。

第五是两端的信息不对称。企业招兼职也痛苦，经常出现学生报名了不来、到岗几天就离职的情况，所以企业端同样需要一个能筛出"相对稳定"候选人的工具。

这些痛点凑在一起，结论就清晰了：普通的信息发布栏解决不了核心问题，因为它的逻辑是"把岗位摆出来，让学生自己挑"，而现实中学生真正需要的是"系统先帮我过滤掉不合适的，再把剩下的按综合匹配度排好序"。于是这个项目定位就变了，不再叫"兼职信息发布平台"，而是"兼职推荐系统"。

1.2 从信息展示到双向匹配的转变

从技术上理解，信息发布平台只需要一张表：岗位表。用户来了就是查列表、看详情、留联系方式，后台管理员维护岗位上下架。但推荐系统需要的数据结构完全不同：

它需要建用户画像，要记录学生的空闲时间、所在位置、已有的技能标签、期望时薪、过往的报名和浏览行为。岗位也不再是一行干巴巴的文本，而是需要给时间、地点、技能要求、薪资范围、是否报销通勤等字段做结构化建模。录用状态也要有闭环：学生报名之后是否被查看、是否被录用、是否到岗、是否完成，这些状态反过来又成为推荐的反馈信号。

这个思路转变非常关键。前者后端的复杂度大概只要三张表，后者至少需要七八张表，并且需要设计一套打分逻辑把它们串起来。也因为这个转变，整个项目的技术选型和数据库设计方向全变了。所以先别急着写代码，先想清楚用户需要的是"看信息"还是"被推送合适的信息"。

2. 技术定稿记录：uniapp + PHP 的组合逻辑

技术选型这块，项目组当时讨论了好几轮。前端到底做原生微信小程序还是跨端框架，后端到底用 PHP 还是换 Java，都有争议。最后定下来的是前端 uniapp、后端 PHP、数据库 MySQL，整体跑在常见的 Nginx + PHP-FPM 环境上。这组技术栈在今天看起来不算新潮，但放在这个项目体量和团队条件下，确实是最稳的选择。

2.1 为什么选 uniapp 而不是原生微信小程序

让我先说结论：如果只针对微信小程序一个平台，原生开发完全够用，甚至性能更好；但如果你不确定后续是否要出 H5 版本或者安卓 App，uniapp 的复制成本几乎为零。

这个项目在规划阶段就被要求"小程序先上线，后续可能扩展 H5 和 App"，那踏实用 uniapp 是理性的。原因有几个：

第一是语法栈统一。uniapp 的页面结构基于 Vue 语法，写过 Vue 的同学几乎零成本上手。原生小程序用的是 WXML + WXSS + JS，写法上有自己的那套规矩，虽然有类似 Vue 的语法糖，但项目里如果有组件复用、混入（mixin）、全局状态管理等需求，原生写法写起来明显繁琐。

第二是组件生态有积累。uniapp 有自己的兼容组件库，比如 uni-ui，同时社区里大量第三方组件的兼容性做得不错。一个典型的例子是签名板、日历选择器这类组件，原生版本要自己调，uniapp 很快能找到现成的。

第三是条件编译可以处理多端差异。很多微信特有的 API 其实多端都有对应实现，uniapp 提供了条件编译能力，可以用#ifdef MP-WEIXIN这样的注释块针对微信平台微调代码，同一份代码保持一个主干。

但也要说实话，uniapp 的坑不是没有。后面我会专门讲几个开发中踩到的问题，比如图片上传、事件参数传递、组件样式隔离等，每个坑都能单独写一篇。如果你本身对原生小程序已经很熟，项目又确定只做微信端，没必要为了跨端而跨端。

2.2 PHP 后端在这个体量下是性价比最高的选择

后端选型时，有同事提议用 Java Spring Boot，理由是性能强、后续可扩展。我不否认 Java 的优点，但当时我问了三个问题：这个项目预估日活是多少？团队里谁会长期维护？部署环境是什么样？

答案很现实：小程序主要面向某一所高校周边，日活撑死几千人，峰值并发可能就一两百 QPS；团队维护者主要是熟悉 PHP 的开发者；部署服务器就是一台低配云主机。这种情况下用 Spring Boot 属于杀鸡用牛刀，光一个 JVM 的内存占用就把小服务器吃掉了大半。

PHP 在这个场景下的优势非常明显：开发效率高，改完代码刷新即生效，不用经过漫长的编译过程；生态成熟，PDO 预处理、MySQL 驱动、JSON 操作都是开箱即用的能力；运维简单，PHP-FPM 跑起来之后几乎不用管，对新手维护者压力小得多。

我当时选的是 ThinkPHP 框架，理由不是它比 Laravel 好，而是团队对此更熟悉，文档是中文的，出错排查资料多。这里顺带提一句，框架本身不是核心，核心是代码结构的清晰度和安全性意识，这个后文会展开。

2.3 最终技术栈一览

Redis 我们只用来存 token 和登录态，纯内存操作，连持久化都没开。这个项目里不需要缓存复杂数据，因为岗位数据变更频繁，缓存反而容易造成数据不一致，不如直接查库。

3. 数据库从零到一：最费心思的不是表数量，而是状态流转

设计数据库的时候，最让我纠结的不是建几张表，而是如何把"报名状态"和"岗位状态"这条链路捋清楚。一个兼职岗位从发布到关闭，学生会经历浏览、收藏、报名、被邀约、被录用、到岗、结算薪资这一整个流程，中间任何一个状态漏掉了，推荐系统的反馈信号就会失真。

3.1 核心表结构与字段设计的取舍

整个项目我们最终建了九张核心表：用户表、角色表、岗位表、报名表、收藏表、浏览记录表、用户标签表、岗位标签表、岗位评价表。这里不把建表语句全部贴出来，只挑几处关键设计说明。

用户表里有个字段叫user_type，用 1、2、3 分别表示学生、企业、管理员。当时纠结过要不要单独建三张表，后来决定合一张，因为三者的公共字段太多，分开会造成大量冗余。学生相关的扩展信息（学校、专业、年级、空闲时间偏好、通勤范围）单独建了一张student_profile表，一对一关联主用户表。这样逻辑上清楚，也能避免用户主表字段过多、索引膨胀。

岗位表是另一块重点。除了常见的 title、description、salary 之外，我加了这几个字段：

• work_date_type：区分固定时间（周几几点到几点）和弹性时间
• work_start_time/work_end_time：可空，配合课表做时间匹配
• longitude/latitude：岗位位置经纬度，用于距离计算
• need_count：招聘人数
• applied_count：已报名人数，这个字段后面会提到并发问题
• audit_status：审核状态，0 待审核、1 已通过、2 已驳回

岗位标签表做成中间表是比较常规的做法：job_id、tag_id、tag_name。之所以把tag_name冗余进去，是为了列表展示时省一次关联查询。查询频率高的小表，冗余字段换性能是值得的。

报名表的状态字段我专门设计了一套状态机，这个下面单独说。

3.2 状态流转：为什么不能只是存一个"已报名"

一开始的方案是报名表就存一个字段status，取值有 0 已报名、1 已录用、2 已完成。后来实际跑流程发现压根不够，因为学生报名之后中间还有很多节点：企业可能要先沟通意向，再决定录用与否；录用之后学生可能不去；去了之后干了一天觉得不合适，这些都算真实状态。

最终我把报名状态设计成了五个：

• 0：待沟通（学生报名，企业未处理）
• 1：已邀约（企业看过简历，愿意进一步沟通）
• 2：已录用（企业确认录用）
• 3：已完成（兼职工作完成，薪资结算）
• 4：已取消（任意一方取消，记录取消原因）

每个状态变更同时写入一张apply_log日志表。为什么必须加日志？因为推荐系统要把"报名后是否完成"作为岗位质量和学生稳定性的重要反馈信号。如果没有日志，这些历史数据全丢了，后续做任何分析都无从谈起。

岗位状态也有自己的流转：0 草稿、1 待审核、2 已上架、3 已下架、4 已关闭。这里有个容易忽略的细节：企业端修改岗位信息后，不是直接更新到线上，而是把状态重置为 1，重新走一遍管理员审核。兼职信息最怕的就是审核之后企业偷偷把薪资改成离谱的值，这个规则能兜底。

3.3 建索引时踩过的性能教训

开发初期表里数据没几条，索引优化完全没在意，直到测试阶段导入了一批模拟数据，列表页响应开始变慢。用慢查询日志排查发现，瓶颈不在查询条件，而在ORDER BY created_at DESC配合WHERE status = 2时没有复合索引，MySQL 需要先过滤再排序，数据量大一点就吃力。

后来加了(status, created_at)复合索引，类似问题直接消失。这个案例想说明一个道理：小项目也值得提前考虑索引设计。推荐排序的时候经常跟着WHERE status = 2 AND tag_id = xxx这种条件，复合索引不是越多越好，但跟排序、过滤强相关的字段，建索引绝对不亏。

另外时间戳字段我全部用的是datetime而不是int类型，虽然 int 计算效率略高，但可读性差太多，调试的时候谁也不想看到一串 1700000000 自己去换算。这个项目规模下，datetime的性能差异完全可以忽略。

4. 兼职推荐的核心逻辑：标签权重、距离系数与冷启动

推荐算法是这套系统最核心、也是最有可讲空间的部分。不过先说一句，我们做的不是那种动辄深度学习的推荐系统，而是用规则权重打分的方式，把合适程度量化出来。对于这种体量的兼职场景，已经足够了。如果你非要引入协同过滤加用户向量，不说离线算力，单是实时响应都容易把服务器拖垮。

4.1 为什么不能只按发布时间排序

如果只要"最新发布"，那推荐系统就没有存在的必要了。但我们要处理一个现实问题：同一个岗位，对一个周一到周五上午满课、住在学校北区、会剪视频的学生，和一个每天都有空、住在市中心、只想做体力活的学生，意义完全不同。

所以推荐打分的核心思路是：把学生需求和岗位属性做结构化匹配，然后按匹配程度打分排序。不需要把所有维度都算得很精细，抓住三个核心维度就够了：技能标签匹配、时间适配、距离适配。这三个是决定学生愿不愿意点的关键因素。

4.2 匹配度打分公式：可落地的那种

最终我们采用的打分公式是：

score = 标签匹配分 * 0.45 + 时间适配分 * 0.3 + 距离适配分 * 0.2 + 热度分 * 0.05

四个维度分别说明一下。

标签匹配分：把学生的技能标签和岗位要求标签做交集对比，再用交集标签数除以岗位标签总数。比如岗位要求三个标签，学生命中两个，得分就是 0.67。如果岗位没有任何标签要求，默认给 0.5 的保底分，避免无标签岗位永远排最后。

时间适配分：这是个稍微复杂的计算。如果岗位是弹性时间，直接给 1 分。如果是固定时间，要和学生设置的"空闲时间段"做重叠判断。我设计了一个简单的重叠算法：获取学生一周内每个可兼职时段，和岗位时间逐一比对，算出能覆盖的最小时间跨度，覆盖率超过 80% 给 1 分，低于 30% 给 0 分，中间按比例线性取值。

距离适配分：用高德地图或百度地图的经纬度距离计算接口算出直线距离。学生设置一个最大通勤距离偏好，岗位距离在偏好范围内给 1 分，超出 1 公里扣 0.2 分，超出 5 公里以上直接排除。

热度分则是一个简单的衰减因子：用岗位近 7 天的报名人数除以往期平均值，再加一点发布时间衰减。这个维度权重最低，只是用来打破同分排序的僵局。

整个打分在查询时直接计算，不需要预先存好。因为岗位数据量维持在千级以内，哪怕是全表扫一遍做内存排序，性能也完全可以接受，就没必要引入复杂的推荐引擎或搜索中间件。

4.3 冷启动问题：新用户没有行为数据怎么办

推荐系统最怕的就是新用户，点开小程序什么都没有。现在的行业叫"冷启动"，我们处理的办法很直接：注册流程里加了偏好问卷。

学生在完善资料的时候，需要勾选自己可兼职的时间段、通勤范围上限、感兴趣的技能标签，以及期望时薪范围。这些数据直接作为初始画像参与打分。虽然用户可能随意勾选，但至少有个起点，比完全空白强多了。

后续通过行为反馈不断修正画像：学生浏览了某个岗位，这个岗位的标签权重加一点；收藏了，权重加更多；报名了，再次加分；报名后取消，相关标签减分。岗位端的反馈信号则是：录用的学生最后完成度如何，如果这个岗位连续出现录用后放鸽子的情况，岗位热度分会下降。

4.4 推荐效果怎么验证

推荐做完了不能喊口号，得看数据。我们用了两个很粗但有效的指标：曝光到点击的转化率，以及报名到录用的转化率。

上线初期通过埋点统计，发现默认排序下岗位点击率大概是 11.6%，启用推荐打分后提升到 17.2% 左右。报名转化率提升倒不算明显，因为受岗位本身吸引力和薪资影响大，但从统计数据上看，推荐位置靠前的岗位，学生取消报名的比例下降了约五分之一。这说明推荐逻辑确实筛掉了一部分"看上去不太合适"的岗位。

这里我建议每个做推荐系统的团队都搭一个非常简易的数据统计后台，不需要多高级，就是每天记录各页面的曝光量、点击量、报名量，然后后台做个按天聚合的报表。没有这个数据，你永远不知道推荐到底有没有在起作用。

5. 小程序端开发实录：登录、列表渲染和那些能写进简历的坑

小程序端的具体开发过程，可以挑三个点详细说说：登录流程、分页渲染、以及我在实际编码时踩过的几个典型坑。这几块内容覆盖面比较广，既有业务逻辑，又有前端性能和兼容性问题，是整个小程序端最值得记录的部分。

5.1 微信登录与 token 体系：别在 session_key 上栽跟头

微信小程序的登录流程看起来简单，背后还是有几个需要注意的细节。

我采用的标准流程是：小程序端通过uni.login获取临时code，把code发送到后端接口，后端拿着code调微信的code2Session接口，换取openid和session_key。然后后端自己生成一个自定义登录态token（例如用 user_id 加盐生成一个随机字符串），存储到 Redis，设置过期时间，返回给前端。前端之后的所有请求都在Authorization请求头里带上这个 token。

这个流程有两点容易出坑。

第一，session_key千万不要返回给小程序端，也不要在前端存储。它应该只在后端使用，用于后续解密敏感数据。很多人第一版图省事，直接把 session_key 扔给前端，这是安全隐患。第二，token 的有效期要设计合理。我的方案是设置 7 天有效，前端每次请求时检查本地 token 的过期时间，剩余不足一天就静默重新走一遍登录流程。这样学生不会频繁被踢出登录态，也不会让 token 长期有效导致安全问题。

还有个编码细节：uni.login拿到的 code 有效期是 5 分钟，所以后端要及时处理。实际测试中偶尔会出现 code 失效的报错，一定要在后端做错误捕获，返回一个明确的提示让前端重新获取 code，而不是直接 500。

5.2 列表页的分页性能优化：从卡顿到流畅的调整

兼职列表页是最核心的页面，滑动流畅度直接决定用户体验。刚开始我们直接一次性把数据全部返回，岗位表数据一多，页面就开始卡，内存占用也高。

后来改为分页加载：每页 10 条，下拉到底触发onReachBottom加载下一页，同时加了加载状态避免重复请求。这里有一个被很多新手忽略的问题：在微信小程序里，onReachBottom触发条件依赖页面滚动位置，但如果列表数据不满一屏，它永远不会触发。所以我判断"可以加载下一页"的逻辑是数据条数不小于每页数量才继续请求，否则直接显示到底了。

为了进一步增强流畅度，我给列表页加了两个优化：一是图片懒加载，岗位封面图用<image>组件的lazy-load属性，首屏只加载前两三条的图片；二是列表项组件化，避免每次 setData 都更新整页数据。用过原生小程序的都知道 setData 是大开销操作，uniapp 虽然做了优化，但核心原理没变。

5.3 实际踩过的坑：域名白名单、富文本渲染和组件库兼容

这三个坑我每个都写了笔记，这里展开说一下。

第一个坑是域名白名单。开发阶段在微信开发者工具里勾选"不校验合法域名"一切正常，一到真机预览就全部请求失败。因为真机模式下所有网络请求必须走 HTTPS，且域名必须在微信公众平台后台配置白名单。上线前记得提前配置好服务器域名的 SSL 证书和业务域名，国内服务器还必须完成备案，这个环节非常容易卡进度。

第二个坑是富文本渲染。岗位描述往往包含换行、列表、加粗等格式，直接用<view>渲染的话换行和缩进会丢。uniapp 的rich-text组件可以解析 HTML，但对img标签的图片尺寸控制和事件绑定都不太理想。我的方案是后端做一次清洗，把富文本内容转成 JSON 结构化的描述块，比如段落、图片、标题三种类型，前端直接用普通组件按类型渲染。开发量多一点点，但稳定性和样式可控性完全不在一个级别。

第三个坑是第三方组件库的兼容问题。我们用了某个流行的 UI 组件库，在 H5 上跑得挺好，一到微信小程序就有样式丢失问题。原因是小程序对 CSS 选择器的支持跟 H5 有差异，部分 scoped 样式、flex 布局的兼容参数在小程序里表现不同。最后解决方式是升级组件库到微信端兼容版本，同时手写了一批关键页面的样式。这提醒我一件事：跨端框架不是银弹，用第三方组件前最好先确认目标平台兼容表。

6. PHP 后端的接口规范与并发安全的实测调整

后端部分看起来是纯增删改查，但接口设计、安全防范和并发问题这三块非常值得认真对待。一个兼职推荐系统，后端如果出问题，轻则数据错乱，重则学生隐私泄露，所以在编码阶段就要把底线守好。

6.1 统一返回结构和异常处理

所有接口统一返回 JSON 格式：code、message、data 三个字段。code 为 0 表示成功，非 0 表示业务错误码。比如 1001 表示参数错误、1002 表示未登录、2001 表示岗位已下架等。这样小程序端只需要在拦截器里统一判断 code，不用每个接口单独处理错误。

异常处理这里要特别强调：后端代码一定要有一个全局异常捕获器，把所有内部异常统一包装成"系统繁忙，请稍后重试"，不要把具体的 SQL 报错、文件路径等敏感信息暴露给前端。曾经在测试阶段，某个接口的数据库连接配置报错，异常信息直接返回到了前端控制台，这要是上线了，算是信息泄露事故了。

分页参数我统一用 page 和 pageSize，返回结构固定为：

{ "code": 0, "message": "success", "data": { "list": [], "total": 200, "page": 1, "pageSize": 10, "hasMore": true } }

6.2 PDO 预处理与 SQL 注入防御

PHP 操作 MySQL 的唯一正确方式是 PDO 预处理语句。这个项目中有个高危点：列表搜索和筛选条件往往由前端传过来，如果直接用字符串拼接，SQL 注入风险极高。

举个例子，学生端按区域搜索时前端传一个region_id，后端代码如果写成：

$sql = "SELECT * FROM job WHERE region_id = " . $_GET['region_id'];

那么请求参数里放一个1 OR 1=1，整个岗位表就全暴露了。改成 PDO 绑定参数后：

$stmt = $pdo->prepare("SELECT * FROM job WHERE region_id = ? AND status = 2"); $stmt->execute([$regionId]);

不仅防注入，执行计划也能被 MySQL 复用，性能反而更好。

6.3 报名名额扣减的并发问题：从"先查再改"到"条件更新"

这个坑是我觉得整个后端开发里最有价值的技术点。岗位表里有个need_count（招聘人数），学生报名时要判断是否已招满。最直观的写法是：

先查询当前报名人数，判断小于招聘人数，再执行插入报名记录，最后更新报名人数。

这在低并发下完全没有问题，但一旦两个学生同时在同一个瞬间报名，就会发生超卖：两人都查询到还有名额，然后都插入成功，最终报名人数超过招聘人数。

解决方案是使用条件更新或者行锁。我的方案是在事务中先对岗位记录执行一个带条件的更新：

UPDATE job SET applied_count = applied_count + 1 WHERE id = ? AND applied_count < need_count

如果rowCount()返回 1，说明扣减成功，再插入报名记录并提交事务；如果返回 0，说明名额已满，回滚事务并提示学生。这样就把判断名额和扣减名额合并成一条原子操作，从根源上避免了竞态问题。

后来模拟并发测试时，用脚本同时发起 50 个报名请求，招聘人数设置为 10，最终报名成功数稳定是 10，没有一个超卖。

6.4 日志与排错体系

后端排错最重要的就是日志。项目里我把日志分成三类：请求日志、错误日志、慢查询分析日志。请求日志记录每个接口的入参、出参、耗时和状态码；错误日志记录全局异常；慢查询则用 MySQL 自带的慢查询日志功能，超过 200 毫秒的 SQL 全部记录。

线上排过几次问题，基本都是靠这三类日志组合定位的。比如有段时间某接口在晚上八点之后响应特别慢，查了请求日志发现是某个小区块的搜索条件组合没建索引，再结合慢查询日志确认了具体 SQL，前后半小时就修复了。

另外，所有登录态相关的日志，严禁记录 token 明文和 openid，这是隐私底线。日志中如果非记不可，也要做脱敏处理，只保留前几位和后几位。

6.5 数据审核与信息治理：技术之外的一把手

最后谈一点整个项目上线后我感受最深的：兼职推荐系统最难的其实不是技术，而是数据治理。

学生兼职这一行，信息质量参差不齐。有冒充正规企业的，有薪资虚高的，有让学生先交押金的。技术系统能做的是在流程上加审核机制：企业注册需要营业执照信息，岗位发布先经过管理员审核再上架，学生提交评价后岗位分数实时变化。但这些机制都只是辅助，核心还是靠运营人员持续的把关。

我在项目里额外加了一个功能：学生端看到某个岗位评价差、疑似虚假信息时可以一键举报，举报数量达到阈值后岗位自动下架并通知管理员复核。这个功能是从电商平台学的思路，做出来之后确实有用，至少帮我们处理了不少异常岗位。

如果你也要做类似的信息平台项目，我建议把数据审核模块当成一等公民来设计，而不是上线后补丁式地加。因为一套从源头审核、过程监控到事后处置的闭环，远比单纯依赖人工审核要可靠得多。

这个项目从立项到跑通，前后花了大概一个半月，整体体量对我来说不算大，但各个环节都走了一遍，收获反而很多。如果你正在做一个类似的校园场景小程序，希望你也能从这些经验里少走几步弯路。