浏览器标签页就是应用，只是操作系统从不承认

你在标签页1炒币，标签页2回邮件，标签页3下单词棋，标签页4画流程图——然后系统杀后台，全没了。这不是浏览器不行，是底层抽象缺了一块。

标签页即应用，但操作系统不认

原文作者描述了一个日常场景：Binance在标签页1，Gmail在标签页2，Scrabble在标签页3，Excalidraw在标签页4，标签页5是一个叫"Gnoke Council"的东西——四个AI（Claude、Gemini、GPT-4o、Grok）一起开会，你当人类主持。一个HTML文件，没后端，没API key，就是一个标签页。

你像切应用一样切它们。因为它们本来就是应用——Web应用。

但浏览器的设计逻辑是：操作系统要释放内存时，浏览器得乖乖交出来。标签页被杀，半条消息、画了一半的图、游戏进度、AI讨论到一半的结论——全灭。

这不是技术限制。这是概念缺失：操作系统有进程管理，浏览器标签页却只是"可丢弃的临时容器"。

现有方案为什么不够用

localStorage（本地存储）是笨钥匙串。塞字符串，取字符串，全手动管理——存什么、什么时候存、什么时候清，每个应用从零造同一套轮子。

浏览器自带的会话恢复更被动。不可预测，看浏览器心情，硬刷新就清。你不能命名它、查询它、主动杀掉它。

两者都没解决核心问题：把整个标签页当作一个有身份、有记忆、可复活的应用进程。

gnoke-spirit的解法：给标签页发身份证

一行代码：

gnokeSpirit.wake();

标签页变成进程。有身份——pid默认用location.pathname（页面路径），每条路由是独立进程。有记忆——IndexedDB（浏览器内置数据库）。知道该存什么、绝不碰什么。

杀掉标签页，重新打开，原地复活。

可以显式指定路径唤醒独立进程：

await gnokeSpirit.wake('/editor'); // 标签页1——独立进程

await gnokeSpirit.wake('/settings'); // 标签页2——隔离、独立

杀掉任意一个，两个都能恢复，彼此不知道对方崩溃过。

存什么、不存什么，硬编码而非配置

自动持久化：文本输入框、文本域、下拉选择值、滚动位置、当前聚焦的输入框。

绝对跳过：密码框、令牌/密钥、认证状态、任何敏感信息。

敏感过滤不是可选项，是写死的。你不可能"不小心"把密码存进去——安全默认，而非安全配置。

工程细节：移动场景下的生存策略

单一数据库连接，页面生命周期内复用。没有重复的indexedDB.open()调用——这对移动设备意味着电池和延迟双收益。

Schema（数据库结构）版本控制从第一天就有。现在是个空迁移钩子，但v2状态结构变更时，老用户不会丢失进程。大多数人跳过这步，后来后悔。

写入全部await（异步等待）。特别是visibility handler（页面可见性处理器）——操作系统杀标签页前的最后一次写入——必须等待完成。这是"生存写入"，必须落地。

零依赖。无构建步骤。2kb。丢一个script标签，调用wake()，完事。

为什么这事值得技术人关注

Web应用和原生应用的边界一直在模糊。PWA（渐进式网页应用）试图解决离线、推送、添加到主屏幕，但"进程生命周期"这个底层问题被搁置了。

gnoke-spirit的激进之处在于：它不等浏览器厂商或操作系统发善心，用现有API（IndexedDB、Page Visibility API）在应用层重建进程抽象。

2kb、零依赖、无构建——这三个数字意味着它可以塞进任何项目，从个人工具到内部系统，不需要说服CTO、不需要改造架构。

作者没说的是：如果这种模式普及，浏览器会不会最终原生支持？或者反过来，Web应用的"进程化"会不会倒逼操作系统重新思考标签页的地位？

标签页就是应用。只是操作系统从不承认。现在有人写了几行代码，逼它承认。