在本地社区论坛的运营中，Discuz X5 依然是中小站长最稳妥的底盘。以我们承建的万维便民这类河套地区便民平台为例，论坛承载发帖互动，而电话114查号、在线聊天室等增强功能则以插件形式挂载。电话114解决本地商家号码检索，聊天室解决即时互动，两者都要复用论坛的用户、积分与登录体系。难点不在功能本身，而在于插件如何在不破坏论坛内核的前提下，与论坛共享用户、会话与数据。本文结合这两个插件的真实开发过程，拆解几处关键的数据交互、用户数据互通与参数传递实现。
一、数据库层的互通：用 DB 类而非直连
插件最常见的错误是另起一套数据库连接。Discuz X5 已经封装了 DB 类与 C::t 模型层，插件应当复用，既避免连接浪费，也保证表前缀与字符集一致。C::t(‘common_member’) 实际是返回一个继承自 discuz_table 的模型实例，会按 config 里的表前缀自动映射为 pre_common_member，插件里不需要写死任何前缀。读取一条用户信息，优先走模型而非裸 SQL，写复杂查询时再用 DB::fetch_all 或 DB::result_first。
通过 C::t(‘common_member’)->fetch($uid) 拿到主表，C::t(‘common_member_profile’)->fetch($uid) 拿到扩展资料，两者与论坛个人中心完全同源。实时性要求高的字段，例如在线状态，直接从 common_session 取 lastactivity，免去了自己维护会话表的重复劳动。插件自定义表也建议遵循 plugin_插件名_表名 的命名规范，在 install.php 里用 DB::schema 创建，这样卸载时方便 DROP，也避免和论坛核心表混淆。
二、用户数据互通：共享登录态与全局变量
论坛已经完成了登录鉴权，插件无需再让用户登录一次。核心入口是全局数组 $_G，它贯穿整个请求生命周期，包含 uid、username、groupid 以及已加载的 member 数组。聊天室在建立长轮询连接时，第一件事就是校验 $_G[‘uid’]，为空则回退到论坛的登录跳转。$_G 的会话由论坛自身的 session 机制维护，插件不需要判断 cookie、解密 token，只要 $_G[‘uid’] 大于 0 就是已登录。
这样用户数据天然互通：在电话114插件里展示某商家页面的”谁浏览过”，可以直接 join 论坛的 member 表取出昵称与头像，无需同步任何字段。会员等级、积分字段如 common_member 中的 credits、extcredits 也是同一张表，互推活动直接读即可。更省事的方案是插件表只存 uid，展示时实时关联，这样用户改名后所有展示位一处生效，不会出现旧昵称残留。
三、参数传递：模板注入与 Ajax 安全
插件要把数据送回前端，正规做法是走模板机制。在论坛主题页注入聊天室入口，我们注册 viewthread_top 钩子，在钩子方法里取 $_GET[‘tid’]，再用 template(‘ichat:room_entry’) 返回渲染片段，论坛会把这段 HTML 拼进原有页面。钩子的注册通过 hookscript 机制完成，插件安装时写入 common_plugin 的 hooks 字段，卸载时自动清理。模板变量通过 return 数组传递，前端模板里用 {$var} 或 {echo $var} 接收。
前端发起的请求必须带 formhash，这是 Discuz 防 CSRF 的令牌函数，插件直接调用即可，不必自己实现。Ajax 返回建议统一 JSON 结构，例如 {‘code’: 1, ‘data’: []}，前端按 code 判断成功失败。所有外部传入参数统一用 intval、daddslashes 收口，避免 SQL 注入与 XSS。
四、心跳监控与实时读取
聊天室最考验实时性。我们用 Redis 做心跳而不是写数据库，原因是高频上报会压垮 MySQL。以一万在线用户为例，每 15 秒上报一次就是每分钟 4 万次写入，MySQL 的锁与刷盘会立刻成为瓶颈。Redis 单线程 I/O 多路复用能轻松扛住数万级心跳，且过期机制天然适合在线判定。
客户端每 15 秒上报一次，服务端用 setex 写入带 30 秒过期的 key，网关侧只要 exists 命中就认定在线，超时自动消失，天然实现掉线检测。缓存 key 一定要加业务前缀，例如 ichat:heartbeat:uid，避免撞键。
消息的实时读取采用基于自增 id 的长轮询：客户端携带上次收到的最大消息 id，服务端只查大于该 id 的增量，50 条封顶，空结果时挂起片刻再返回。相比全量轮询，数据库压力下降一个数量级。
服务端挂起不能超过 PHP 的 max_execution_time，否则连接被进程管理器掐断，前端表现为频繁重连。我们用 25 秒硬上限，到点返回空包让客户端立即再拉。
五、电话114查号的数据交互示例
电话114的核心数据交互也遵循同样的思路。搜索接口接收关键词后，从 plugin_tel114_business 插件表中命中记录，结果列表再 join common_member 取出发布者头像，最后通过 template(‘tel114:search_list’) 渲染成论坛统一风格的卡片。点击”拨号”或”查看详情”时，前端用 Ajax 调用计数接口，把点击量写回同一插件表，同样通过 DB 类完成。整条链路没有绕过 Discuz 的数据层，也没有自建用户表，因此和论坛的账号、积分、权限完全打通。
六、几个必须注意的坑
第一，钩子命名要带插件标识。Discuz 的 hookscript 机制下，方法名冲突会静默覆盖，建议类统一以 plugin_插件名 开头，方法对应具体 hookid，避免与其他插件打架。
第二，缓存 key 必须加业务前缀。我们早期把心跳 key 写成 heartbeat:uid，结果和另一个缓存模块撞键，导致在线状态乱跳。改成 ichat:heartbeat:uid 后稳定。
第三，电话114的查号请求要走论坛的限流。开放查询接口容易被爬，我们在插件层套用了论坛的防刷逻辑，对单 ip 做窗口限流。
第四，插件安装脚本里要判断表是否存在，重复安装时不报错。用 DB::fetch_first 先查 information_schema 再 CREATE TABLE IF NOT EXISTS，是稳妥做法。
七、缓存一致性的兜底
聊天室消息除写入 Redis 外，还要定时落库。我们采用”Redis 主读，MySQL 主写”的混合策略：用户发言先写 MySQL 拿到自增 id，再写入 Redis 消息队列；读消息时优先从 Redis 取增量，Redis 异常时回退到 MySQL 兜底。这样既保证实时性，又避免 Redis 宕机导致丢消息。电话114的查询结果也做短时缓存，但商家信息更新后立即清缓存，保证号码准确。
八、权限与论坛用户组打通
聊天室房管和电话114商家的管理权限，直接复用论坛的 adminid 与 groupid。例如判断是否为管理员只需检查 $_G[‘adminid’] 是否大于等于 1，判断是否为超级版主检查 $_G[‘groupid’]。这样无需自建权限表，论坛后台调整用户组后，插件权限自动生效。
九、小结
把插件当成论坛的”外挂器官”而非独立系统，是这类项目能长期维护的关键。统一走 DB 类与 C::t、复用 $_G 登录态、用钩子做参数传递、用缓存承担高频心跳，这四件事做好了，电话114与聊天室就能和论坛无缝生长在一起。我们在万维便民（www.0478.wang）落地后，插件与论坛共享同一套用户体系，运营侧不再处理重复注册，开发侧迭代也互不干扰。对于正在做本地社区或行业论坛的站长，这套数据互通思路值得直接复用。
没有回复内容