Starlight-apk blog

一切的源头#

翻 git log，最早的提交是四月底。

那时候它还叫 FutureOSS，一个听起来很牛但实际上啥也不是的名字。代码基本靠 AI 生，逻辑基本靠猜，能跑全靠运气。

我那时候的想法很简单：我想要一个插件化的运行时框架，什么功能都通过插件加。 想法挺好，但实现嘛……提交信息写的是「完成阶段2」，实际上连阶段1都站不稳。

第一个分水岭：v1.1.0#

4月24号，我搞了个大版本。

加了进程隔离、安全网关、防火墙、运维工具箱、FTP 服务器、多语言部署编排器……功能列表看着挺唬人。实际上这些插件大多只有一个壳——路由是空的(pass)，方法返回是错的，_load() 方法在清空数据而不是加载数据。

但有一件事我做对了：安全架构。

进程隔离是真的，AES-256-GCM 加密是真的，三层签名也是真的。那段时间我可能看了太多安全相关的文章，满脑子都是「不能让人轻易搞穿我的项目」。

于是 NBPF 包格式诞生了——一个插件打包格式，加密层数比功能还多。

至暗时刻：「修复P0级问题：40+文件语法错误」#

4月25号的提交信息很诚实：「修复了若干Bug」

然后第二天：「修复P0级问题：40+文件语法错误 + import路径 + 清理废弃代码」

40 个文件都有语法错误。import 路径全是错的。我不知道当时是怎么让这些代码「跑起来」的，可能是运气吧。

这一天我干了一件事：把整个项目的代码一个一个文件看过去，修语法错误，改 import 路径，删了一大堆不知道从哪来的废弃代码。

提交信息里的「🔧」表情现在看起来格外讽刺。

塞彩蛋：成就系统#

4月26号我加了一个成就系统。

藏在 !! 前缀后面。你在 CLI 里输入 !!help 就能看到。有各种奇奇怪怪的成就：

• 凌晨两点打开项目 → 解锁「夜猫子」
• 加载 20 个以上插件 → 解锁「插件收集者」
• 连续启动失败再恢复 → 解锁「崩溃幸存者」
• 在 CLI 输入经典秘籍指令 → 解锁「上上下下左右左右BA」

还有个 !!stats 可以看你的成就进度。!!export 导出成就截图去装逼。

这个功能跟框架本身毫无关系，但我做得很开心。写代码嘛，总得给自己找点乐子。

改名 NebulaShell#

5月2号，我把项目从 FutureOSS 改成了 NebulaShell。

原因很简单：FutureOSS 这名字太中二了，而且跟项目实际做的事情对不上。NebulaShell 至少听起来像是「一个有点技术含量的东西」。

同一天我还开始搞 TUI（终端界面），做了个双 UI 架构——Web 管理界面和终端界面可以同时用。后来因为懒，TUI 做到一半就搁置了。预留接口 的意思是「我也不知道啥时候会继续做」。

那场大规模重构#

5月3号到5月5号是项目变动最大的三天。

先是 「docs: 创建文档目录 + 更新LICENSE + 规范项目文档」——我终于开始写文档了。SVG 架构图、分层图、数据流图，画了一大堆。代码能不能跑先不说，图要好看。

然后是 「核心迁移至 oss/core + NBPF 多重签名加密 + NIR 编译器 + README 全面升级」。

这次重构把核心代码从插件体系里抽了出来，变成了独立的 oss/core/engine.py。之前核心功能本身也是一个插件（“用插件加载插件”），听起来很酷但实际维护起来很蛋疼——插件加载器还没加载完，你怎么让它去加载自己？

NIR（Nebula Intermediate Representation）也是这时候加的。说白了就是把 Python 代码 compile() 成 code object 然后序列化保存，实现所谓的「一次编译，到处运行」。其实就是 Python 自己本来就支持的功能，我给它包装了一下起了个看起来很专业的名字。

代码审查：当头一棒#

5月4号我做了一次全面的代码审查。结果挺难看的：

• 4 个 CRITICAL 级别问题：路径穿越漏洞、方法实现完全错误、路由空实现、空指针
• 3 个 HIGH 级别问题：代码审查器自己就不可用、多处未定义变量
• 总共 19 个问题

plugin-storage 的代码尤其惨——_resolve_path 方法完全忽略了传入的路径参数，不管你要读什么文件都返回同一个目录。get() 方法实际上在做 set() 的操作。keys() 方法在清空数据。_load() 方法在覆写文件而不是加载文件。

每个方法的实现都和它的名字完全相反。

看到这份报告的时候我沉默了十分钟。然后默默建了一个 FATAL_FIXES_REPORT.md。

项目的未来#

现在项目到了 v2.0（虽然 pyproject.toml 里写的还是 1.2.0）。

代码从最早的一堆烂摊子，到现在核心引擎 1700+ 行，NBPF 加密系统 600+ 行，NIR 编译器 300+ 行。虽然还有很多空实现和 pass，但至少架构是清晰的了。

后续计划里写着要与 Passnux 项目整合，全面技术重构。听起来又是一个大工程——希望这次不用再修 40 个文件的语法错误。

写在最后#

翻完 NebulaShell 的整个 git 历史，我发现一个规律：这个项目每一次大进步，都是因为看到了自己代码有多烂。

第一次重构是因为 40 个文件都有语法错误。第二次重构是因为代码审查查出了 19 个问题。下次重构可能是因为什么？我还挺期待的。

1
git clone https://github.com/starlight-apk/NebulaShell.git

「写代码最可怕的不是有 bug，而是你觉得自己写得挺好的。」