我见过最离谱的网站网站统计代码，是访问嵌在页面底部的一段只有三个字符的隐藏iframe——它每秒刷新一次，把访客的人数IP、浏览器版本、统计屏幕分辨率甚至鼠标停留坐标全部打包发到第三方服务器。代码那是网站个卖电子烟的灰色站点，老板根本不知道自己的访问访客数据正在被当作商品转卖。

写统计代码这件事，人数本质上是统计在做一件很朴素的事：数人。但数人的代码方式分三六九等。最粗糙的网站做法是服务器日志分析，每个请求都留下痕迹，访问但抓不到JavaScript渲染后的人数动态内容，也区分不了真人还是统计爬虫。稍微讲究点的代码用HTTP Referer字段判断来源，可这字段经常被隐私插件清空，数据缺口大得能塞进一头大象。

真正靠谱的方案是前端埋点。在页面底部插一段JavaScript，用`navigator.sendBeacon()`在页面卸载时悄悄把数据发回服务器。这方法有个坑——如果用户直接关掉浏览器标签页，beacon不一定来得及触发。我见过一个团队为此写了三套回退方案，最后用`visibilitychange`事件配合localStorage暂存，才把丢失率从12%压到2%以下。那些号称“精准统计”的第三方工具，其实背后都在跟这种技术细节较劲。

做统计代码最容易被忽略的是“去重”。裸的计数器会把同一个人的十次刷新算成十个人，这种数字拿去汇报，老板看了会开心，但运营看了会骂娘。所以得用cookie或者fingerprint标识唯一访客。cookie简单，但用户清缓存就失效；fingerprint靠canvas画图特征和字体列表生成指纹，准确率高，可涉及隐私争议。国内某大厂就因为这玩意被用户告过，最后悄悄改成了纯cookie方案。

写代码时还得考虑性能。统计脚本不能拖慢页面加载，否则用户早跑了。业内习惯是把脚本放在``之前，用`async`属性避免阻塞渲染。我见过一个极端案例——某电商网站首页的统计脚本居然用了同步的`XMLHttpRequest`，结果每次访问都要白等半秒，转化率直接掉了三个百分点。后来他们改成`fetch`加`keepalive: true`，问题才解决。

数据上报的频率也有讲究。实时上报太耗资源，批量上报又容易丢数据。折中的做法是每十秒攒一批，用`setInterval`检查队列长度，超过20条就立刻发送。如果页面处于后台标签页，浏览器会节流定时器，这时候得监听`visibilitychange`事件，在页面重新可见时补发积压的数据。

最后说个反常识的细节——统计代码里的时间戳最好用服务器时间，而不是客户端时间。因为用户电脑的时钟可能快慢五分钟，导致凌晨零点前后的数据归属错乱。我见过一个分析报表，把凌晨00:00到00:05的访问量算成了负值，就是因为客户端时间比服务器快，日志里出现了“未来”的记录。修这个bug只花了一行代码，但排查花了整整两天。

统计代码看起来简单，实际上每个环节都藏着无数个类似的坑。能把这些坑都填平的人，写出来的代码往往不超过五十行，但每一行都经得起推敲。那些动不动就报出几百万行代码的统计系统，多半是把简单的事情搞复杂了。