本文内容可能已经过时，仅作参考。 书接上回，刚迁到服务器，东西还没完全配完，就从日志里看到不少不速之客了！虽然是静态博客，但看到这些扫描器反复试探还是很烦，果断禁掉。

2026-08-01飞书下线旧 webhook 机器人后，本文已同步更新至 open-api 方案。 由于近期网站速度不稳定，只好再把博客解析改到服务器上。博客源代码托管在 GitHub 上，每次更新的流程如下： 提交源码到私有仓库 私有仓库执行 Action 2.1. 执行 hexo g 生成静态文件 2.2. 部署到 xaoxuu.github.io 公开仓库 2.3. 触发服务器同步拉取 xaoxuu.github.io 更新 本文内容 Vercel/Netlify/Cloudflare等平台同步部署（基于 xaoxuu.github.io 静态内容） 2.3 曾经是 rsync 同步到服务器、也曾是同步到 oss，但前者配置复杂，这次我已经忘了怎么操作了；后者用了几天感觉同步速度极慢。rsync 方案： 服务器问题记录

博客图片存哪儿，看起来是小事，折腾起来却让人头大。

熟悉我的朋友可能知道，我并非科班出身的前端或后端开发者。五年前，我摸索着实现了一个动态友链项目。这个项目磕磕绊绊地运行至今，但也暴露出一些由于我技能所限而难以解决的痛点，加之日常事务繁忙，项目一直处于“勉强能用”的状态。比如： 配置和更新流程略显繁琐 无法自动标记友链的在线状态（例如404错误） 查看朋友们是否更新博客，需要逐个手动访问 只能按照 issue 创建或更新时间排序，体验不佳

事情的起因在回访用户的过程中，我发现有不少用户用 wiki 当作专栏来使用，可见专栏确实是一个普遍的需求点，而现有的 wiki 系统并不是专门为此场景设计的，虽然能用，但是不够好用。 为什么需要用 wiki 作专栏？ 如果一个话题需要发多篇文章，且它们在归档页的顺序不是相邻的（即中间发布了不属于这个话题的其它文章），那么读者阅读的时候文末的「下一篇」会跳到此话题以外的文章中，没有办法连贯性地阅读此话题的全部文章。一个 wiki 项目就像一本书，其中的各个页面之间有较强的关联性，左侧有文档树，可以快速定位到上一篇、下一篇，因此很好的解决了这个痛点。

事情经过近日发现一个发通知时触发的 EXC_BAD_ACCESS 崩溃，在 DEBUG 时，崩溃指向这一行代码：