企业官网建设流程全解析

简介：这是一套2024年发布的资源牛知识付费系统开源版，覆盖微信小程序、PC端和H5公众号三端，数据实时互通，适合站长、培训机构和开发者快速搭建知识变现平台。系统内置DIY首页、卡密/图文/视频/音频/网盘等多类型资源、课程章节试看、社群付费加入、流量主广告、二级分销与代理分站等完整功能，并支持火车头自动采集文章，满足内容聚合与自动化更新需求。资源包共2000个文件，以js、ts、html、css等前端代码为主，搭配php后端接口、sql数据库脚本、md说明文档及jpg/png界面素材，整体165.41MB，目录结构清晰，便于二次开发定位。已有882人学习下载，更新至v3.5.6，新增移动端自定义专题、分类页样式、我的页菜单样式及代理SVIP套餐等配置，无论是直接部署运营还是研究多端知识付费系统架构，都具备较高参考价值。

1. 资源牛这类三端互通的知识付费系统，到底解决了什么问题

做知识付费系统遇到的第一道坎，通常不是课程内容本身，而是「用户会在哪个端买课」。想靠微信小程序承接流量，又要做 H5 方便分享裂变，还得有 PC 端让用户安安静静看长视频，三个端分开开发，时间翻三倍，账号和订单还容易对不上。2024 年前后，资源牛这类三端互通的知识付费系统开源版热度持续走高，核心原因就是它把「小程序 + PC + H5」统一到一套后端和同一套订单逻辑里：用户在手机上学到一半，换电脑可以接着看，已购课程、会员状态、学习进度都从一个库里取数。适合谁呢？中小机构、个人讲师、做内容分发和资源整理的团队。这类系统的价值不是省掉一个端，而是把账号、订单、课程进度这些最容易分家的数据，从一开始就焊在同一张表上。

2. 从标题拆需求：三端互通的知识付费系统由哪几块拼成

2.1 后端管理台：课程、订单、会员、采集入库的统一入口

标题里「PC + H5 + 小程序」只是前台的三个壳，真正的核心是后台管理台。无论哪一端下单、哪一端上课，最终都写进同一个数据库。这类开源版大多沿用 FastAdmin 或 ThinkPHP 体系的路由和表结构，前缀常见为fa_，实际项目命名可以改，但职责基本一致。核心表大致有如下角色：

从使用习惯上讲，我一般会先把后台的「课程管理」和「会员列表」两个页面跑通，再谈其他。因为三端的数据互通不是靠前端代码同步，而是靠后台这一张 course 表里不同端的展示字段——小程序首页展示的、H5 列表页展示的、PC 详情页展示的，其实是同一批数据。如果你拿到源码后第一件事是看前端页面，大概率会绕弯路，先看数据表结构和后台目录才是正路。

2.2 小程序端：微信生态的登录与支付闭环

小程序端是整个系统里最依赖微信生态的一环。很多人以为小程序端就是把 H5 页面套进小程序的 web-view，实际上这里有个硬约束：微信小程序里用web-view只能打开配置了业务域名的网页，而且 web-view 里的 H5 无法直接调用小程序的登录和支付能力。所以这套系统的正常结构是：小程序是原生或 uni-app 写的独立前端，通过wx.login()拿 code，后端拿 code 去微信接口换 openid，再用 openid 关联到fa_user表并签发 token。

支付闭环也要重点说：小程序内购买虚拟课程，微信官方要求必须走小程序内支付（而非 web-view 里的 H5 支付），并且 iOS 端对虚拟支付限制极多。很多此类开源版实际把小程序端支付做了「分类处理」——安卓走小程序支付，iOS 走客服引导或 H5 跳转。这是微信生态规则决定的，不是代码 bug，后面避坑章节会再展开。

2.3 PC 与 H5：同一套响应式前端，还是两套独立页面

标题里的 PC 和 H5 是两种使用场景，实现方式各有取舍。最常见的做法是：H5 端和 PC 端共用一套 uni-app 或 Vue 项目编译出来的前端，服务端只关心提供 API，前端根据设备宽度调整布局。听起来省事，但实际落地时你很快会碰到一个热词场景里常被问的问题——一套 H5 代码要能指向多个域名。

怎么理解？开发环境接口指向http://localhost:8080，测试环境指向https://test-api.example.com，生产环境指向https://api.example.com。所以请求层必须封装成一个可配置 baseURL 的模块，而不是把域名写死在每个页面里。另一条路是 PC 端用后台自带的模板引擎直接渲染，比如 FastAdmin 的默认前端，H5 再单独跑一个 uni-app 编译出来的包。两条路我都试过：团队懂 Vue 就选前者，维护成本低；想快速上线就用后者，但 H5 和 PC 的页面样式会出现轻微差异，需要接受。

H5 在微信内打开时还牵扯到分享。微信内 H5 想自定义分享卡片、标题和缩略图，需要后端做 JS-SDK 签名，也就是wx.config那段配置。很多开源版在文档里没写清，导致用户分享出去的是原始链接，卡片又丑又没有摘要，裂变效果大打折扣。这个签名接口建议后台预留好，不要等上线后临时加。

2.4 三端数据互通的本质：一套账号体系 + 一套订单状态机

把三端想象成三个遥控器，它们控制的是同一台电视。小程序通过 code2session 拿到 openid，H5 用手机号验证码或账号密码登录，PC 用扫码或账密登录，三者登录方式不同，但在fa_user表里对应的是同一个user_id。token 各自独立签发，服务端通过 token 反解出 user_id，然后课程进度、已购列表、钱包余额都按 user_id 去查。这就是三端互通的核心——不是把三个端的前端代码合并，而是让所有业务数据只认user_id。

订单状态机更需要统一。支付行为可能发生在小程序、H5 或者 PC 上，但订单状态一定要收敛成一套状态值，否则会出现「H5 已支付、小程序显示待支付」这种让客服崩溃的问题。

这里最重要的一条铁律是：支付成功状态只能由支付回调来写，前端页面轮询出来的结果只能用来刷新展示，不能当数据源。我看到有人偷懒，在小程序端拿到支付成功返回后直接 update 订单表，结果回调延迟时订单状态会回跳，后面排查起来非常痛苦。回调处理代码一般长这样：

// 支付回调统一入口，伪代码示意 public function notify() { $data = file_get_contents('php://input'); $result = json_decode($data, true); // 验签通过后，只做两件事：更新订单状态、给用户账户到账 $order = db('order')->where('order_sn', $result['order_sn'])->find(); if ($order && $order['pay_status'] == 0) { db('order')->where('order_sn', $result['order_sn'])->update(['pay_status' => 1, 'pay_time' => time()]); // 发放已购记录，往 user_course 表写入一条记录 db('user_course')->insert(['user_id' => $order['user_id'], 'course_id' => $order['course_id']]); } echo 'success'; }

这段逻辑里最容易被忽略的是那行user_course插入。很多人只改了订单状态，没给用户写入已购记录，结果订单显示已支付，但用户端课程列表里还是空的。三端互通很多时候不是被复杂的跨端问题卡住，而是这种基础数据联动漏了环节。

3. 把开源版跑起来：本地与服务器的部署步骤

3.1 环境选型：这套开源版的常见运行环境

拿到源码包后先别急着装，先确认运行环境。这类系统大多基于 PHP 生态，典型组合是 PHP + MySQL + Nginx，前端小程序部分需要 HBuilderX 之类的工具编译。环境版本有讲究：PHP 版本过高或过低都可能让后台白屏。比如 ThinkPHP 5.0 时期的老系统在 PHP 8.0 以上会报each()函数被移除之类的兼容错误，而新一点的采集插件可能又依赖 PHP 7.4 以上特性。

我建议直接按这套组合来准备环境：

本地开发我一般在宝塔面板里直接搭，省去手动编译 PHP 的麻烦。生产环境建议单独搞一台云服务器，不要用本地电脑长期对外提供访问，原因很简单：家庭宽带没有固定公网 IP，IP 一变，小程序request合法域名指向的服务器就失联了。

3.2 从源码包到后台能登录：安装目录与伪静态

部署的第一步是解压源码并确认目录结构。后台代码一般需要放在 Nginx 的网站根目录，前端资源会分成public、application或addons这些常见目录。拿到压缩包后在服务器上执行：

# 假设源码包已上传到 /www/wwwroot 目录 cd /www/wwwroot unzip ziyuan_niu.zip -d ziyuan_niu cd ziyuan_niu # 如果网站根目录是 public，需要把运行入口指向 public # 很多这类系统的入口在 /public 下，而不是根目录 ls -la cat README.md # 先看安装说明，确认是否要求把根目录绑定到 public

接着要配置伪静态。伪静态的作用是把index.php?s=/course/1这类地址转成/course/1.html，方便 PC 端 URL 更友好，也避免一些接口路由 404。Nginx 下常见的伪静态规则：

location / { if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?s=$1 last; } }

注意，伪静态规则不是写进代码里的，而是要在 Nginx 的站点配置里加，或在宝塔的「伪静态」设置里选择对应的框架模板。我踩过坑：后台登录页能打开，但点击登录后一直跳回登录页，排查了半天发现是伪静态没配，POST 请求的地址带上了多余的index.php前缀，导致路由匹配失败。

数据库导入是另一个高频卡点。在后台安装引导页面里填数据库名、用户名、密码，系统会自动执行install.sql或初始化脚本。如果自动安装失败，就手动导入预先准备好的 SQL 文件：

mysql -u root -p your_database < install.sql

导入完成后打开config/database.php或.env文件，核对数据库连接配置。注意确认表前缀是否和源码一致，很多系统默认是fa_，如果安装时填了另一个前缀，所有查询都会报「表不存在」。

3.3 小程序端接入：HBuilderX 导入与 appid 配置

小程序端如果基于 uni-app 开发，源码目录里会有一个manifest.json。在 HBuilderX 中导入整个前端目录，先改微信小程序配置，而不是直接点运行。需要改的地方只有两个：mp-weixin里的 appid，以及业务的接口域名。

{ "mp-weixin": { "appid": "wx1234567890abcdef", "setting": { "urlCheck": true }, "usingComponents": true } }

appid必须填真实的小程序 appid，测试号在真机预览时经常出现登录态异常。urlCheck在开发时可以先改成false跳过域名校验，但上线前必须改回true，并保证所有网络请求都指向已在微信公众平台配置过合法域名的地址。

接口请求封装建议单独抽一个request.js，把 baseURL 和环境变量集中管理：

const BASE_URL = 'https://api.example.com' export function request(path, data = {}) { return new Promise((resolve, reject) => { uni.request({ url: BASE_URL + path, method: 'POST', data, header: { 'token': uni.getStorageSync('token') || '' }, success: res => resolve(res.data), fail: err => reject(err) }) }) }

这里的关键点是 token 从uni.getStorageSync读取，因为小程序原生的 Storage 是持久化的，只要用户不删除小程序就不会丢。写死在代码里的 baseURL 是新手最容易犯的错——换环境就要重新打包，测试接口时改来改去极其痛苦。

3.4 H5 与 PC 的打包发布：同一套代码分端编译

uni-app 项目的优势在于 H5 和 PC 可以直接编译成静态文件丢到服务器。在 HBuilderX 里选择「发行 -> 网站-PC Web 或手机 H5」，生成一个unpackage/dist/build/h5目录，里面是纯静态的 HTML、CSS、JS 文件。把这个目录上传到服务器 Nginx 站点根目录即可：

# 上传编译后的 h5 目录到服务器 scp -r unpackage/dist/build/h5 root@server_ip:/www/wwwroot/ziyuan_niu/public/h5 # 给目录设置权限，避免 Nginx 读不到文件 chown -R www:www /www/wwwroot/ziyuan_niu/public/h5

如果 PC 端要有独立域名和独立布局，可以再配一个 Nginx server 块，把同一份 H5 代码指过去，然后在代码里通过 URL 判断返回 PC 版布局。这比维护两套前端代码省力得多。H5 端部署完成后，有一个小细节容易被忽略：H5 页面在微信内打开时，微信浏览器会缓存页面，改完代码用户看到的还是旧版。常见做法是在 H5 入口 HTML 里禁用缓存，或在静态资源链接上加版本号。

4. 资源采集入库：从采集到可售卖内容的全流程

4.1 采集任务的两种接法：定时脚本与后台手动触发

标题里的「支持采集资源」是这类系统吸引人的地方。技术实现上无非两种路线：一是服务器定时任务定时抓取，二是管理员在后台手动点击采集按钮触发。常见做法是两者结合——后台配置采集规则，生成定时任务。

# 每天凌晨 2 点执行采集任务 0 2 * * * cd /www/wwwroot/ziyuan_niu && php think collect >> /www/wwwroot/logs/collect.log 2>&1

php think collect是命令行入口，具体命令名要看源码里的定义。如果你改了采集脚本后 crontab 一直不生效，先手动执行一次这条命令，看日志里有没有输出。采集脚本最常见的两个问题是超时和内存溢出，抓取远程页面或视频信息时，网络慢一点整个进程就卡死，建议在采集入口写set_time_limit(0)并给 PHP 调大memory_limit。

4.2 采集到课程表的字段映射：别让脏数据直接入库

采集来的资源不能原样往fa_course表里塞。远程数据的字段命名和本地表结构往往对不上，比如对方的「价格」可能是字符串¥199.00，本地表需要的是数字19900（以分为单位）。在做采集逻辑时，要建立一个映射关系：

字段映射之后是数据清洗，最简单的做法是在插入前做一次过滤：

-- 插入前先清理同一资源来源的重复记录 DELETE FROM fa_course WHERE source_hash = :source_hash; INSERT INTO fa_course (title, cover, price, video_url, content, source_hash) VALUES (:title, :cover, :price, :video_url, :content, :source_hash);

source_hash是一个很值得加的字段，它通常是采集源 URL 的 MD5。没有它，同一个资源被定时任务采集两遍，库里就会出现两个一模一样的课程，用户端看到列表重复，后台订单也会串。每次采集时先按 hash 去重，再接插入逻辑。

4.3 视频与图片的存储策略：防盗链与跨端播放

采集来的图片和视频如果直接沿用远程链接，上线三天内大概率会出问题。最常见的是「防盗链」：源站检查了Referer，非白名单域名访问图片直接返回 403。小程序端请求图片时 Referer 往往为空或微信相关域名，最容易触发拦截。处理方案就一个字：转存。

转存到本地服务器的目录，然后把数据库里的图片地址替换成新地址。写一段简单的 PHP 转存函数：

function save_remote_file($remote_url, $save_path) { $ch = curl_init($remote_url); $fp = fopen($save_path, 'wb'); curl_setopt($ch, CURLOPT_FILE, $fp); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_REFERER, $remote_url); // 伪造来源，绕过部分防盗链 curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10); curl_exec($ch); curl_close($ch); fclose($fp); }

注意，CURLOPT_REFERER只能骗过最基础的防盗链，很多大站已经升级成带签名 URL，伪造也没用。更稳妥的策略是：采集时把图片下载到本地，视频则视体量而定——小体积课程视频直接传 OSS 对象存储，大体积内容建议用点播服务并开启转码。小程序对视频格式兼容性有限，avi、mkv这类格式在真机上基本没法直接播，采集时碰到这类链接最好标记为「不合法」自动跳过，或者走HLS(m3u8)转码流程。

4.4 采集的合规边界与内容质检：版权意识要前置

关于采集，技术讨论是中性行为，但内容合规必须由使用方自行把控。从一个站把别人的课程、文章、素材搬到自己平台售卖，涉及授权问题；我建议只采集你有权分发的内容，比如自己历史平台的备份、授权合作方提供的转授权资源、出版社或版权方明确允许转载的公开内容。开源版提供了采集能力，不意味着采集来的资源可以无边界地商业化。

内容质检建议走这几步：一是检查标题长度和封面是否为空，二是用命令探测视频链接是否真实可访问，三是对价格做范围校验。

# 批量检测采集后课程的视频链接状态，输出不可访问的 URL curl -I -m 10 -s -o /dev/null -w "%{http_code} %{url_effective}\n" $(cat video_urls.txt) | grep -v "^200" | head -20

这一步很重要。采集到的资源链接，源站随时可能删除或限流，课程卖出去以后才发现视频打不开，售后会很被动。高频做法是：上架前全量检测，上架后每天用定时任务抽查链接存活率，失效的课程自动下架并向已购用户发通知。

5. 三端联调与上线避坑清单

5.1 微信小程序：合法域名校验、虚拟支付审核与 iOS 限制

现象：小程序开发工具里接口请求正常，真机预览时所有请求全部失败，报url not in domain list。

原因：小程序真机环境强制校验request合法域名。开发工具里勾选了「不校验合法域名」所以正常，真机上这个开关不存在。而且域名必须是 HTTPS，不能带端口，HTTP 请求在小程序里直接非法。

解决：在微信公众平台「开发管理 -> 开发设置 -> 服务器域名」里把接口域名加进request合法域名；如果是 WebSocket 还要单独配 socket 合法域名。这里最容易漏的是：如果 H5 和接口不在同一域名，H5 页面里用web-view时还得在「业务域名」里配置，否则小程序内嵌网页白屏。

另一个坑是虚拟支付。现象：小程序端点击购买，安卓机上弹出微信支付正常，苹果手机上没有任何反应，或直接提示「无法支付」。

原因：微信对 iOS 端虚拟支付有明确限制，课程、会员、充值这类虚拟商品不允许直接走微信支付，审核阶段就可能被拒。

解决：iOS 端引导用户跳转 H5 支付，或走客服人工处理；部分开源版会把小程序端 iOS 的支付按钮改成「联系客服」，这是行业内通用做法，不是系统缺陷。

5.2 H5 与 PC 的跨域问题：CORS 不只是加一个响应头

现象：H5 页面在微信里打开正常，在浏览器里直接访问时报跨域错误，接口数据加载不出来。或者 PC 独立域名访问 H5 时，接口正常，但登录后刷新页面回到未登录状态。

原因：接口域名和页面域名不一致，浏览器拦截了跨域请求。登录态丢失则是因为 token 存在sessionStorage或localStorage中，不同域名互不共享。

解决：后端给接口加跨域响应头，Nginx 配置如下：

add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS, PUT, DELETE'; add_header Access-Control-Allow-Headers 'token, Content-Type'; add_header Access-Control-Max-Age 86400;

Access-Control-Max-Age 86400的意思是浏览器把预检请求的结果缓存 24 小时，减少频繁 OPTIONS 请求带来的性能损耗。另外，token这个自定义头必须在Access-Control-Allow-Headers里显式声明，否则带 token 的请求依然会被拦截。

5.3 三端订单状态不一致：为什么支付成功小程序还显示待支付

现象：用户在 H5 端支付成功，金额到账，但小程序端的订单状态一直是「待支付」，用户截图找客服理论。

原因：前端页面在展示订单时没有实时向后端查询，而是用了本地缓存状态。或者小程序端的订单列表接口没有把「已支付但未写入 user_course」的数据关联出来。更隐蔽的原因是我前面提过的：支付回调只更新了订单表，没有给用户写入已购记录。

解决：先按这个顺序排查。第一步，后端查看支付回调日志，确认回调到达且没有报错；第二步，查订单表pay_status是否已变成 1；第三步，查user_course表有没有这用户和课程的记录。三端页面展示的永远以服务端查询结果为准，不要在localStorage或uni.setStorage里存订单状态当数据源。如果排查后发现回调根本没到，那就是回调地址被微信支付调用失败——原因通常是回调 URL 外网不可达，或 HTTPS 证书链不完整。

5.4 升级系统版本后采集插件崩溃：表结构变化是头号杀手

现象：开源版发布新版，按说明覆盖代码后，后台能打开，但采集任务开始报 SQL 错误，甚至整个后台报 500。

原因：新版升级了表结构，可能给fa_course表增加了字段，而采集插件还在按旧字段名写入；或者 PHP 版本升级后，老代码里的某个函数已被移除。

解决：升级前先做两件事。第一，把fa_course、fa_order等业务表的结构导出备份，必要时整个库 mysqldump 一份。第二，升级后先执行一次采集任务的试跑，不要直接跑定时任务。SQL 报错时看 MySQL 日志定位到具体是哪张表哪个字段：

# 开启 MySQL 错误日志，升级后观察报错内容 tail -f /var/log/mysql/error.log

这类系统从开源社区拿到的更新包，升级说明里一般不细讲字段变更，手动对比新旧 SQL 文件里的ALTER TABLE语句是最可靠的方式。改完表结构后，记得清一下 Redis 缓存，很多后台的数据是通过缓存读出来的，缓存里还是旧结构，页面照样报错。

6. 上线后的验证方法与进阶玩法

6.1 用一笔测试订单跑通三端全链路

上线前我习惯专门做一次「三端一致性演练」，而不是只测登录。操作路径：小程序端找到课程并提交订单，但不要在小程序里支付，转到 H5 端完成支付，然后去 PC 端查看订单状态和课程播放权限。全链路验证的核心是确认订单状态、已购记录、课程进度三个数据在三个端完全一致。

验证完最后跑一条 SQL 做兜底核对：

SELECT COUNT(DISTINCT user_id) AS buy_users, COUNT(DISTINCT course_id) AS buy_courses FROM fa_order WHERE pay_status = 1 AND user_id = 10086;

返回的结果里买课用户数和课程数能对得上，才代表fa_order和user_course没有出现数据孤岛。这一步我每次上线都会做，数据源偏离比代码报错更隐蔽。

6.2 用日志做每日数据核对

上线后不要只看销售额，订单日志的完整性更重要。常见做法是把小程序、H5、PC 三个端的访问日志按用户维度打点，每天用命令筛查异常行为：

awk -F'[ =]' '{print $4}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

这是最粗糙的统计方法，但能快速看出有没有某个 user_id 订单异常聚集。支付回调日志里出现连续失败记录时，优先查证书和回调路由，不要反复让用户重新支付。

6.3 进阶：多商户、分销、会员卡与课程试看

这套系统的进阶空间比标题写的大。基于三端互通的基础架构，可以继续加多商户入驻——每个商家有自己的课程库和结算账户，平台抽成走已有的钱包体系；也可以加分销裂变，H5 页面在微信内分享时带上分享人 ID，小程序端通过 scene 参数实现渠道追踪。这些功能大多已经存在于成熟的生态里，不一定需要自己造轮子。

分销要重点测的是跨端链路：用户在 H5 分享出去的链接，小程序里打开能不能正确绑定上下级关系。很多分销插件只测了单端，三端互通后绑定关系丢了，佣金结算就乱账。

会员卡和课程试看配置相对简单：课程表加一个try_see_minutes字段，前端播放器根据用户是否已购来控制试看时长。小程序端播放器注意设置头部标题动态变化——试看状态下提示「试看 3 分钟」，已购状态下显示课程名，这个小细节能明显降低客服问询量。我自己的习惯是每次改完这些功能，第一件事就是重放一遍支付回调日志和分销绑定日志，确认跨端数据没有回流问题。这套系统的数据链路长，所有诡异问题最后都指向同一个答案：三端数据不互通不是前端 bug，而是后端数据源跑偏。把校验脚本做成上线必跑项，能省下一整年的排查时间。希望帮到你。

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