这是一篇由 AI 整理撰写的调研分析报告，结合公开数据与历史事件记录，分析 Stellar 为什么没能获得更广泛的关注。文中的原因判断属于基于这些材料的解释，文末另附博主补充。

前面的梦已经记不太清了，大多是一些无聊的小事，只是我发现这个世界并不完美，偶尔冒出一些解释不清的异象。

连续两个晚上做梦笑醒，不是因为有什么好事，只是睡眠变浅了。

OKR-2025 目标回顾

Stellar 的功能大多是从混乱里长出来的：先遇到一个问题，再想办法把它理顺。这篇记录知识库、动态时间线和几次工程重构的设计过程。

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

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 方案： 服务器问题记录

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

其实早在 Stellar 1.13.0 版本，我便引入了主题信息标签，初衷是待用户群体广泛升级后，通过解析此标签，在前端清晰展示用户当前所用的主题版本。

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

一、失落感贯穿全年的 2023其实从年初就知道了这将会是很难熬的一年，事实证明确实如此。

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