企业官网建设流程全解析

简介：面向Discuz! 论坛站长与社区运营者的QQ快捷登录插件，北岸团队在原生QQ登录基础上优化的2.4版本，主要解决论坛注册流程繁琐、新用户流失的问题。借助腾讯开放平台申请的应用ID与密钥完成账号对接，用户可直接用QQ账号登录，减少重复填写资料的步骤，提升登录成功率与社区使用体验。

压缩包共61个文件、约1MB，以24个php逻辑脚本和4个xml插件配置为主，配合8个htm/html模板页面、12张jpg与11张png图标素材，覆盖安装、绑定、回调、卸载等完整环节。

已有430人学习，版本声明100%可用。插件提供SC_UTF8、SC_GBK、TC_BIG5、TC_UTF8等多种编码配置，并含移动端登录类文件，管理员可按论坛编码直接选用；安装、回调、绑定与帮助脚本齐全，便于对照梳理授权流程与数据表结构，降低自行调试成本。附带页面模板与图标资源，便于调整登录入口外观，也方便排查编码不匹配、回调异常等问题，适合中小型社区直接部署或二次调整。

1. 一个让站点登录页"半瘫"的插件版本

去年帮人接手一个 Discuz 站的迁移，登录页上那个 QQ 图标点下去转了三秒，然后停在一个空白页，地址栏里挂着一串code和redirect_uri。老站长说"以前是好的"，我问改过什么，他说换了个域名，顺手把 http 升成了 https。问题就出在这——Discuz QQ登录插件 里最容易被忽略的一环不是代码，是回调地址。后来我把插件换成北岸QQ登录 改进版 2.4，重新走了一遍从环境确认到回调试通的流程，才把这条路铺平。这类插件看着只是登录页多一个按钮，实际同时压在 Discuz 的插件机制、PHP 的扩展、开放平台的 OAuth2 校验三块地基上，任何一块松动，前台表现都是"点了没反应"。下面这套顺序，是我在 PHP 7.4 加 Discuz! X3.4 上实际走通过的落地步骤。

2. 装前先把环境钉死：Discuz! X3.4 与 PHP 7.4 的版本对照

插件装不上，十次里有六次不是插件的问题，是环境漂了。Discuz 的插件机制从 X3.2 之后基本稳定，但 PHP 版本一跨大版本，老插件里那些each()、create_function()、隐式类型转换的写法就开始集体报错。北岸QQ登录 改进版 2.4 属于延续老代码风格的那一类，我在 PHP 8.1 上试过一次，插件后台能进，前台点登录直接白屏，日志里是一条Uncaught Error: Call to undefined function each()。所以第一步不是急着上传压缩包，是先确认你脚下的地是不是平的。

2.1 一份能直接照抄的版本对照表

下面这张表是我目前给所有 Discuz 站装登录类插件时用的基线，左列是组件，中间是我实际跑通过的版本，右边是可接受区间和踩过的雷。表里的版本不是要求，是"我用这套没出问题"，你本地高一个小版本通常没事，跨大版本就要做好心理准备。

为什么把 PHP 卡在 7.4 而不是 8.x，说穿了就一句话：Discuz 本体和大量老插件在 8.x 上的兼容是零散的，你修好这一处，下一个?->或者函数签名变化又在别处冒出来。登录插件是面向全站用户的第一道门，不是做实验的地方。常见做法是给论坛单独跑一个 7.4 的 PHP-FPM 池，用 Nginx 的fastcgi_pass指过去，宿主机上其他项目该用 8.x 用 8.x，互不干扰。

确认版本的命令没什么花头，但一定要在 Web 实际使用的那套 PHP 上跑，不是 SSH 登录后默认的那个php。我见过太多人命令行php -v看到 7.4，结果站点的 FPM 池指向 8.0，白折腾半小时。

# 看 CLI 版本，只作参考，不代表站点实际用的 php -v # 看站点实际加载的扩展，这才是关键 php -m | grep -E 'curl|openssl|json|mbstring|gd' # 如果是 FPM，直接问 FPM 的 socket 对应哪个版本 ps aux | grep 'php-fpm' | grep -v grep

php -m的输出里，curl、openssl、json、mbstring这四个必须有。curl负责跟开放平台换 token，openssl决定 https 回调能不能走，json用来解析返回体，mbstring处理昵称里的中文和 emoji。少任何一个，插件后台一般不会拦你，等到用户点登录才炸，属于最难受的那类故障。

如果缺扩展，Debian 系和 RHEL 系的装法不一样，但思路一致：装上对应版本的包，然后重启 FPM。这里要注意包名必须带版本号，php-curl和php7.4-curl是两个东西，装错了等于没装。

# Debian / Ubuntu 系，包名要跟 PHP 版本对齐 apt install -y php7.4-curl php7.4-openssl php7.4-mbstring # RHEL / CentOS 系 yum install -y php74-php-curl php74-php-openssl php74-php-mbstring # 装完必须重启 FPM，只 reload nginx 没用 systemctl restart php7.4-fpm

装完再跑一次php -m确认，别信安装脚本最后那行"successful"。这类事我吃过亏，脚本说成功，实际扩展没进conf.d，因为 ini 扫描目录的路径跟包默认的不一致。

2.2 必开扩展与目录权限：data/ 可写是底线

扩展齐了，接下来是目录权限。Discuz 的插件机制会把插件配置、缓存、模板编译产物写到data/下面，data/plugin/、data/cache/、data/template/这几个目录必须是 Web 用户可写的。权限不对的表现很有迷惑性：插件在后台能装上、能启用，但前台入口不出现，或者出现了点下去 500，日志里翻半天只有一行权限拒绝。

我的做法是先看一眼属主，再决定是改属主还是改权限，不要上来就chmod -R 777。777 能让问题消失，但也会让下一个问题以更隐蔽的方式出现。

# 先看当前属主，假设 Web 用户是 www ls -ld data data/cache data/template data/plugin 2>/dev/null # 统一属主，权限给到 755，文件 644 chown -R www:www data find data -type d -exec chmod 755 {} \; find data -type f -exec chmod 644 {} \; # 运行期需要写的几个目录单独放宽 chmod -R 775 data/cache data/template data/plugin data/log

data/log容易被漏掉，插件出错时的日志如果写不进去，你在后台看到的永远是那句干巴巴的"操作失败"，等于把黑匣子焊死了。另外config/目录要保证 Web 用户可读但不可写，config_global.php里存着数据库密码，权限给宽了是另一类事故。

Nginx 这一侧还有个小坑值得提前说。Discuz 的插件入口走的是plugin.php?id=xxx:yyy这种带冒号的参数形式，如果伪静态规则写得激进，把plugin.php也当成静态资源去try_files，请求会直接落到 404，而你在浏览器里看到的是"页面不存在"，根本想不到是重写规则的问题。

# 关键：plugin.php、connect.php 这类动态入口不能被静态化规则拦截 location / { try_files $uri $uri/ /index.php?$query_string; } # 伪静态规则放在后面，且显式排除 plugin.php location ~ \.php$ { fastcgi_pass unix:/run/php/php7.4-fpm.sock; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }

fastcgi_pass的 socket 路径要跟你实际启动的 FPM 池对上，/run/php/php7.4-fpm.sock只是 Debian 系的默认值，RHEL 系通常在/run/php-fpm/www.sock。路径错了的表现是整站 502，比插件问题好排查得多。

2.3 装之前留好后悔药：三处必须备份的东西

插件装坏了不算大事，装坏了还没有回滚点才是大事。Discuz 的插件安装过程会改数据库，部分插件还会往common_setting、common_plugin里写记录，卸载不干净的时候，残留的钩子会让前台某块区域一直报错。所以我装任何插件之前，固定备份三样东西。

第一样是数据库。用mysqldump导一份完整的，别只导插件相关的表，因为插件的钩子可能挂在common_pluginvar、common_nav这些"看起来不相干"的表上。

# 导出前先确认表前缀，默认是 pre_，很多站改过 mysqldump -u root -p --single-transaction --default-character-set=utf8mb4 \ 论坛库名 > /backup/discuz_$(date +%F_%H%M).sql

--single-transaction是给 InnoDB 用的，能保证导出的是一致性快照，论坛在线时也不会锁表。--default-character-set=utf8mb4别省，Discuz 的默认字符集在不同版本间有差异，导出时字符集不对，恢复回来就是一堆问号。

第二样是source/plugin/整个目录，打个 tar 包，几十兆的事。第三样最容易被忽略：把后台"应用 - 插件"列表截图或者复制一份存下来，记清楚当前装了哪些、哪些是启用的。等出问题要回滚时，你至少知道"原本是什么样"，否则只能凭记忆猜哪个是后装的。

3. 开放平台拿凭证：AppID、AppKey 与回调地址的对应关系

插件本身的代码是死的，能不能跑起来取决于你从开放平台拿到的那三个值：AppID、AppKey、回调地址。这三者的关系，说白了一句：AppID 是你的身份证，AppKey 是密码，回调地址是你告诉对方"办完事回哪儿找我"。三者里有任何一个跟平台上登记的不一致，用户在授权页点完"同意"，回来就是个错误页。

3.1 建应用时填的三项信息

在开放平台建一个网站应用，表单看着长，真正影响插件能不能跑的就三项。第一项是应用类型，必须选网站应用，选成移动应用的话回调地址的校验规则完全不同，插件按网页方式跳转会被拒。第二项是站点地址，填你论坛的根地址，带协议头，比如https://论坛域名。第三项是回调地址，这一项最要命，后面单独说。

拿到 AppID 和 AppKey 之后，先别急着往插件后台填。AppKey 在平台上一般只明文显示一次，关掉页面就得重置，我的习惯是先扔进密码管理器，再填进插件。填的时候注意别把首尾空格带进去，这个坑低级但高频，trim()一下不费事，插件不一定替你做了。

应用创建完还有一个状态问题，很多人卡在这。新应用默认是未上线状态，这时候只有你在平台上登记的测试账号能走通授权流程，普通用户点进去会被拦。我的做法是先在后台把自己加进测试名单，把整条链路跑通，确认没问题再去提交审核。审核期间不用等，测试账号够用了。

3.2 回调地址为什么必须和站点 URL 同源

这一段是整篇里我最想让你记住的部分。开放平台校验回调地址时，比对的粒度比你想象得细：协议（http 还是 https）、主机名（带不带 www）、端口号（非标准端口要写出来）、路径，逐字符比对。少一个斜杠都可能被判不合法。

常见的匹配失败组合，我列一下，都是实际遇到过的：

所以正确顺序是：先去插件后台看它要求的回调地址是什么格式，把那个完整的 URL 复制出来，再填回开放平台。反过来做，先填平台再去改插件，你会发现插件根本不让你自定义回调路径，它是写死在代码里的。

Discuz 系登录插件的回调入口通常长这样，插件标识以压缩包里第一层目录名为准，别自己改：

https://你的域名/plugin.php?id=插件标识:callback

有些版本走的是connect.php?mod=login&op=callback这条老路子，具体看插件后台参数页上写的那行提示，照抄就行。抄完记得在平台上把"站点地址"也改成同一个域名，两个字段不一致时，部分接口会返回"来源不合法"。

还有一个细节：如果你站点的 http 会 301 跳到 https，那么回调地址必须直接写 https。写 http 的话，用户授权完回来先吃一个 301，跳转过程中code参数在某些客户端上会丢，表现就是"授权成功了但没登录上"。这种玄学问题查起来极费时间，从源头避免最省事。

3.3 回调地址变更后的连锁反应

站点换域名、加 CDN、上 https，这三种操作都会改回调地址。改完之后不是更新平台那一个字段就完事，插件后台的参数、Discuz 的siteurl配置、缓存里的旧地址，三处都要跟着动。

siteurl在后台"全局 - 站点信息 - 网站 URL"里，也可以直接查数据库确认：

-- 表前缀按实际情况替换，很多站不是 pre_ SELECT skey, svalue FROM pre_common_setting WHERE skey IN ('siteurl', 'siteport');

siteurl末尾不要带斜杠，这是 Discuz 的约定，带了之后拼出来的链接会出现双斜杠，某些严格的校验会因此失败。改完这些，去后台"工具 - 更新缓存"点一下，把data/cache/里的旧配置冲掉。我一般还会顺手把data/template/下的编译产物删一遍，模板缓存里可能还留着旧的登录按钮链接。

4. 插件落地：从上传 source/plugin 到后台启用

环境和凭证都齐了，才轮到真正把插件放进去。Discuz 的插件安装是"文件到位 → 后台识别 → 安装 → 启用"四步，每一步都有各自的失败模式，分开看比混在一起猜要快得多。

4.1 上传与文件完整性校验

插件包解压后，第一层应该是一个英文标识的目录，这个目录名就是插件标识，跟回调地址里的id=参数必须一致。解压出来如果多套了一层目录，比如插件名/插件名/...，后台是识别不到的，因为它扫的是source/plugin/下的一级子目录。

上传方式我用两种：文件小就后台"应用 - 插件 - 安装新插件"直接传压缩包，文件大或者服务器限制上传大小，就用 scp 传上去再解压。后者更可控，也能顺手把权限设好。

# 假设站点根目录是 /www/discuz cd /www/discuz/source/plugin # 上传后解压，注意压缩包内是否有多余的顶层目录 unzip -l /tmp/plugin.zip | head -20 # 解压并修正属主 unzip /tmp/plugin.zip -d /www/discuz/source/plugin/ chown -R www:www /www/discuz/source/plugin/插件标识 find /www/discuz/source/plugin/插件标识 -type d -exec chmod 755 {} \; find /www/discuz/source/plugin/插件标识 -type f -exec chmod 644 {} \;

unzip -l那一步别跳过，它能提前告诉你压缩包结构对不对。我见过打包时把.DS_Store和__MACOSX一起打进去的，虽然不影响运行，但会让目录看起来乱，排查时干扰视线。

传完之后核对一下关键文件在不在。一个功能完整的登录插件，目录里通常会有主入口文件、install.php（安装时的建表逻辑）、callback相关的处理文件、模板目录、语言包目录。少一个，后台可能装得上，但点登录会报 404 或者空白。这一步不要求你读懂代码，只要求你确认"该有的都在"。

4.2 后台安装、启用与数据表变更

进后台"应用 - 插件"，列表里应该能看到一个"未安装"状态的插件。点安装，过程一般几秒钟。这里有个 Discuz 的老规矩：如果站点开启了插件数据存 datastore 的选项，部分插件会提示需要先开这个开关，否则装完参数保存不了。

// config/config_global.php 末尾附近，找到这行改成 1 $_config['plugindata']['datastore'] = 1;

这个配置项的作用是把插件自己的配置数据缓存进common_syscache表，减少每次请求查库。改了之后要清一次缓存才生效。改配置文件属于动手术，改之前先cp config_global.php config_global.php.bak，出了事直接换回来。

安装过程中插件可能会建表或者给已有表加字段。Discuz 自带的 QQ 互联会用common_member_connect这张表存绑定关系，字段里有conopenid、conuin、conisregister这些。改进版插件如果复用了这套表结构，绑定关系就存在这儿，后面排查"绑错人""重复注册"时全靠它。

-- 看某个 openid 绑到了哪个 uid 上 SELECT uid, conopenid, conisregister FROM pre_common_member_connect WHERE conopenid = '这里填实际的 openid'; -- 看有没有同一个 uid 被多条记录占用 SELECT uid, COUNT(*) AS c FROM pre_common_member_connect GROUP BY uid HAVING c > 1;

第一条查出来是空，说明这个 QQ 号压根没绑上；查出来有记录但用户说登不进去，那就是插件读表的方式跟这张表对不上，得回去看插件是不是自建了表。第二条查出c > 1，是典型的重复绑定，通常是用户在插件装之前用 Discuz 自带的 QQ 互联绑过一次，装完又用插件绑了一次，两条记录指向同一个 uid 的不同 openid。

安装完成后记得点"启用"。启用和安装是两个状态，只安装不启用，前台什么都不会出现。启用之后页面会刷新，这时候去看"全局 - 站点功能"或者插件自己的设置页，应该能看到参数表单了。

4.3 前台入口挂载与模板缓存清理

插件启用了但登录页没有 QQ 图标，这个现象太常见了，原因基本集中在三处：模板没挂载、缓存没清、图片路径 404。

先看模板。Discuz 的登录页模板在template/默认模板目录/member/login.htm里，插件一般通过钩子自动注入，但如果你用的是第三方模板，钩子位置可能被改过，注入失败。判断方法很简单：把模板临时切回默认的，看图标出不出来。出来了就是模板的问题，没出来才继续往下查。

再看缓存。Discuz 的模板是编译型的，data/template/下存的是编译后的 PHP 文件，改了模板不删这个目录，前台还是老的。

# 清模板编译产物和配置缓存，注意只删内容不删目录本身 rm -rf /www/discuz/data/template/* rm -rf /www/discuz/data/cache/* # 目录本身要留着，属主和权限不能丢 chown -R www:www /www/discuz/data/template /www/discuz/data/cache

删完刷新前台，第一次访问会重新编译，可能慢一两秒，正常。如果删了之后报"模板文件不存在"，说明模板目录的路径配置有问题，去后台"全局 - 站点功能 - 界面"里核对模板目录名。

图片 404 相对好判断，浏览器 F12 看那个小图标的请求，红色就是路径不对。插件一般把图标放在自己的static/或images/目录下，路径是相对站点根目录拼的。如果你把论坛装在子目录里（比如/bbs/），而siteurl配的是域名根，拼出来的路径就会少一层，图标自然 404。这种问题不用改代码，改siteurl就行。

5. 参数逐项配：后台表单里哪几个字段不能错

插件装好之后，后台那张参数表才是真正决定它能不能用的地方。表单字段不多，但每一项都有明确的失败表现，我按"填错了会怎样"的顺序过一遍。

5.1 核心参数对照表

AppID 和 AppKey 这两个没什么好说的，复制粘贴别带空格。回调地址要强调的是：插件后台填的这个值，和开放平台登记的那个值，必须字符级一致，包括协议和末尾有没有斜杠。我一般做法是先在浏览器里把回调 URL 打开一次，确认它返回的不是 404，再把地址栏里那一整串复制到两边。

绑定方式这一项影响最大，值得单独说。选"自动建号"时，用户第一次用 QQ 登录，插件会拿昵称生成一个 Discuz 账号，密码随机，邮箱可能是openid@域名这种占位。选"强制绑定已有账号"，用户必须先登录本地账号再绑定，多一步但账号体系干净。两种没有优劣，看站点定位，但装好之后不要随便改，改了之后老用户的绑定关系可能失效。

5.2 账号绑定策略与用户组映射

绑定策略里有个细节容易被忽略：邮箱冲突。自动建号时，如果插件用 QQ 返回的邮箱去建账号，而这个邮箱已经在站里注册过，就会撞库。表现是新用户点登录，提示"该邮箱已被注册"，然后就卡住了，既没登录也没建号。

常见做法是把自动建号用的邮箱改成不可达的占位地址，比如用 openid 拼一个假域名，避免和真实邮箱冲突。如果插件后台没有这个选项，那就只能选"强制绑定已有账号"这条路，牺牲一点转化率换稳定性。

用户组映射是另一个高频问题。新用户自动建号后落在哪个组，决定了他们能看到什么。落在"等待验证会员"组的话，用户登录成功但什么都看不了，会以为登录失败了。我一般在插件后台把默认组设成一个权限明确的普通组，装完立刻用一个测试 QQ 走一遍，登录后随便点开一个帖子确认能看，这一步花不了两分钟，能省掉后面一堆"登录了但用不了"的反馈。

5.3 伪静态与 HTTPS 下的回调拼接

站点开了伪静态之后，plugin.php?id=x:callback这种带冒号的 URL 在某些重写规则下会被截断，:后面的部分被当成端口或者路径分隔符。表现是回调进来时插件收不到id参数，直接返回首页。

排查方法是在浏览器地址栏直接访问那个回调 URL，加一个?test=1，看页面返回什么。正常应该是一个错误提示（因为没有 code 参数），不正常是 404 或者跳回首页。后者就是重写规则的问题，去 Nginx 配置里确认plugin.php没有被location ~ \.html$之类的规则接走。

https 环境下还有一层：PHP 的 curl 要能验证对端的证书。默认情况下 curl 用系统 CA 库，但很多编译安装的 PHP 没配curl.cainfo，表现为SSL certificate problem: unable to get local issuer certificate。这个报错在插件后台往往被吞掉，用户看到的只是"登录失败"。

// 临时探针，放到站点根目录，测完立刻删 $ch = curl_init('https://开放平台接口域名/'); curl_setopt_array($ch, [ CURLOPT_RETURNTRANSFER => true, CURLOPT_TIMEOUT => 5, CURLOPT_SSL_VERIFYPEER => true, // 生产环境不要为了跑通改成 false CURLOPT_SSL_VERIFYHOST => 2, ]); $body = curl_exec($ch); if ($body === false) { echo 'curl error: ' . curl_error($ch); } else { echo 'ok, http code: ' . curl_getinfo($ch, CURLINFO_HTTP_CODE); } curl_close($ch);

这个探针只做一件事：确认 PHP 的 curl 能不能带着证书校验访问 https。返回curl error: SSL certificate problem就是 CA 没配好，去php.ini里指定证书路径：

; php.ini 里加上这两行，路径按系统实际的证书位置改 curl.cainfo = /etc/ssl/certs/ca-certificates.crt openssl.cafile = /etc/ssl/certs/ca-certificates.crt

改完重启 FPM。注意CURLOPT_SSL_VERIFYPEER千万别为了图省事设成false，那等于把证书校验整个关掉，中间人随便截你的 token 你都察觉不到。生产环境上这么干，早晚要还。

6. 排查：五类最常见的翻车现场

插件这东西，装的时候顺不顺利不重要，出问题能不能五分钟定位才重要。下面这五条是我遇到过频率最高的，每条按现象、原因、解决写，你对着现象找就行。

6.1 现象：点登录图标跳到错误页，地址栏带 code

原因基本只有一个：回调地址跟平台上登记的不一致。可能是协议不同（http 对 https）、主机名不同（带不带 www）、末尾斜杠不同，也可能是站点换过域名但平台没更新。

解决分三步。第一步，把浏览器地址栏里那个完整的回调 URL 复制出来，包括所有参数。第二步，登录开放平台，把登记的回调地址也复制出来，一个字符一个字符对。第三步，改到完全一致，改完清一次 Discuz 的缓存，因为插件可能会把回调地址缓存进common_syscache。对不出来的情况也有，比如站点前面挂了 CDN，PHP 拿到的HTTP_HOST跟真实域名不一致，这时候要在 Nginx 里补proxy_set_header Host，或者在config_global.php里把siteurl写死。

6.2 现象：授权页正常，回来提示"code 已失效"

原因是那个code被用了两次。OAuth2 的授权码是一次性的，换完 token 就作废。什么情况下会换两次？最常见的是页面被刷新了，或者浏览器回退又前进，还有一个隐蔽的原因是站点配置了多条回调路径，插件先请求一次失败，重试又用同一个 code。

解决：先确认用户是不是手动刷新过，这个没法从服务端杜绝，但可以在插件里加个友好提示。如果是自动重试导致的，去看插件代码里换 token 的那段有没有失败重试逻辑，有的话改成失败不重试，直接跳错误页。另外检查服务器时间，时间偏差过大时 token 的签名校验会失败，表现也是类似的报错，date命令看一眼，跟标准时间差超过几分钟就去配 NTP。

6.3 现象：前台图标不出来，或者点下去 500

分两种。图标不出来的，先清data/template/和data/cache/，再看模板是不是第三方模板把钩子位置改没了，最后看图片路径是不是因为站点装在子目录而少了一层。点下去 500 的，去看 PHP 错误日志，data/log/下或者 FPM 的error_log，十有八九是插件里用了 PHP 8 已经移除的函数。

解决：500 这类问题没有捷径，必须看日志。日志里如果是Call to undefined function，说明 PHP 版本太高，要么降版本，要么把那个函数替换成等价写法。如果是Failed opening required，说明插件文件不全，重新传一遍。最坑的是日志里什么都没有，那就是display_errors关了而错误又没写进日志，临时在config_global.php里把$_config['debug'] = 1打开，能看到更多信息，查完记得关掉。

6.4 现象：登录成功但用户说"没登录上"

这个现象最迷惑，因为服务端日志显示一切都是成功的。原因通常是 cookie 域或者会话没对上。Discuz 的登录态靠 cookie，cookie 的 domain 配置在config_global.php的$_config['cookie']['cookiedomain']里。如果站点从www.example.com换到了example.com，而 cookie 域还写着带 www 的那个，浏览器就不会把 cookie 带上来，用户看着是登录了，一刷新就掉。

解决：把cookiedomain改成.example.com这种带前导点的形式，能同时覆盖主域和子域。改完让用户清一次浏览器 cookie，或者你在后台换个 cookie 前缀（cookiepre），强制所有客户端重新拿。顺便检查一下$_config['cookie']['cookiepath']，站点装在子目录时这个值要跟着改，不然 cookie 只在那个子目录下有效。

6.5 现象：同一个人被建了两个账号

多发在"之前用 Discuz 自带 QQ 互联绑过，后来又装了这个插件"的站。两套逻辑各存各的 openid，用户点不同入口就建不同账号。查common_member_connect表会看到同一个 uid 有多条记录，或者同一个 openid 对应多个 uid。

解决：先决定保留哪一套。如果保留插件这套，把插件装之前的老绑定关系导出来，按 openid 匹配，能对上的手动合并，对不上的通知用户重新绑。合并账号要动common_member和一堆关联表，不是删一条记录那么简单，操作前必须再备份一次数据库。我的习惯是在插件启用之前先把老的 QQ 互联入口从模板里摘掉，只留一条路，从源头避免分叉。

7. 验证：从点击图标到绑定成功走一遍

参数都填完，缓存都清完，别急着通知用户"能用了"。登录链路涉及四次跨系统跳转，中间任何一环断了，前台表现都是含糊的"失败"。我固定用一个五分半钟的验证流程，走完才敢说这活干完了。

第一步，静态检查。确认前台登录页那个图标能正常显示，F12 看图片请求是 200 不是 404。顺手在无痕窗口打开一次，排除浏览器缓存干扰。

第二步，回调可达性。用 curl 直接打回调地址，看返回状态码。这一步验证的是路由，不是业务逻辑。

# 回调地址换成你实际的，看状态码和跳转目标 curl -sS -o /dev/null -w 'http_code=%{http_code} redirect=%{redirect_url}\n' \ 'https://你的域名/plugin.php?id=插件标识:callback' # 顺带确认站点根地址返回正常，排除整站故障 curl -sS -o /dev/null -w '%{http_code}\n' 'https://你的域名/'

正常情况下回调地址不带参数访问会返回 200 加一个错误提示，或者 302 跳回登录页，两种都算路由通。返回 404 说明重写规则有问题，返回 502 说明 PHP 那边挂了，这两种先修好再往下走。

第三步，完整链路。用一个从未在这站注册过的 QQ 号走一遍首次登录，重点看三件事：授权页能不能正常拉起、回调后有没有自动建号、建出来的账号落在哪个用户组。建号之后点开一个需要登录才能看的帖子，确认权限正常。

第四步，二次登录。同一个 QQ 号退出后再登一次，这次不应该再建号，应该直接进。如果又建了一个，说明 openid 没被正确读出来，回去查common_member_connect表。

第五步，数据库对账。

-- 确认绑定记录只有一条，且 conisregister 标记符合预期 SELECT uid, conopenid, conisregister, conis_follow FROM pre_common_member_connect WHERE conopenid = '刚才那个 QQ 的 openid';

conisregister这个字段各家插件用法不完全一样，我的经验是它标记"这条绑定是不是通过注册流程产生的"，值和你预期不符时，去看插件的建号逻辑，别硬改数据库。

这套流程我一般会跑两遍，第二遍换个浏览器，因为在无痕窗口和普通窗口之间，cookie 的行为差异会暴露出一些配置问题。有一次就是在无痕下一切正常、普通窗口下登录掉线，最后定位到是cookiedomain写错了，白白多花了一个下午。

从那以后我每接一个 Discuz 站，装登录插件之前都强制自己先跑一遍环境对照表，装完再走一遍这五个检查点，一步不省。不是因为流程多严谨，是因为跳过任何一步省下的十分钟，后面都要用两小时来还。希望帮到你。

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