告别不蒜子，自己给博客记个数
内容提要
作者因不蒜子统计服务频繁故障，改用Cloudflare Worker和D1数据库自建博客计数器，网页仍托管于GitHub Pages。文章介绍了Wrangler授权、数据库初始化、历史基数导入（估算约80,500次浏览、40,500位访客）、部署与接口检查，并指出单篇旧数据无法可靠迁移、访客数仅为近似值，同时提醒注意隐私保护和手动备份。
延伸解读
自建计数器的核心：数据自主与可控性
作者将计数从第三方服务迁移到Cloudflare Worker和D1，关键动机是避免服务故障导致数字消失。自建后，计数数据存储在自己的数据库中，可以随时导出备份，也能检查绑定和采集状态。但文章也提醒，这并非一劳永逸：Cloudflare仍可能出问题，只是现在能自己排查和备份。对于依赖统计的博客，这种可控性比免费服务更值得考虑。
历史数据迁移的妥协：估算基数与单篇缺失
迁移时，作者以约80,500次浏览和40,500位访客作为历史起点，但这是基于回忆的估算，并非精确导出。单篇文章的旧计数无法可靠获取，因此新系统只记录启用后的浏览量，页面显示的不是文章从发表至今的累计数。这种处理避免了把未知数据强行分配或归零，但读者需注意单篇数字的起点。
访客统计的近似性：随机编号与隐私边界
访客数通过浏览器本地保存的随机编号（有效期365天）去重，服务端仅存其SHA-256摘要。清除数据、换设备或浏览器都会产生新编号，导致同一人被重复计数；禁止本地存储时则只记浏览量。数据库不保存IP、User-Agent或编号原文，但请求仍经过Cloudflare，可能处理网络信息。因此访客数适合粗略参考，隐私说明也需相应更新。
运维提醒：备份与部署的分离
文章强调，网页源码、数据库记录和数据库备份是三件不同的事。日常发布仍用原有脚本构建静态网页，只有计数服务代码或配置变更时才需单独部署Worker。完整备份需用D1导出命令，且应放在非公开目录、避免覆盖旧文件；云端导出会暂时阻塞数据库请求，宜在低峰期进行。作者已手动导出并验证，但尚未设置定时备份，读者若效仿需自行补上。
Q&A
为什么作者要放弃不蒜子统计服务？
因为不蒜子服务频繁故障，网页能打开但浏览量显示为空，有时浏览器加载很久，检查发现统计接口没有正常返回，曾出现504 Gateway Timeout，数字时有时无，体验不好。
自建博客计数器的整体架构是怎样的？
网页仍托管在GitHub Pages，由Python生成静态网站；浏览器加载计数脚本后向Cloudflare Worker发送请求，Worker校验请求并用D1数据库保存访问记录和累计计数，最后返回数字显示在页面上。
如何把旧的历史浏览数据迁移到新计数器？
由于无法从不蒜子后台完整导出精确记录，作者根据回忆估算历史起点为80,500次浏览、40,500位访客。新系统将历史基数与新增记录分开保存再相加显示，单篇文章的旧计数无法可靠迁移，因此单篇只显示新系统启用后的浏览量。
自建计数器如何统计访客数？隐私方面有什么措施？
访客数通过在浏览器本地保存有效期为365天的随机编号，服务端保存其SHA-256摘要来去重，同一编号再次访问不新增访客。数据库不保存IP、User-Agent或随机编号原文，也不发送查询参数和锚点；但请求经过Cloudflare，仍可能处理网络信息，因此隐私说明需更新。
部署和初始化计数器时需要注意哪些关键步骤？
使用Wrangler 4.154.0，通过设备授权方式登录并确认whoami；创建D1数据库并填写ID到TOML；先保持COLLECTION_ENABLED为false，初始化本地数据库、导入历史基数、导出SQL并导入D1；部署Worker后检查绑定和历史基数，确认无误再将采集开关改为true重新部署。
计数器数据库如何备份和恢复？
使用wrangler d1 export命令导出完整SQL备份，输出文件名带日期时间，放在非公开目录且不覆盖旧文件；云端导出会暂时阻塞其他请求，应挑访问少时进行。恢复时先导入新数据库，核对后再切换，不直接覆盖正在计数的库。目前尚未设置定时备份。
这个自建计数器有哪些局限性和不准确之处？
统计请求可能被拦截、网络会出错、机器人可能混入，限流不能完全防刷；访客数只是近似值，清除数据或更换设备会产生新编号；单篇旧数据无法可靠迁移；接口不可用时脚本最多等待八秒，有缓存则显示缓存并注明时间，不自动重试。
