为什么需要一个计数器 API在开源项目的 README 里放一个访问量徽章或者在自己的博客页脚显示“本文已被阅读 N 次”是很多开发者都遇到过的需求。实现方式有很多但自建一套存储和计数的后端并不是一个小事要维护数据库、处理并发、防止刷量还要考虑图片生成的性能。访问量计数器 API 提供了一种更轻的解法它把计数、存储和图片渲染都封装成了“一次 HTTP GET 请求”。对于个人开发者来说这种接口的价值在于“工具化”——不需要关心底层存储只要约定好参数就能把访问量数据变成可展示的 SVG 图片或可处理的 JSON 对象。适用场景这个接口适合以下几类场景GitHub 项目 README 中使用img标签直接嵌入 SVG 计数卡片个人博客或静态站点上显示文章阅读量需要把访问量数据以 JSON 形式导出自行做数据看板或统计由于接口支持按site隔离并能挂多个name一套接口可以同时服务多个站点或页面不需要为每个页面单独申请一个接口地址。接口能力与边界先明确这个接口能做什么、不能做什么。能力方面输出格式有三种svg默认适合直接嵌入、png静态图、json适合程序处理计数模式daily每日清零和total累计不清零主题14 套前 7 个为像素牌主题含角色帧动画后 7 个为 SVG 渐变主题数字位数支持 4~12 位默认 7 位限制方面文档标注的 QPS 为 10 次/秒这个限制在正常的小流量项目下是足够的。但如果你的页面在短时间内被大量访问计数器请求本身可能会触发限流需要注意对图片资源做缓存或降级。另外接口的计数逻辑是“请求即增加”所以需要思考如何避免页面刷新就重复计数。鉴权与请求格式从官方 curl 示例可以看到该接口需要携带请求头X-API-Keycurl -sS \ -X GET \ -H X-API-Key: $APIZERO_API_KEY \ https://v1.apizero.cn/api/visits-counter?siteapizero.cnnamehomeAPIZERO_API_KEY需要从环境变量中读取或者替换成你自己的密钥。关于如何获取密钥请以官方文档为准本文不展开。请求参数逐项解析下面是各个查询参数的用途和注意事项用表格方便快速查阅。参数类型必填默认值说明sitestring否-站点标识用于区分不同来源建议传域名。不传则全局共享一个计数器namestring否demo计数器名称同一站点下可挂多个不同位置modestring否daily计数模式daily每日清零total累计不清零themestring否gojo_board主题可选项见文档formatstring否svg输出格式svg/png/jsonlengthnumber否7数字位数 4~12默认 7前导补 0no_incrementnumber否0只读模式1 表示只查询不递增site 与 name 的组合如果你有多个站点建议每个站点传不同的site例如siteblog.example.comnamearticle-1siteblog.example.comnamearticle-2sitedocs.example.comnameindex这样site相当于一级命名空间name是二级标识。如果不传site所有请求会落到同一个全局计数器容易互相影响。mode 与 no_increment 的配合no_increment1是一个很有用的调试参数。在预览某个 theme 或检查计数器当前值时使用它不会让当前请求计入总次数。建议在代码调试阶段始终带上这个参数等确认无误后再去掉。JSON 格式接入示例curl 默认返回的是 SVG 图片若想拿到结构化数据需要在请求参数中加formatjsoncurl -sS \ -X GET \ -H X-API-Key: $APIZERO_API_KEY \ https://v1.apizero.cn/api/visits-counter?siteapizero.cnnamehomeformatjsonmodetotallength7响应是一个 JSON 数组首个对象包含了业务数据。以文档中的示例为例[ { content_type: application/json, description: 成功, example: { code: 200, data: { display_value: 0000042, format: json, incremented: true, length: 7, mode: daily, name: home, record: { daily: 42, day: 2026-05-09, total: 1024, updated_at: 2026-05-09T21:48:5208:00 }, step: 1, theme: gojo_board, theme_name: 像素牌-苍空, value: 42 }, desc: success, tips: 极数本源 · https://apizero.cn }, status: 200 } ]其中值得重点关注的字段有data.value当前计数数值。modedaily时是当日累计次数modetotal时是总次数。data.display_value根据length格式化后的前导补零字符串可以直接用于展示。data.record.daily当日次数。data.record.total累计总次数。data.record.updated_at服务端更新计数的时间。data.incremented本次请求是否使计数自增。当no_increment1时为false。注意code和status在这里都是字符串200在判断时建议用“与字符串比较”而不是“与数字比较”避免类型不一致的麻烦。错误处理思路接口的错误处理在素材中没有单独列出但根据通用 API 经验可以从以下几个方面入手排查请求头缺失如果没有携带X-API-Key接口大概率会返回 401 或 403。这是最常见的问题。参数校验失败length超出 4~12、theme不在可选列表里、mode不是daily/total、format不在三者之列服务端可能返回 4xx 或携带错误信息的 JSON。QPS 限流当请求频率超过 10 次/秒可能收到 429 或类似限流响应。可以通过在客户端增加缓存、降低调用频率来解决。网络抖动调用超时、连接被重置等情况属于网络异常建议在代码中设置超时时间并做重试或降级。具体错误码以官方文档为准。上面只是通用排查思路避免与真实行为不一致。工程化注意事项在生产环境中接入这个计数器有几个细节需要关注。用 SVG 做页面展示用 JSON 做数据采集在网页或 README 中嵌入计数卡片直接使用img标签指向formatsvg的接口地址即可无需后端参与img srchttps://v1.apizero.cn/api/visits-counter?siteblog.example.comnamearticle-1themegojo_board alt访问量 /但如果需要在页面加载时把计数写入自有的 localStorage 或数据库建议用 JSON 格式请求一次取出value后再处理。避免刷新重复计数由于计数器是“每次请求都增加”的直接放在img里的话用户每次刷新页面都会导致 1。如果这不是你期望的行为有两种处理方式只让服务端或云函数在真正需要计数的时机调用一次接口页面不直接请求。前端先用no_increment1拉取值来展示再在页面离开或某个特定事件时触发一次真实的递增请求。这里没有绝对对错取决于产品定义。如果只是展示热度用传统img方式也够用。为图片响应加缓存SVG 这类动态图片的响应内容是不稳定的CDN 或浏览器缓存策略需要明确。如果你希望计数变化能尽快呈现可以在img的 URL 后面额外拼接一个参数例如t时间戳来绕过浏览器缓存但这会增加请求量需要权衡。更优雅的方案是让服务端或反向代理设置合理的Cache-Control再配合定时刷新。注意 QPS 上限QPS 10/s 对应的是单接口的请求频率。在小规模项目中足够但如果在高并发页面中所有图片都直连这个接口可能出现限流。建议在网关层或前端聚合数据降低直连压力。小结访问量计数器 API 把计数、存储和渲染封装成了简单的 GET 请求适合开发者在个人项目和中小站点中快速落地。关键点在于明确site与name的隔离关系区分daily和total模式使用no_increment调试针对缓存和重复计数做好设计。最后再强调一次接口的完整定义、错误码以及鉴权细节以官方文档为准。参考文档接口文档https://apizero.cn/aidocs/visits-counter原始 Markdownhttps://apizero.cn/aidocs/visits-counter/raw.md 访问量计数器 API 实战：参数调优、响应解析与站点隔离设计
为什么需要一个计数器 API在开源项目的 README 里放一个访问量徽章或者在自己的博客页脚显示“本文已被阅读 N 次”是很多开发者都遇到过的需求。实现方式有很多但自建一套存储和计数的后端并不是一个小事要维护数据库、处理并发、防止刷量还要考虑图片生成的性能。访问量计数器 API 提供了一种更轻的解法它把计数、存储和图片渲染都封装成了“一次 HTTP GET 请求”。对于个人开发者来说这种接口的价值在于“工具化”——不需要关心底层存储只要约定好参数就能把访问量数据变成可展示的 SVG 图片或可处理的 JSON 对象。适用场景这个接口适合以下几类场景GitHub 项目 README 中使用img标签直接嵌入 SVG 计数卡片个人博客或静态站点上显示文章阅读量需要把访问量数据以 JSON 形式导出自行做数据看板或统计由于接口支持按site隔离并能挂多个name一套接口可以同时服务多个站点或页面不需要为每个页面单独申请一个接口地址。接口能力与边界先明确这个接口能做什么、不能做什么。能力方面输出格式有三种svg默认适合直接嵌入、png静态图、json适合程序处理计数模式daily每日清零和total累计不清零主题14 套前 7 个为像素牌主题含角色帧动画后 7 个为 SVG 渐变主题数字位数支持 4~12 位默认 7 位限制方面文档标注的 QPS 为 10 次/秒这个限制在正常的小流量项目下是足够的。但如果你的页面在短时间内被大量访问计数器请求本身可能会触发限流需要注意对图片资源做缓存或降级。另外接口的计数逻辑是“请求即增加”所以需要思考如何避免页面刷新就重复计数。鉴权与请求格式从官方 curl 示例可以看到该接口需要携带请求头X-API-Keycurl -sS \ -X GET \ -H X-API-Key: $APIZERO_API_KEY \ https://v1.apizero.cn/api/visits-counter?siteapizero.cnnamehomeAPIZERO_API_KEY需要从环境变量中读取或者替换成你自己的密钥。关于如何获取密钥请以官方文档为准本文不展开。请求参数逐项解析下面是各个查询参数的用途和注意事项用表格方便快速查阅。参数类型必填默认值说明sitestring否-站点标识用于区分不同来源建议传域名。不传则全局共享一个计数器namestring否demo计数器名称同一站点下可挂多个不同位置modestring否daily计数模式daily每日清零total累计不清零themestring否gojo_board主题可选项见文档formatstring否svg输出格式svg/png/jsonlengthnumber否7数字位数 4~12默认 7前导补 0no_incrementnumber否0只读模式1 表示只查询不递增site 与 name 的组合如果你有多个站点建议每个站点传不同的site例如siteblog.example.comnamearticle-1siteblog.example.comnamearticle-2sitedocs.example.comnameindex这样site相当于一级命名空间name是二级标识。如果不传site所有请求会落到同一个全局计数器容易互相影响。mode 与 no_increment 的配合no_increment1是一个很有用的调试参数。在预览某个 theme 或检查计数器当前值时使用它不会让当前请求计入总次数。建议在代码调试阶段始终带上这个参数等确认无误后再去掉。JSON 格式接入示例curl 默认返回的是 SVG 图片若想拿到结构化数据需要在请求参数中加formatjsoncurl -sS \ -X GET \ -H X-API-Key: $APIZERO_API_KEY \ https://v1.apizero.cn/api/visits-counter?siteapizero.cnnamehomeformatjsonmodetotallength7响应是一个 JSON 数组首个对象包含了业务数据。以文档中的示例为例[ { content_type: application/json, description: 成功, example: { code: 200, data: { display_value: 0000042, format: json, incremented: true, length: 7, mode: daily, name: home, record: { daily: 42, day: 2026-05-09, total: 1024, updated_at: 2026-05-09T21:48:5208:00 }, step: 1, theme: gojo_board, theme_name: 像素牌-苍空, value: 42 }, desc: success, tips: 极数本源 · https://apizero.cn }, status: 200 } ]其中值得重点关注的字段有data.value当前计数数值。modedaily时是当日累计次数modetotal时是总次数。data.display_value根据length格式化后的前导补零字符串可以直接用于展示。data.record.daily当日次数。data.record.total累计总次数。data.record.updated_at服务端更新计数的时间。data.incremented本次请求是否使计数自增。当no_increment1时为false。注意code和status在这里都是字符串200在判断时建议用“与字符串比较”而不是“与数字比较”避免类型不一致的麻烦。错误处理思路接口的错误处理在素材中没有单独列出但根据通用 API 经验可以从以下几个方面入手排查请求头缺失如果没有携带X-API-Key接口大概率会返回 401 或 403。这是最常见的问题。参数校验失败length超出 4~12、theme不在可选列表里、mode不是daily/total、format不在三者之列服务端可能返回 4xx 或携带错误信息的 JSON。QPS 限流当请求频率超过 10 次/秒可能收到 429 或类似限流响应。可以通过在客户端增加缓存、降低调用频率来解决。网络抖动调用超时、连接被重置等情况属于网络异常建议在代码中设置超时时间并做重试或降级。具体错误码以官方文档为准。上面只是通用排查思路避免与真实行为不一致。工程化注意事项在生产环境中接入这个计数器有几个细节需要关注。用 SVG 做页面展示用 JSON 做数据采集在网页或 README 中嵌入计数卡片直接使用img标签指向formatsvg的接口地址即可无需后端参与img srchttps://v1.apizero.cn/api/visits-counter?siteblog.example.comnamearticle-1themegojo_board alt访问量 /但如果需要在页面加载时把计数写入自有的 localStorage 或数据库建议用 JSON 格式请求一次取出value后再处理。避免刷新重复计数由于计数器是“每次请求都增加”的直接放在img里的话用户每次刷新页面都会导致 1。如果这不是你期望的行为有两种处理方式只让服务端或云函数在真正需要计数的时机调用一次接口页面不直接请求。前端先用no_increment1拉取值来展示再在页面离开或某个特定事件时触发一次真实的递增请求。这里没有绝对对错取决于产品定义。如果只是展示热度用传统img方式也够用。为图片响应加缓存SVG 这类动态图片的响应内容是不稳定的CDN 或浏览器缓存策略需要明确。如果你希望计数变化能尽快呈现可以在img的 URL 后面额外拼接一个参数例如t时间戳来绕过浏览器缓存但这会增加请求量需要权衡。更优雅的方案是让服务端或反向代理设置合理的Cache-Control再配合定时刷新。注意 QPS 上限QPS 10/s 对应的是单接口的请求频率。在小规模项目中足够但如果在高并发页面中所有图片都直连这个接口可能出现限流。建议在网关层或前端聚合数据降低直连压力。小结访问量计数器 API 把计数、存储和渲染封装成了简单的 GET 请求适合开发者在个人项目和中小站点中快速落地。关键点在于明确site与name的隔离关系区分daily和total模式使用no_increment调试针对缓存和重复计数做好设计。最后再强调一次接口的完整定义、错误码以及鉴权细节以官方文档为准。参考文档接口文档https://apizero.cn/aidocs/visits-counter原始 Markdownhttps://apizero.cn/aidocs/visits-counter/raw.md