141 项测试、31 项合规检查、零捷径：我们如何交付 Statnive
大多数 WordPress 插件运行一次 linter 就完事了。Statnive 在任何发布交付之前都要通过 5 层自动化验证 — 从 pre-commit 钩子到 WordPress.org 合规门禁。这是我们检查的具体内容和原因。
在您安装任何插件之前，您都在信任别人的代码
您激活的每一个 WordPress 插件都获得了对您数据库、后台面板以及访客数据的完整访问权限。大多数插件页面只显示一个星级评分和一个「Last updated」日期。这远远不足以做出信任决策。
我们打造 Statnive 的初衷，就是让它成为我们自己愿意在自己网站上信任的分析插件。本文走一遍 Statnive 每一行代码到达您 WordPress 安装前所经历的精确质量流水线。没有空泛的承诺 — 具体的检查、真实的数字，以及关于自动化测试能与不能捕获什么的诚实说明。
要点数字：141 项 PHP 单元测试、31 个 WordPress.org 合规章节、10 个专门的 CI 门禁、3 个 PHP 版本目标，以及在每一次构建上强制执行的 5KB tracker 大小预算。
第 1 层：Pre-commit 钩子 — 没有任何东西未经检查就进入仓库
在代码进入我们的 Git 仓库之前，pre-commit 钩子会对每一个暂存文件运行两项检查：
对 PHP 改动：
- PHPCS（PHP CodeSniffer）针对 WordPress Coding Standards 校验暂存文件 — 这与 WordPress 核心使用的规则集相同。它会捕获不安全的输出转义、缺失的清洗以及不规范的代码模式。
- PHPUnit 运行完整的单元测试套件。141 项测试必须全部通过。任何一项失败都会阻止提交。
对 TypeScript/JavaScript 改动：
- Vitest 运行所有 React 组件测试。仪表盘 UI 不能未被察觉地回退。
Pre-commit 钩子刻意做得很快 — 在开发机上 5 秒以内完成。目标不是替代 CI，而是在最常见的错误浪费一次到 GitHub 的来回前就把它们抓住。在实践中，这一道门禁就能在代码离开开发者笔记本前抓住大约 80% 的问题。
第 2 层：持续集成 — 每次推送跑 6 个并行作业
每一次推送到我们的 development 或 main 分支，以及每一个 pull request，都会触发一个有 6 个并行作业的 GitHub Actions CI 流水线：
| 作业 | 检查内容 | 为什么重要 |
|---|---|---|
| Lint（PHP 8.2、8.3、8.4） | PHPCS + PHPStan level 6 | 跨 3 个 PHP 版本的编码规范和静态类型安全 |
| 单元测试（PHP 8.2、8.3、8.4） | PHPUnit 套件 | 跨 3 个 PHP 版本的逻辑正确性 |
| 最低底线冒烟测试（PHP 8.0） | 语法 lint + 自动加载启动 | 证明插件可以在声明的最低 PHP 版本上加载 |
| Tracker 构建 | Vite 构建 + gzip 大小检查 | 对分析 tracker 强制执行 5KB gzip 预算 |
为什么是 4 个 PHP 版本？
现实中 WordPress 网站使用 PHP 8.0 到 8.4。在 PHP 8.4 上能用的函数在 PHP 8.0 上可能表现不同 — 默认参数值、类型转换规则以及废弃特性在不同版本之间各异。我们在能跑完整测试套件的三个版本（8.2、8.3、8.4）上测试，并单独验证生产代码至少在 PHP 8.0 上能解析并启动 — 这是我们插件头部声明的最低版本。
5KB tracker 预算
在您网站上收集页面浏览的 JavaScript tracker 有一个硬大小上限：5,120 字节 gzip 压缩后。每次构建都会测量产物大小，超过预算就让流水线失败。这并非随意而为 — 我们的性能基准显示 tracker 大小与 LCP 影响直接相关。这个预算迫使我们让关键路径保持最小，把非必要功能延迟到一个异步的辅助脚本中。
# From our CI workflow — the tracker size check
- name: Verify tracker size
run: |
MAX_SIZE=5120 # 5KB in bytes
GZIP_SIZE=$(gzip -c public/tracker/statnive.js | wc -c)
if [ "$GZIP_SIZE" -gt "$MAX_SIZE" ]; then
echo "::error::Tracker size (${GZIP_SIZE}B) exceeds limit (${MAX_SIZE}B)"
exit 1
fiLevel 6 的 PHPStan
PHPStan 是一种无需运行代码就能找出 bug 的静态分析工具。Level 6（满分 10）会捕获类型不匹配、未定义变量、错误的返回类型以及不可达的代码路径。我们配合 phpstan-wordpress 扩展运行它，扩展能理解 WordPress 钩子签名、过滤器返回类型以及 $wpdb 方法约定。结合对 $wpdb->prepare() 的强制要求，这是我们对抗 SQL 注入的主要防线 — 静态分析器会标记任何拼接用户输入而非使用预处理语句的查询。
第 3 层：WordPress.org 合规 — 10 个专门门禁
这一层是 Statnive 的质量流水线与多数 WordPress 插件分道扬镳的地方。除了标准的 lint 与测试，我们还运行 10 个专门构建的合规门禁，强制执行 WordPress.org 插件指南 — 这与审查团队在提交期间手动检查的规则相同。
大多数插件开发者是在提交被拒后才发现这些规则。我们把它们自动化了，让违规在每次提交时被抓住：
安全门禁
ABSPATH 守卫 — 每个 PHP 文件在执行前必须检查 defined('ABSPATH')。这能防止通过 URL 直接访问插件文件，从而泄露服务器路径或在 WordPress 上下文之外执行代码。我们的门禁会扫描源码树中每一个 .php 文件，如果有任何文件缺少守卫就会失败。
禁止模式 — 自动化扫描会阻止 WordPress.org 明确拒绝的危险 PHP 函数：eval()、exec()、shell_exec()、system()、passthru() 和 curl_init()。它还会抓出 PHP 短标签、原始 json_encode()（必须使用 wp_json_encode()）以及硬编码的 wp-content 路径。
WP API 合规 — 检查所有脚本和样式表都使用 WordPress 的 enqueue 系统，而不是硬编码的 <script> 或 <link> 标签。也会扫描未清洗的超全局变量访问（$_GET、$_POST、$_REQUEST）— 这是 WordPress.org 拒绝插件提交的主要原因之一。
完整性门禁
Readme 与版本一致性 — 插件版本必须在三处保持一致：readme.txt 的 Stable tag、statnive.php 头部以及 STATNIVE_VERSION PHP 常量。不一致意味着 WordPress 会显示错误的版本号 — 让用户困惑，也是审查者眼中的红灯。这一门禁还会校验标签数量（最多 5 个）、短描述长度（最多 150 字符）、LICENSE 文件存在与否，以及 External Services 披露章节。
发行 ZIP 校验 — 构建实际会被上传到 WordPress.org 的 ZIP 文件，然后校验其内容。必需文件必须存在（statnive.php、readme.txt、LICENSE、src/Plugin.php、未压缩的 tracker 源代码）。禁止文件必须不存在（node_modules/、.git/、composer.json、tests/、phpunit、配置文件）。ZIP 大小必须保持在 25MB 以下。
头部对齐 — 校验全部 11 个必需的插件头字段都存在并保持一致。检查 Tested up to 的 WordPress 版本是否在当前稳定版的 2 个小版本以内 — 过期的值意味着插件无人维护，也会影响 WordPress.org 搜索排名。
架构门禁
架构阻断器 — 扫描那些表明违反政策的模式：在激活钩子里发起 phone-home HTTP 调用（用户在激活插件时不应看到网络请求）、自定义自动更新钩子（更新由 WordPress.org 处理）以及打包的 MaxMind GeoIP 数据库（用户必须自己提供 license key）。
免费/付费边界 — 免费的 WordPress.org 版本不能包含 license 门禁代码。这一门禁会扫描诸如 isPro()、checkLicense()、trial_expires 和 premium_only 等模式 — 确保 .org 构建是真正免费的，而不是阉割版的试用。
外部服务审计 — 提取 PHP 源码中引用的每一个 https:// 域名，然后核实每一个都在 readme.txt 的 External Services 章节中有所记录。任何未记录的外部连接都会让构建失败。这就是我们如何保证关于您的数据流向何处的透明度。
获取 Statnive：可信赖的代码
本文中描述的每一项检查都会在每次变更时自动运行。没有人需要记得跑安全扫描或检查版本一致性 — 流水线强制执行。从 WordPress.org 安装 Statnive，看看结果：在您自己的服务器上运行的快速、私密分析。
第 4 层：WordPress Plugin Check — 比要求更严格
Plugin Check (PCP) 是 WordPress.org 团队的官方工具，会运行审查团队所使用的相同自动化检查。多数插件配置 PCP 仅在错误时失败。
Statnive 在错误和警告上都会失败。
这是一个深思熟虑的选择。PCP 的警告通常标记的是合理的问题 — 已废弃函数的使用、可访问性差距、性能担忧 — 这些虽然在技术上不会阻止提交，但会随时间损害插件质量。把警告当作错误处理，让我们能抓住其他插件带病发布的问题。
PCP 门禁在构建后的发行目录上运行（不是源码树），使用 PHP 8.0 — 我们声明的最低版本。这意味着我们测的就是用户实际会安装的内容，运行在我们支持的最旧 PHP 版本上。
第 5 层：发布门禁 — 任何版本交付前要过 31 个章节
发布之前，完整的门禁把上面所有内容合并为一次通过/不通过的判定：
静态测试门禁（必须全部通过）：
| 门禁 | 检查 | 工具 |
|---|---|---|
| S-1 | WordPress Coding Standards | PHPCS |
| S-2 | 静态类型分析 | PHPStan level 6 |
| S-3 | PHP 单元 + 集成测试 | PHPUnit |
| S-4 | React 组件测试 | Vitest |
| S-5 | 官方 Plugin Check | PCP（错误 + 警告） |
合规 grep 门禁（17 项自动化模式检查）：
| 门禁 | 强制内容 |
|---|---|
| C-1 | 每个 PHP 文件都有 ABSPATH 守卫 |
| C-2 | License 文件校验 |
| C-3、C-4 | 激活时不 phone-home，无隐藏付费墙 |
| C-5 | Readme 结构、版本一致、外部服务披露 |
| C-6 | 无未清洗的超全局变量访问 |
| C-7 | 无打包的 GeoIP 数据库 |
| C-8、C-9、C-10 | 无自定义更新器、无打包的核心库、无外部 CDN |
| C-11、C-12 | 在停用时清理 cron，存在 uninstall 函数 |
| C-13 | SVN assets 目录结构 |
| C-14 | ZIP 完整性和大小 |
| C-15 | 数据库表创建遵循 dbDelta 格式 |
| C-16 | 所有面向用户的字符串都已国际化 |
| C-17 | 注册了 WordPress Privacy API 钩子 |
除了自动化门禁，每次发布还包含人工审查，覆盖性能预算、浏览器兼容性、可访问性（WCAG 2.2 AA）、后台 UX 清晰度、升级/迁移安全性以及失败处理。完整的清单跨 3 个严重级别共 31 个章节：
- CRITICAL — 阻塞发布流水线的自动化门禁
- RELEASE BLOCKER — 在打版本标签前必须通过的人工检查
- QUALITY GATE — 我们对自己持有的标准，会审阅但属于建议性
安全与隐私：由流水线验证，而不仅是承诺
许多分析插件会在营销页上列出安全与隐私功能。我们更愿意展示这些承诺是如何被机械地强制执行的：
所有 SQL 查询都使用预处理语句。 PHPStan 的 WordPress 扩展会标记任何拼接用户输入而非使用 $wpdb->prepare() 的 $wpdb 方法调用。这在静态分析阶段就会被抓住 — 在代码运行之前。
没有 Cookie、localStorage 或指纹追踪。 合规门禁会扫描设置 Cookie 的函数和浏览器存储 API。单元测试套件验证 tracker 负载只包含散列后、不可逆的访客标识。
每日轮换盐值。 同一个访客每天产生不同的散列值，防止跨天追踪。这一点由专门的单元测试覆盖，验证盐值轮换之间的散列唯一性。
Tracker 负载上的 HMAC 签名。 每一次页面浏览上报都用服务器生成的密钥签名。签名校验在单元测试套件中被覆盖 — 无效或被篡改的负载会被拒绝。
外部服务透明度。 CI 门禁会从源码中提取每一个外部域名，并核实它出现在 readme.txt 披露中。如果开发者新增了一个对新域名的 HTTP 调用，构建会一直失败直到该域名被记录。
自动化测试无法捕获的内容
我们相信对局限性透明，而不仅是对能力透明。
自动化测试验证代码在已知条件下行为正确。它们无法捕获：
- 微妙的 UX 困惑 — 一个技术上正确但对非技术用户具有误导性的仪表盘图表
- 性能边缘情况 — 一个在 1,000 行下很快但在 100,000 行下退化的查询。我们对关键路径有 k6 负载测试，但无法覆盖所有数据形状
- WordPress 生态冲突 — 仅在特定主机配置上才浮现的插件或主题交互问题。我们针对 WP 6.4 到 trunk 测试，但 WordPress 生态有 60,000+ 插件
- 零日漏洞 — 任何静态分析都无法防止此前未知攻击向量被利用
我们用每次发布的人工审查、任何人都可以审计代码的公开 GitHub 仓库，以及对 WordPress.org 支持论坛上来自真实安装报告的主动监控来弥补这些差距。
我们为什么把这些公开
研究表明超过 50% 的 WordPress 插件开发者在公开披露前不会修复已报告的漏洞。插件常年没有更新。除了星级评分和「Last updated」日期，用户没有办法区分一个被良好维护的插件和一个被遗弃的插件。
我们认为 WordPress 生态值得更好的信号。公开我们的质量流水线是一种抬高门槛的方式 — 既针对我们自己（既然已经公开，我们就无法悄悄跳过检查），也针对生态（其他插件开发者可以采用类似实践）。
如果您正在为自己的 WordPress 网站评估分析插件，我们建议您向每一个候选者询问：你们如何测试？发布前要跑哪些检查？我能看一眼 CI 配置吗？
Statnive 的整个代码库都在 GitHub 上开源。本文描述的每一份工作流文件、每一项测试、每一个合规门禁都可以公开审计。
试试 Statnive
所有这些工程都为一个目标服务：让您在自己的 WordPress 服务器上拥有可信赖的分析。没有第三方数据传输，没有 Cookie，没有拖慢您网站的追踪脚本。
从 WordPress.org 免费安装 Statnive — 您的数据留在您的服务器上，每一次发布都通过 141 项测试和 31 项合规检查的验证。