从“无限转圈”到“完美呈现”：一款轻量级WordPress流量统计插件的填坑实录

🎯 一、起心动念：为什么要造轮子？

作为一个WordPress站长，我们总需要在“功能”与“性能”之间做取舍。市面上的统计插件要么太重（如Jetpack，功能强大但拖慢后台），要么数据存储在第三方（涉及隐私且加载慢）。

我的目的很简单：

轻量化：数据存在本地数据库，不依赖外部服务。
纯净美观：模仿Jetpack经典的“绿柱黑芯”样式，但在详情页使用更清晰的折线图。
深度集成：不仅要在插件页看，还要在WordPress仪表盘（Dashboard）首页直接看，且支持点击跳转。

实现思路：

后端：自定义数据表 wp_uos_visitors_log，使用 admin-ajax 异步记录访问。
前端：使用轻量级的 Chart.js 库进行图表渲染。
交互：通过 AJAX 获取数据，实现无刷新加载。

🛣️ 二、坎坷的开发之路：那些年踩过的坑

原本以为只是简单的 CRUD + 画图，没想到在 “24小时详情页” 这个功能上，经历了数十个版本的迭代与挣扎。

1. CDN 的“水土不服”

最初，插件引用了国外的 CDN 资源加载 Chart.js。结果在国内环境下，脚本加载极其缓慢甚至超时，导致 Chart is not defined 报错，图表直接白屏。对策：果断切换至国内稳定的 360 CDN 或 Staticfile 源。

2. “无限转圈”的噩梦 (The Spinning Wheel of Death)

这是最折磨人的阶段。在开发到 V37-V45 版本时，为了追求UI的一致性，我强行把主页的“重叠柱状图”样式套用到了“24小时详情页”。结果：图表区域一直显示“加载中…”，控制台也不报错，但就是画不出图。

我一度怀疑是 SQL 查询慢，或者是 JS 冲突，尝试了无数次“盲目回滚”和“猜测性修复”，甚至一度想要放弃。

3. 破案关键：红色调试法

为了找出原因，我开发了一个 V49 深度调试版，直接在页面上打印出后端传来的原始数据和 JS 的状态。

]

真相只有一个：在调试面板中，我发现 PHP 输出的数据数组竟然是这样的： PV: [0, "6", "25", 0, "12" ...] 注意到了吗？它是字符串类型的数字！

而在 V39 等版本中，为了实现美观，我们在 Chart.js 中使用了 maxBarThickness 和 grouped: false 等复杂计算属性。当渲染引擎试图用这些复杂规则去计算一个字符串坐标时，运算崩溃了，导致渲染线程卡死。

🛠️ 三、核心技术复盘

1. 数据清洗（Sanitization）是重中之重

V36 版本之所以能跑，是因为它的配置简单，Chart.js 自动兼容了字符串。但为了更高级的图表，必须保证数据纯净。

代码改进示例：在 PHP 输出数据前，必须进行强制类型转换：

PHP

// 错误写法：数据库取出来直接用
// $hourly_data[$h] = ['pv' => $row->pv]; 

// 正确写法：强转整型 (intval)
foreach ($results as $row) { 
    $hourly_data[intval($row->h)] = [
        'pv' => intval($row->pv), // 关键！把 "6" 变成 6
        'uv' => intval($row->uv)
    ]; 
}

2. JS 实例的销毁与重建

在 SPA（单页应用）或动态加载中，如果 Canvas 上已经绑定了一个 Chart 实例，再次 new Chart() 会导致报错。 解决方案：画图前，先检测并销毁旧实例。

JavaScript

var ctx = document.getElementById('uosDetailChart');
if(ctx) {
    // 救命代码：如果有旧图表，先销毁！
    var oldChart = Chart.getChart(ctx);
    if (oldChart) { oldChart.destroy(); }
    
    new Chart(ctx, { ... });
}