简介：这套源码实现微信群二维码的活码生成与管理，核心解决群二维码过期、扫码次数受限需频繁更换的问题。当原码失效时，系统可自动切换到新二维码，适合社群运营、线上活动、品牌营销等长期引流场景。部署环境需PHP5.6并安装sg11扩展，执行新装后填写激活信息即可使用，技术门槛不高。资源包共2000个文件，包含585个PHP核心逻辑、254个HTML页面、247个JS脚本与132个CSS样式，另有GIF、PNG等图片素材及SQL数据库脚本，覆盖前端展示、后端处理与数据存储，整体压缩包约21.43MB。当前已有181人学习下载。这份源码提供完整可运行的活码系统，含数据库初始数据与清理脚本，后台支持二维码规则配置，便于二次开发或直接部署。对需要稳定群引流入口的运营者或PHP学习者均具参考价值。
1. 微信活码到底是什么:先解决「群二维码总失效」这个日常难题
微信群二维码 7 天就过期、群满 100 人就扫不进去,这是做社群的人几乎每天都要骂一次的事。微信活码系统这套源码,本质上是把「一个稳定不变的二维码入口」和「后端动态跳转」拼在一起:物料上印的码永远不变,用户扫完之后由服务器决定把他带去哪个群、哪张二维码、哪个链接。运营不用再反复生成群二维码、重印传单,开发者也不用每次换群就重新发一次渠道包。适合谁:社群裂变、线下地推物料、多群流量承接的运营,以及想快速搭一个内部二维码管理后台的 PHP 开发者。这套 zip 源码正好覆盖「二维码生成、后台管理、跳转控制」三段,下面我按拆包落地的顺序把它讲透。
2. 动态跳转原理与源码结构:扫码后的那 200 毫秒发生了什么
2.1 活码与固定码的分水岭:壳不变、指向变
固定二维码的逻辑很简单:码里面直接存了一段内容,比如群二维码图片的 URL 或者微信号。微信生成群二维码时,给的是一个有效期只有 7 天的临时链接,图片印到物料上那一刻,倒计时就开始了。7 天一过,扫码只看到「该二维码已过期」,流量当场断掉。
活码系统把这段逻辑反转了:印刷品上的二维码指向你自己的服务器,码里面存的是类似https://你的域名/api/scan?code_id=12这样一个地址。用户扫码后,请求来到服务器,服务器根据code_id去数据库查这条活码当下的状态:是启用中、已停用、还是到期了。如果正常,就返回一个 302 跳转,把用户带到你最新配置的目标地址;如果停用或到期,就输出一个提示页。
这套机制的关键收益有两点。首先是「换码不换物料」:群二维码到期了,你在后台把target_url换掉,印刷品一个字都不用改;其次是「可统计」:因为每次扫码都先经过你的服务器,扫码时间、设备、IP 都可以记下来,这是固定二维码完全做不到的。微信官方自己也有带参数的二维码接口,但那是服务号能力,而且换参数就要重新生成码。活码系统把这一层封装成了人人可用的后台,不再依赖每次改代码。
2.2 源码包结构:后台、接口、安装脚本各管哪一段
我拆过几个同类 PHP 活码包,目录划分基本是同一套思路。这份源码解压之后,核心结构大致如下:
| 目录 / 入口文件 | 职责说明 |
|---|---|
/install | 安装向导,检测环境、写入数据库配置,安装完生成锁文件 |
/admin | 管理后台,登录、活码列表、新增编辑、二维码上传 |
/api | 扫码跳转接口,也就是用户扫码后真实请求的入口 |
/data | 运行配置、缓存文件,通常需要可写权限 |
/upload | 上传的群二维码图片、物料图存放目录 |
api下面的入口文件是真正干活的角色。用户扫码后命中的就是它,它要做三件事:接收code_id参数,查数据库,然后决定返回 302 还是提示页。admin后台则是给运营用的,负责把code_id和目标 URL 之间的映射关系维护好。install只在第一次部署时起作用,装完建议直接删除或者加锁。
拿到任何一个活码包,先别急着配环境,先把目录结构过一遍。重点确认三件事:入口文件在哪、数据库配置写在哪个文件里、上传目录是不是需要有写权限。这三件事在部署阶段坑最多,后文避坑章节会展开讲。
2.3 数据库表设计:活码状态机与扫码记录
活码系统的核心数据模型不复杂,两张表就能讲清楚:一张存活码本身,一张存扫码日志。常见的建表语句类似下面这样:
CREATE TABLE `live_code` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(64) NOT NULL DEFAULT '' COMMENT '活码名称', `target_url` varchar(255) NOT NULL DEFAULT '' COMMENT '跳转目标地址', `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '1启用 0停用', `expire_at` datetime DEFAULT NULL COMMENT '到期时间', `create_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `scan_log` ( `id` int(11) NOT NULL AUTO_INCREMENT, `code_id` int(11) NOT NULL COMMENT '活码ID', `ua` varchar(255) DEFAULT NULL COMMENT '扫码客户端 User-Agent', `ip` varchar(64) DEFAULT NULL COMMENT '客户端IP', `scene` varchar(64) DEFAULT NULL COMMENT '场景值', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;字段设计是理解这套源码的钥匙。live_code表里最关键的不是name,而是status和expire_at的组合:跳转接口每次被请求时,都要先判断状态是否启用、当前时间是否在到期时间之前。这两个字段共同构成了活码的状态机——启用中、已停用、已到期。scan_log表则是为统计预留的,scene字段在进阶场景分流时非常有用,后面我会专门演示。
两张表配合起来,整个系统的数据流就是:用户扫码 → 请求带上code_id→ 查live_code→ 写一条scan_log→ 返回跳转。理解了这个链路,后面部署、排错、改造都有方向。
3. 把系统跑起来:PHP 环境、伪静态规则与安装配置
3.1 环境选型:为什么这类源码大多跑在 PHP + MySQL 上
活码系统源码以 PHP 为主,这不是偶然。PHP 的部署门槛低、虚拟主机兼容性好,而且这类源码通常是从 LNMP 时代一路迭代过来的,对 PHP 7.x 的兼容性最稳。MySQL 负责存活码和日志,标配 InnoDB 引擎就行。
我一般会在本地用 PHPStudy 或者宝塔面板这类集成环境来跑,省去手动配php.ini的功夫。需要注意 PHP 版本选择:常见做法是选 PHP 7.2 到 7.4 之间的版本。这套源码如果是在 5.6/7.0 时代写的,放到 PHP 8.x 上很容易因为mysql_*函数移除、each()废弃这类兼容性问题直接白屏。先看包里的说明文件写的要求版本,没有说明的就按 7.3 起步试,这是最稳妥的路线。
部署前还要确认两个扩展:pdo_mysql和curl。前者是数据库连接的基础,后者用于生成二维码时调外部接口,缺了会在安装环境检测那一步直接标红。
3.2 Nginx 伪静态规则与目录权限
活码系统里很多地址是带参数的路由,比如/api/scan/12这种形式,如果不配伪静态,访问就会 404。Nginx 下常见做法是这么配的:
server { listen 80; server_name huo.example.com; root /var/www/huoma; index index.php index.html; location / { if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?s=$1 last; } } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~* \.(jpg|png|gif|ico|css|js)$ { expires 30d; } }Apache 环境下则是在站点根目录放.htaccess:
<IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?s=$1 [QSA,L] </IfModule>伪静态规则的s=$1参数名不是标准,取决于源码入口是怎么解析路由的。有的包用 PATH_INFO,有的用$_GET['s'],配完后用带参数的路径实测一下,别只测首页。目录权限方面,data和upload目录一般需要写入权限:
chmod -R 755 /var/www/huoma chmod -R 777 /var/www/huoma/data chmod -R 777 /var/www/huoma/upload严格来说,777在生产环境不是好习惯,但你刚开始在本地跑,为了绕过权限导致的安装失败,先这样处理是最省时间的。
3.3 安装向导:配置项逐一说明
环境准备好之后,安装流程基本是走一遍向导。访问http://你的域名/install,然后按步骤来:
- 环境检测:确认 PHP 版本、扩展、目录权限全部通过;
- 填写数据库信息:包括数据库主机、端口、库名、用户名、密码;
- 设置管理员账号和密码,此账号用于登录后台;
- 安装完成,生成
install.lock,防止重复安装。
安装过程中最常见的三个配置项,建议按下表理解:
| 配置项 | 常见值 | 说明 |
|---|---|---|
| 数据库主机 | 127.0.0.1 | 本机部署写 localhost 也可以,但注意 PHP 7 之后localhost和127.0.0.1在连接行为上有差异 |
| 数据表前缀 | live_ | 同库跑多个系统时用来隔离表,单个系统默认即可 |
| 管理员密码 | 不少于 8 位 | 后台关系整个活码体系,泄露等于所有跳转全部失守 |
装完之后,建议把install目录删掉或重命名。留着它在生产环境意味着任何人都可以重新触发安装流程,把数据库配置覆盖掉,这是活码系统最容易被人忽略的安全口子。
4. 从固定码换到活码:后台建码、群二维码替换与公众号绑定
4.1 创建一个活码:后台字段与跳转逻辑
后台登录之后,新增一条活码时会看到几个字段:名称、跳转地址、有效期、状态。名称是给你自己看的,方便识别是哪条渠道;跳转地址才是核心。最常见的写法,是直接把微信临时群二维码的链接填进去。
微信后台生成群二维码后,会得到一个类似https://weixin.qq.com/r/xxx的短链,这个短链就是target_url。用户扫活码,你服务器的接口返回 302,浏览器自动跳转到这个微信短链,微信再拉起群二维码展示。链路是两层跳转,但对用户来说感知只是一次扫码。
创建完活码,你可以先用命令行验证接口是否正常:
curl -I "https://你的域名/api/scan?code_id=12"正常情况会看到类似这样的输出:
HTTP/1.1 302 Found Location: https://weixin.qq.com/r/xxxx如果返回的是 200 而不是 302,说明源码的跳转逻辑不是重定向,而是直接输出一个展示页。这两种模式各有取舍:展示页可以在扫码后先出一个中间页,给用户一句欢迎语再引导进群,转化数据更好看;直接 302 链路短、体验顺滑。看你运营上的偏好,不用纠结。
4.2 上传微信群二维码:替换物料而不换活码
活码系统的日常操作,不是反复建新码,而是反复改target_url。具体流程是这样:微信群二维码到期了,进微信群设置,重新生成一张新的群二维码,下载图片或复制链接,回到活码后台,把这条活码的跳转地址更新掉,保存。
这里有一个容易踩的认知误区:有人直接把微信群聊里那张二维码截图上传当新码用。群里展示的二维码是一个快照,不代表最新的进群凭证。正确做法是每次去微信群设置里点「生成新的群二维码」,把最新生成的那个链接或图片回填到后台。群满 100 人之后,旧群的二维码即使没过期也进不去了,这时候要开新群、新码,然后把所有渠道的活码一次全部指向新群。
换码之后,拿手机扫一下旧的印刷物料确认,这时候二维码没变,但进的是新群,整套换血动作就完成了。这个操作习惯如果团队里每个人都遵守,运营就不需要等用户扫码发现失效了再补救。
4.3 接入公众号菜单与自动回复
活码系统除了印在物料上,还有一个常见接法:放到公众号的菜单栏或自动回复里,让用户点菜单直接进群。以自动回复为例,用户在公众号后台回复「进群」,公众号服务器把这条消息转发给业务后台,你的接口返回一条图文消息:
// text 消息回调处理,命中关键词时返回图文消息 if ($keyword === '进群') { $result = [ 'title' => '扫码加入交流群', 'description' => '群名额有限,先到先得,若提示已满请联系管理员', 'url' => 'https://你的域名/api/scan?code_id=12', 'picurl' => 'https://你的域名/upload/cover.jpg', ]; // 组装成微信要求的 XML 结构返回 }这里的url就是活码接口地址,用户点击图文消息后会先经过你的服务器,再被跳转到微信群二维码。这个接法的好处是,你可以随时换群而不需要重新发文章、改菜单。需要注意公众号类型:订阅号菜单里可以放普通链接,但涉及网页授权的接口能力,需要认证服务号才能完整使用。
5. 避坑指南:部署与运营里的五个典型翻车点
5.1 部署安装期:两个高发问题
坑一:安装过程中直接白屏,或者首页打开了但后台登录页全是乱码。
现象:访问/install页面一片空白,或者安装完成后打开后台,文字显示成 � 这样的乱码。
原因:大概率是 PHP 版本不兼容,老代码在 PHP 8.x 上碰到被移除的函数直接 fatal error,而错误显示没开,只能看到白屏;乱码则是文件编码问题,常见是编辑器把文件存成了带 BOM 的 UTF-8,输出内容的时候 BOM 被当成字符发到了页面。
解决:先切 PHP 版本,7.2 到 7.4 之间轮着试;然后打开php.ini里的display_errors临时开成On,把真实报错逼出来。文件编码问题,用 VS Code 打开首页文件,点右下角编码,选择「通过编码重新打开」,确认是UTF-8 without BOM后另存一遍。
坑二:首页能开,后台里点任何一个功能链接都是 404,或者伪静态样式彻底失效。
现象:/admin能打开登录页,但登录之后跳转到/admin/index.html就 404。原因基本是伪静态没有真正生效:Nginx 下 rewrite 规则没加载,Apache 下AllowOverride默认是None,.htaccess根本没被读。
解决:Nginx 就把location /那段 rewrite 配好,然后nginx -t验证配置再 reload;Apache 则去站点配置里把AllowOverride All打开,重启服务。改完别只在浏览器看,用curl -I "https://域名/admin/index.html"看一眼返回码,确认是 200 再继续。
5.2 运营使用期:三个高发问题
坑三:手机扫码后打开一个空白页,或者提示「无法验证服务器身份」。
现象:PC 上访问接口一切正常,手机微信里扫码就白屏,有的机型还会提示安全风险。
原因:两个方向,一个是域名没配 HTTPS,微信内置浏览器对 http 链接有限制;另一个是跳转目标本身是微信内部短链,微信会要求发起跳转的域名先加入公众平台的「业务域名」白名单,否则拦截。
解决:给活码域名配 SSL 证书,把target_url全部改成 https;然后登录微信公众平台,在「公众号设置 → 功能设置 → 业务域名」里把活码域名加进去,下载校验文件放到站点根目录,完成验证。
坑四:活码的二维码还在,但扫进去提示「群二维码已过期」,运营完全无感。
现象:用户反馈进不了群,去后台看活码状态还是启用中,跳转地址也没改。
原因:target_url指向的还是上次那张临时群二维码,微信那边的链接早到期了,活码不知道自己引用的链接已经失效,它只会按配置跳转。
解决:把群二维码替换动作做成例行事务,每周一检查一遍所有活码,点开跳转路径看一眼是不是最新链接。如果群里二维码是 7 天有效期,就把提醒周期设为 5 天,提前处理,不要等用户来骂了再补救。
坑五:后台统计里扫码量几乎为 0,但业务明显有进群。
现象:scan_log表数据稀疏,一天才几条,而实际上几百人进群了。
原因:一部分是 CDN 或浏览器缓存劫持了扫码请求,302 被命中后,后面的请求根本没到源站;另一部分是跳转接口里日志写在重定向之后,程序早就 exit 了,日志压根没执行到。
解决:把「写日志」放到「执行跳转」之前,先记录再header('Location: ...');另外对于活码接口路径设置不缓存规则,或者在接口 URL 上带一个版本参数,绕过 CDN 缓存。
6. 进阶玩法:给活码加场景分流与访问统计
活码系统跑顺之后,下一步值得做的就是场景化。同一张印刷码,线下海报和线上公众号推文的用户质量不一样,但默认情况下它们都进同一个群,数据也混在一起。要做分流,只需要在跳转接口里多读一个scene参数:
$codeId = (int)($_GET['code_id'] ?? 0); $scene = trim($_GET['scene'] ?? ''); // 先写日志,再跳转,顺序不能反 $stmt = $pdo->prepare( 'INSERT INTO scan_log (code_id, ua, ip, scene, create_time) VALUES (?,?,?,?,NOW())' ); $stmt->execute([ $codeId, substr($_SERVER['HTTP_USER_AGENT'] ?? '', 0, 255), getClientIp(), $scene ]); // 根据场景决定去哪个群 if ($scene === 'offline') { $target = getTargetForScene($codeId, 'offline'); } else { $target = getTargetById($codeId); } header('Location: ' . $target); exit;这套改动的核心是:码还是那些码,但海报印刷时在链接后加&scene=offline,公众号菜单里用&scene=wechat,后端就能按场景分配不同群、不同落地页。注意,这里要在后台的活码编辑表单里留一个「场景值」字段,生成二维码时自动拼上去,否则运营每次手动改链接很容易出错。
改完之后,我建议每次都要按三个步骤验证一次:第一步,分别用带scene=offline和scene=wechat的两个链接扫码;第二步,打开后台看scan_log表,确认两条记录的场景值确实不同;第三步,看接口返回的Location是否分别指向各自的目标地址。这套验证走完,才能算一次合格的发布。
以前我接过一个需求,客户说群里总有广告号混进来,排查到最后发现是全部流量都堆在同一个群、同一个码,没有任何鉴别机制。后来加了场景分流,把不同渠道的人分开引到不同群,配合进群欢迎语做了一轮筛选,问题才算落地。吃过那次亏之后,我每次上线活码都强制自己走一遍「清缓存 → 真机扫码 → 查日志」的流程,确认跳转地址和记录都对得上,才敢发给业务方。希望帮到你。
本文还有配套的精品资源，点击获取
