index

对我来说，如果想要将博客长期维护下去，互动和统计功能是必不可少的。只不过静态的博客框架通常无法直接提供相关功能，这时候就需要借助其他的开源实现了。

访客统计

其实我也很能理解这种功能的矛盾之处，一方面博主们希望用统计数据来了解自己站点的流量情况，另一方面访客们觉得这可能涉及到隐私的问题。因此为了达到最大限度的平衡，我肯定不会选择直接接入 Google Analytics 之类争议较大的外部工具，而在支持自建且注重隐私保护的项目中目前最出名的我想应该是 Umami，所以这次我还是直接选择了它。

当然，如果你完全不能接受任何统计功能的存在，那只需要将此脚本加入浏览器广告拦截器的黑名单即可，也可以通过 DNT 设置来禁用本站的 Umami 跟踪，这完全无可非议。

由于需要数据库的支持，所以我还是回到了 Vercel 平台，其内置的 Neon 数据库已经完全够用，这样也不会增添额外的成本了。至于部署的过程也非常简单，先在后台提前创建好数据库并获取连接地址，再通过此链接一键部署即可。

只不过由于免费版的 GitHub 账户不支持创建私有的 Fork 项目，所以 Vercel 自动克隆出的项目将不会保持和源仓库的链接关系，这就导致后续要更新版本的话会麻烦一点。

比起部署而言，将 Umami 接入 Astro 时倒是有需要特别注意的点。如果直接将后台提供的脚本代码插入到站点中，会发现跟踪请求只有在页面首次载入时才会被触发，这个问题看似很容易解决，但实际上却并没有那么简单。

由于视图过渡机制的存在，当用户点击内链时并没有真正触发页面重载，所以自然也就不会重新执行被插入的脚本。Astro 官方文档针对此问题已给出了说明和解决方法，比如为脚本标签加入 data-astro-rerun 属性即可。

然而在搜索相关资料的过程中，我在这里发现了一个插件，测试了一下似乎没有作用。其实这个插件本身的机制并不复杂，但据我观察，直接通过 appendChild(child) 方法插入的脚本在页面切换后就会消失，不过这好像也没什么毛病。

于是我忍不住仔细调试了一番，想弄明白这个问题到底是怎么回事。

其实 Umami 的追踪脚本应该是能够处理这种情形的，其在此处为 history 对象注册了钩子，因此只要历史记录中的内容发生了变化，就可以重新触发跟踪请求，并不需要反复执行脚本。然而当 Umami 脚本的标签中包含了 defer 属性后，似乎钩子就不再生效了。之所以会出现这种情况，主要是因为 Astro 有一个针对 history 的防劫持机制，因此注册钩子的时机很重要。

由于 Umami 后台提供的代码中默认包含了 defer 属性，所以才会无意间导致了此问题的出现。因而只要去掉这个属性就可以马上解决问题，当然这样也会改变代码的执行时机，看来用最开始的方法才是最好的，总有种折腾了一圈又回到原点的感觉。

评论系统

评论系统这块开源的选择就很多了，仅国产这边就有 Twikoo、Artalk 和 Waline 等比较有名的作品，而国外的项目就更多了。之所以没有考虑那些基于 GitHub 的项目，主要还是考虑到并非人人都需要 GitHub 账户，再说面对一个必须要登录才能评论的站点我自己也是不太愿意去评论的。

考虑到 Twikoo 和 Artalk 之前都用过，这次我就选了 Waline 作为博客的评论系统，试用下来感觉也还不错。除此之外，Twikoo 只支持 MongoDB，Artalk 基于 Go 开发，也都是需要考虑的因素，这样看来只有支持 Postgres 的 Waline 可以做到纯 Vercel 部署，比另外两个要方便一些。

与 Umami 不同，Waline 官方提供的一键部署链接并不会直接克隆整个源代码仓库，而是只克隆了其中的一个专门的子项目，它实际上是一个只依赖 Waline 自身最新版的空项目，这样一来如果想要升级的话，就只需要在 Vercel 那边执行一下重新部署命令就好了。当然我理解有人是比较喜欢精准地控制版本的，也很有道理。

除了必须的数据库连接信息外，其他需要配置的环境变量不多，我这边主要是禁用了 UA 和区域信息的显示，并且启用了 Telegram 端的评论提醒。至于前端的配置就可以根据自己的喜好来做了，这种直接插入页面 DOM 中的评论系统可以通过页面上的 CSS 来控制样式，只是也有可能会产生需要手动处理的冲突。

另外在集成 Waline 时肯定也会遇到视图过渡相关的问题，根据上面的经验，最简单的方法肯定还是用 data-astro-rerun 属性，这里就不再赘述了。

总之，到这里新博客的建设工作就暂告一段落了，后面则是长期的维护工作，相较而言这才是最考验意志力的部分。