苹果派的小站 | 博客

Orbit 通向 v1.0 的长期方案：从 Runtime 代码到兼容性网络

2026-08-16T14:33:34.000Z

Orbit 通向 v1.0 的长期方案：从 Runtime 代码到兼容性网络

规划主题： Orbit 1.0 — Stable Floating Interaction Platform
起点： v0.4 的 Runtime Hardening 与 Contract Alpha
规划日期： 2026-08-16

一、长期目标：v1.0 不是“大版本”，而是“可被依赖的承诺”

Orbit 的长期价值不能建立在 Music、Clock 或未来某一个 Widget 的功能稀缺性上。单个悬浮工具会被替代，单套拖拽与 Dock 代码也会被复刻。Orbit 真正可能形成不可替代性的路径，是让站点主题、Widget 作者与用户都开始依赖同一种悬浮交互兼容性。

因此，v1.0 不应理解为“功能足够多”或“文档足够完整”，而应理解为：Orbit 已经能稳定地承诺一个跨主题、跨 Widget、跨版本的 Runtime Contract，并有真实的独立采用者证明该 Contract 值得依赖。

Orbit 1.0 的产品不是一批官方悬浮组件，而是一种让任何静态站功能获得一致空间、手势、生命周期、可访问性与用户偏好能力的开放运行时。

这一表述并不意味着 Orbit 要做成大型平台或云服务。相反，Orbit 的竞争力应来自轻量、可复制、可自托管、无框架与 local-first；这些特征与现有静态站定位一致。1 2 但“轻量”不能等于“只是一份好代码”。v1.0 必须让外部作者不用理解内部实现，也愿意把自己的 Widget 面向 Orbit 构建。

二、不可替代性的正确模型

Orbit 不应该试图通过封闭数据、专有账户或功能堆叠制造替代成本。那既偏离静态站与开源工具的气质，也会使产品与成熟 SaaS 正面竞争。更适合 Orbit 的模式是：开放协议 + 兼容实现 + 可移植用户连续性 + 生态验证。

不可替代性来源	它解决的问题	Orbit 中的具体体现	不应误解为
稳定 Contract	Widget 作者无需为每个主题重写横切交互。	一次面向 Orbit 的实现，获得挂载、拖拽、停靠、显隐、销毁、Launcher、Profile。	一个内部 `registerHost` 函数。
主题兼容性	站点维护者无需逐一手工协调 Widget。	主题只接入 Runtime 与 Manifest，多个 Widget 可统一运行。	官方只提供一个 Demo 主题。
用户连续性	用户的位置、可见性、偏好不因 Widget 更新而丢失。	local-first Profile、导入/导出、schema 迁移。	把用户数据锁在私有服务。
互操作网络	替换 Runtime 会破坏已有 Widget/主题兼容性。	独立 Widget、主题与工具都采用同一 Contract。	GitHub Star 或官方 Widget 数量。
可信治理	使用者敢于在自己的站点上长期依赖。	SemVer、兼容矩阵、弃用策略、安全边界与透明发布。	一次性发布 1.0 标签。

要注意：开源协议不会让 Orbit 的源码不可复制，但会让“重建所有兼容性、文档、测试、示例、用户 Profile 迁移与社区习惯”变得没有意义。真正的护城河不是锁定，而是被采用后形成的协调成本。如果到 1.0 前没有独立采用者，Orbit 仍可以是优秀库，但不应自称为平台。

三、v1.0 的产品边界

Orbit 需要坚定地做一个页面级微交互 Runtime，而不是逐步吞噬静态站的内容层、账号层、编辑层或 AI 层。边界越清楚，Contract 越稳定，第三方才越容易相信其长期方向。

Orbit 1.0 负责	Orbit 1.0 不负责
Widget 的挂载、生命周期、显隐、位置、停靠、空间协调和恢复。	内容管理、文章编辑、站内搜索、评论、推荐系统。
Pointer/keyboard/reduced-motion 等跨 Widget 交互约定。	Widget 的业务逻辑、业务数据模型和后端服务。
Launcher、可访问性基线、Profile 导入导出与错误隔离。	用户账号、强制云同步、广告、追踪与市场交易。
Widget/主题/Manifest 的兼容性与版本协商。	规定所有 Widget 必须使用同一视觉语言。
对静态 HTML、Hexo 等低构建依赖环境的友好接入。	成为 React/Vue/Next 等框架的通用应用平台。

这意味着，Reader、Music、Clock、站点状态等任何后续功能都只能是对 Contract 的证明，而不能倒逼 Core 为某一个业务做硬编码。当前 Runtime 已经开始避免在 Core 中写死业务 DOM id，这一原则应在 1.0 中成为硬性规则。3

四、通向 1.0 的阶段路线

版本号不是日历承诺。每个阶段只有在前一阶段的证据充分时才进入下一阶段。建议将路线分成 v0.4、v0.5、v0.6、v0.7–0.9、v1.0 RC 与 v1.0 六个阶段；若证据不足，应延长验证，不要用功能清单替代成熟度。

阶段	核心目的	对外状态	进入下一阶段的证据
v0.4	加固生命周期，发布 Contract Alpha 与 Profile Alpha。	实验性、仅建议试用。	三个异质 Widget 跑通同一 Contract；Music/Clock 重挂载无资源泄漏。
v0.5	把 Alpha 用于真实主题与外部作者试验。	Public Beta。	至少 2 个非核心维护的 Widget 或主题接入；发现并修复 Contract 缺口。
v0.6	收敛 Contract，定义 Manifest 与兼容性工具。	Candidate API。	Contract 变更明显下降；Widget 可由独立仓库发布与安装。
v0.7–0.9	兼容性、迁移、性能、安全和治理打磨。	Release Candidate 预备期。	至少一个完整升级周期无破坏性事故；跨浏览器/主题矩阵稳定。
v1.0 RC	API freeze、生态回归与迁移演练。	除 P0/P1 问题外不再改 Contract。	独立采用者确认升级无阻；安全与可访问性门禁通过。
v1.0	发布稳定承诺与兼容政策。	Stable。	满足所有 1.0 发布门槛，而非仅完成开发任务。

4.1 v0.4：证明“Contract 可以存在”

v0.4 负责清理地基：Music 的资源回收、Clock 的 Contract 迁移、Reference Widget、Profile Alpha、DOM 集成测试与统一 CI。它不试图解决生态问题，只解决“Orbit 自己是否有资格要求别人依赖它”。具体方案见《Orbit v0.4 方案》。

4.2 v0.5：证明“外部人可以使用 Contract”

v0.5 的主任务不是增加官方 Widget，而是引入外部视角。至少选择两个与核心仓库不同的维护边界：一个 Widget 作者、一个主题维护者；最好两者都不参与 Runtime 内部开发。应让他们按公开文档完成接入，然后将他们遇到的阻碍记录为 Contract Issue，而不是由核心作者用私有知识绕过。

v0.5 可以提供以下最小分发形态：一个 Runtime 包、一个 Widget manifest、一个独立 Widget 包，以及一个主题适配示例。对静态站用户仍应保留复制 dist/ 的零构建接入；包管理器是可选便利层，不可成为唯一路径。

v0.5 的成功问题： 一个来自独立仓库的 Widget 能否不复制 Gesture、Snap、Launcher、位置持久化或 DOM 清理代码，在两个不同主题中工作？如果答案是否定的，不应进入 API freeze。

4.3 v0.6：从“API 集合”成为“互操作协议”

v0.6 应冻结 Manifest 的基本形态，并建立兼容性协商。Runtime 与 Widget 不应只靠“能 import 就运行”，而应明确说明所要求的 Contract 版本、能力、样式资产和可选权限。Manifest 必须足够小，避免重演复杂前端插件平台的包管理问题。

{
  "id": "org.example.status",
  "name": "Example Status",
  "orbit": { "contract": "^0.6.0" },
  "entry": "./dist/widget.js",
  "styles": ["./dist/widget.css"],
  "capabilities": ["drag", "dock", "profile", "portal"],
  "permissions": ["local-profile"]
}

v0.6 规范组成	目的	稳定性要求
`Widget Manifest`	声明 entry、样式、Contract 版本、能力与权限。	进入 Candidate，字段采用可扩展/可忽略策略。
`WidgetDefinition`	定义 mount/destroy/visibility/metadata。	以生命周期语义为核心，避免业务字段膨胀。
`Runtime Service API`	提供 layout、gesture、profile、portal、a11y。	错误、取消、资源所有权要有明确语义。
`Profile Schema`	允许用户导入导出和 Widget 状态隔离。	提供 schema version 与 migration hook。
`Theme Adapter`	约束主题如何加载 Runtime、Manifest、样式。	保持静态文件接入，不假设框架或后端。
`Compatibility Report`	在构建/运行前说明可否组合。	对不兼容版本给出可理解错误，而非静默失败。

此阶段还应发布一个小型开发工具，例如 orbit validate 或纯浏览器诊断面板，用于验证 Manifest、识别重复 id、缺失样式、未释放 portal 和 Contract 不匹配。工具的价值不在“更炫”，而在于让第三方接入成本可见、可诊断。

4.4 v0.7–0.9：证明“生态可以安全地演进”

v0.7–0.9 的工作重点是耐久性，不是扩张速度。需要完成三类验证：一是兼容性，二是性能与可访问性，三是治理与升级。

兼容性方面，应至少维护两个主题/部署形态、三个独立业务形态的 Widget，并让其中至少一个 Widget 经过一次非破坏性升级。性能方面，要在移动端验证多个 Widget 并存、低端设备拖拽、长列表/portal 和 reduced-motion；现有项目对 rAF 合并、backdrop-filter 与几何正确性已有意识，但应从文档原则走向可复现的基准和回归门禁。4

治理方面，需要建立公开的变更流程：Alpha 可以快速变化；Beta 需要迁移指南；Candidate 仅修复；Stable 采用 SemVer、支持窗口与弃用周期。所有 breaking change 必须同时提供旧 Contract adapter 或明确的 codemod/迁移指南。v1.0 不应让早期 Widget 作者在一次小版本升级后被迫重写。

五、1.0 的技术架构标准

v1.0 不要求最复杂的实现，但要求每一种副作用都有清楚所有者、每一种跨 Widget 交互都有清楚仲裁者、每一个扩展点都有错误边界。

5.1 Core 的稳定职责

Core 子系统	1.0 承诺	典型失败时的行为
Registry	校验 id、版本与 capability；维护实例目录。	拒绝冲突定义，并向诊断面板报告。
Lifecycle	统一清理 listener、timer、rAF、observer、media 等副作用。	一个 cleanup 出错不阻断其他清理，错误以 `widgetError` 事件报告。
Visibility	区分 hide 与 destroy，维护 `aria-hidden` 与 portal 可见性。	无 Root 时不无限重试；销毁状态不得被意外复活。
Space Coordinator	处理位置、碰撞策略、停靠和 viewport 变化。	根据 capability 降级，不强迫所有 Widget 可拖拽。
Gesture Router	拥有 pointer session 与快捷键冲突策略。	冲突时遵循优先级并保证 cancel 可达。
Launcher	从 Metadata 渲染 Widget 列表，并保持键盘与焦点可访问。	单个 Widget 元数据损坏不得导致 Launcher 崩溃。
Profile Store	命名空间状态、schema 升级、导入/导出。	忽略不认识/损坏的条目，不丢弃其他 Widget 状态。
Diagnostics	汇总版本、实例、泄漏提示、兼容性状态。	默认只读，不影响生产体验。

Widget 作者有权要求 Runtime 提供声明过的服务；也有责任遵守资源、DOM、状态与安全边界。这个对称关系应写入 1.0 Contract，而不是分散在示例注释中。

Widget 权利	Widget 责任
获取隔离的 Profile 命名空间和可移植状态。	不读取、修改其他 Widget 的 Profile。
请求受控 portal 以渲染 body 级 UI。	通过 Runtime 声明 portal，销毁时不留下节点或全局监听。
使用统一 gesture/layout 服务。	不自行注册与 Runtime 冲突的全局 pointer 流。
在 Launcher 展示 label、图标与可见性。	元数据必须安全文本化；不得依赖 Core 的内置 id。
通过事件与其他 Widget 协作。	只使用版本化、文档化事件；不得直接调用其他 Host 私有 API。

5.3 安全与隐私底线

Orbit 的开放扩展会引入比第一方 Widget 更大的输入边界。1.0 应禁止 Core 直接把外部 Widget 的 id、label 或元数据写进 innerHTML；应采取 DOM API、文本转义和 URL 协议校验。Widget 样式隔离在 1.0 可以先通过命名空间约定和文档实现，不必急于引入 Shadow DOM；但必须避免默认全局 selector 破坏主题。

Profile 默认仅保存在用户浏览器。任何未来同步能力必须是可选、显式同意、可导出和可删除的独立服务，不能成为 Runtime 的隐式网络行为。对于像 Music 一样依赖外部 API 的 Widget，Manifest 至少应声明网络能力，并在文档中给出 CSP、connect-src 与 media-src 说明。5

六、生态策略：先验证“被采用”，再追求“规模”

Orbit 最需要的不是大量官方组件，而是少量可信的独立采用。第一批生态不应追求市场，而应追求异质性与可复现性。

参与者	他们为什么会采用 Orbit	Orbit 必须提供的交换价值	首批验证方式
静态站主题作者	不想为每个插件维护拖拽、移动端、z-index、可访问性。	一个稳定的 Theme Adapter 与统一入口。	在两个不同风格主题中加载同一 Widget。
Widget 作者	不想重复做生命周期、空间与管理面板。	Contract、Services、样板、诊断和版本兼容。	独立仓库发布一个非核心 Widget。
站点维护者	想组合工具而不让页面变乱。	Launcher、冲突管理、Profile 与可复制配置。	从 manifest 安装/移除多个 Widget。
终端用户	想保留自己的位置、可见性和微交互偏好。	local-first、低打扰、可恢复、可迁移。	导出 Profile 后在另一兼容站点/主题导入。

首批 Widget 的选择应围绕 Contract 的压力测试，而非热度。建议至少包含：一个带媒体/异步状态的 Widget（Music）、一个极轻量周期更新 Widget（Clock）、一个含 portal 或列表的 Widget，以及一个由外部作者实现的、与上述业务无关的 Widget。这样才能验证 Runtime 是否真的通用。

同样，主题适配需要两个不同约束：例如一个传统 Hexo 主题和一个纯静态 HTML/Cloudflare Pages 部署。若 Orbit 只能在自己的 Demo 样式和 DOM 结构中顺利运行，它就还不是通用 Runtime。

七、版本与治理政策

v1.0 的可依赖性不只取决于代码，还取决于使用者能否预测变化。应在 1.0 前公布以下政策，并实际执行至少一个 Beta → RC 的升级周期。

政策	1.0 承诺
语义化版本	Core Contract 的破坏性变化只出现在 Major；新增可选能力进入 Minor。
Contract 生命周期	`experimental` → `beta` → `stable` 三阶段；每项能力均标记稳定性。
弃用期	Stable API 在至少一个 Minor 版本内给出 warning、文档迁移和可用替代。
兼容窗口	Runtime 明确支持哪些 Widget Contract 范围；不兼容必须可诊断。
安全修复	P0/P1 漏洞或资源泄漏优先 patch；公开说明影响范围与修复版本。
变更治理	影响 Contract 的 Proposal 必须有动机、替代方案、迁移和测试计划。
生态沟通	Changelog 区分 Runtime、Contract、Widget、Theme Adapter 与文档变化。

MIT 许可与开放开发仍然可以保持。真正需要治理的不是贡献权限，而是 Contract 的稳定性：不要让每个为 Music 手感而做的内部变化，意外成为所有第三方 Widget 的破坏性变化。

八、衡量进展的指标

Orbit 不应以“新增组件数”作为长期北极星。它要证明的，是部署者、Widget 作者和用户对同一 Runtime 的依赖正在增强。建议同时观察领先指标与结果指标。

类别	指标	为什么重要
Contract 可用性	从空模板到首个 Widget 可运行的步骤数与失败点。	衡量第三方接入摩擦，而不是核心作者熟练度。
复用深度	Widget 业务代码中未重复实现的 Runtime 横切能力数量。	验证 Contract 是否真正节省了拖拽、显隐、清理等样板。
生命周期可靠性	多次 destroy/remount 后监听、DOM、portal、media 的残留数。	这是第三方敢否依赖 Runtime 的基础。
生态独立性	非核心维护者的 Widget/主题数量及持续兼容版本数。	区分官方示例与真实采用。
用户连续性	Profile 导出/导入成功率、schema 迁移成功率。	证明 Orbit 开始承载可移植偏好，而非单页装饰。
升级信任	Minor 升级中无迁移失败的第三方 Widget 比例。	证明治理与兼容政策可执行。
体验质量	交互冲突、可访问性缺陷、移动端回归的 issue 数。	防止生态扩张破坏 Orbit 的低打扰哲学。

这些指标不一定全部公开，但它们应服务于一个判断：是否有人在没有核心作者介入的前提下，成功安装、开发、升级并维护 Orbit Widget。

九、v1.0 的 Go / No-Go 门槛

v1.0 最重要的纪律，是宁可继续发布 0.x，也不要用版本号掩盖未经验证的稳定性。以下门槛应作为发布清单而非愿景。

Go：可以发布 v1.0 的条件

维度	必须满足的条件
生命周期	所有参考 Widget 都通过自动化 mount/hide/destroy/remount/portal 清理测试；无已知 P0/P1 泄漏。
Contract	`WidgetDefinition`、Runtime Services、Manifest、Profile Schema 已至少经过一个完整 Beta 升级周期。
外部采用	至少 2 个非核心维护的 Widget/主题组合，在不同主题或部署形态中持续可用。
兼容性	有公开兼容矩阵、诊断工具与一次成功的无破坏升级案例。
文档	新 Widget 作者可只凭公开文档完成接入；所有链接、示例、npm 包文件和迁移指南通过自动校验。
可访问性	Launcher、键盘操作、焦点恢复、reduced motion 和高对比基本场景有自动/人工回归。
安全与隐私	动态元数据安全渲染；Profile local-first；网络能力与 CSP 边界文档化。
治理	SemVer、弃用、支持窗口与变更 Proposal 流程已发布并试运行。

No-Go：应继续停留在 0.x 的信号

若 Contract 仍频繁因第一方 Widget 的临时需求而改变；若 Music/Clock 之外的 Widget 需要复制内部私有模块；若第三方主题接入需要核心作者手工调试；若 destroy/remount 仍可能残留监听；或若唯一采用者仍是 Orbit 自己的 Demo，那么 v1.0 都尚未到来。此时继续发布 0.6、0.7 或 0.9 是负责任的做法，而不是失败。

十、结论：让 Orbit 值得被替代之前先值得被依赖

Orbit 的目标不应该是让任何人“无法替代”它的代码；开源世界中那既不现实也不必要。更值得追求的状态是：Widget 作者、主题维护者和用户都发现，离开 Orbit 会失去一组已经验证过的兼容性、连续性与交互质量，于是没有足够理由去替换它。

这条路径从 v0.4 的生命周期和 Contract Alpha 开始，但不在 v0.4 结束。v0.5 需要外部人使用，v0.6 需要协议收敛，v0.7–0.9 需要在真实升级中证明耐久，v1.0 才能对稳定性作出承诺。届时 Music、Clock 与其他 Widget 仍然重要，但它们的重要性不在“本身不可替代”，而在于它们共同证明：Orbit 已经成为静态站悬浮交互的可靠兼容层。

参考资料

Orbit-v0.3更新报告

2026-08-15T04:13:32.000Z

Orbit v0.3 更新报告

版本定位： 在 v0.2 的多 Widget Runtime 之上，补齐实例生命周期、显式销毁、可访问性恢复入口和最低自动化门禁，为将来的稳定 API 打基础。

发布范围

v0.3.0 已以标签 v0.3.0 和 GitHub Release 发布，指向提交 e61e983；npm 包 floating-widget-framework 的 latest 也为 0.3.0。

相对 v0.2-baseline，此次变更涉及 46 个文件，约新增 4,500 行、删除 416 行。改动覆盖 Runtime、Clock/Music Host、Launcher、构建校验、CI、性能说明、阶段设计记录与发行产物。

主要更新

1. 生命周期成为正式契约

v0.3 引入 LifecycleScope，将事件、计时器、DOM、观察器等副作用登记为逆序、幂等、异常隔离的 cleanup 队列。Runtime 同时明确了两个不同操作：

操作	语义	适用场景
`setVisible(id, false)`	隐藏，不释放已创建实例和资源	用户在 Launcher 中暂时关闭组件
`destroy(id)`	显式清理资源并移除实例	页面卸载、重建、PJAX 或业务主动销毁

Orbit.mount() 也改为幂等：新的 widgets 配置只更新列出的组件，不会因某个 id 被省略而销毁已经挂载的实例。这避免了增量配置场景下的意外拆除。[4]

2. Host adapter 与 Clock 试点

Runtime 通过 Host adapter 获得 start、getRoot、destroy 和 getVisibilityTargets，核心层不再写死 Music/Clock 的业务 DOM。Clock 作为试点已覆盖事件解绑、计时器销毁、rAF 拖拽队列取消、DOM 删除和 destroy 后重新 mount；这是本次更新最可信的工程验证。[5]

Clock 的拖拽更新经 requestAnimationFrame 合并，展开方向交由共享 ExpandPolicy 判断，也将高频视觉更新与可测试几何决策分开。

3. Music 接入新边界

Music Host 增加了模板集中创建、状态 class 的单一投影、data-orbit-portal 所有权、AudioEngine/MutationObserver/PJAX 监听清理以及显式 destroyMusicPlayer()。特别是 dock-list portal 只删除被本实例声明拥有的节点，降低了对页面其他内容的误伤风险。[6]

4. Launcher 的可访问性和移动端恢复

Launcher 现在会在打开时聚焦标题或第一个控件、在关闭时恢复触发点焦点，并处理 Tab 循环与 Escape 关闭。若粗指针设备上全部 Widget 被隐藏，launcherFallback: 'ghost' 会显示一个独立、不可拖拽且不入列表的恢复按钮，避免用户失去重新打开管理器的路径。

验证与质量信号

本版本新增 LifecycleScope、WidgetRegistry、ExpandPolicy 的单元测试。实际执行结果如下：

校验项	实测结果	覆盖范围
`npm run build`	通过	三个浏览器 IIFE 产物生成
`npm run test:unit`	14 项通过	生命周期、注册契约、展开几何
`npm run test:normalize`	12 项 smoke 检查通过	状态归一化规则
`npm run check:dist`	通过	发行文件存在性与体积检查
`npm run ci`	通过	build、unit、dist 校验
GitHub Actions	v0.3 发布提交成功	Node 20 环境下的基础门禁

构建后工作树保持干净，且 dist/ 与 site/dist/ 的三个 JS 产物 SHA-256 一致，说明源码、npm 分发物和站点演示分发物在本次发布时没有漂移。

兼容性与使用影响

v0.3 仍支持 v0.2 的 registerHost 方式，并保留单 Widget 与多 Widget IIFE 交付形态。使用者需要理解的新行为是：隐藏不等于销毁；若页面框架会卸载或重建宿主环境，应调用 Orbit.destroy(id)，而不是仅从 ORBIT.widgets 配置中移除它。

已知限制与建议

Music Host 仍过于集中。 其约 1,566 行，仍混合歌单、音频、DOM、布局、手势、持久化和 PJAX。下一阶段宜拆分 Playlist、Audio、Template/Portal 和 Interaction 边界。
CI 少跑了一层。 工作流执行 test:unit，但未调用完整的 npm test，因此当前没有自动跑 test:normalize。应将 CI 改为完整测试命令，并补充浏览器级的 destroy → remount、portal 清理和移动端长按回归。
迁移文档需补齐。 Release 说明指向 docs/MIGRATION-v0.3.md，但标签中不存在该文件。应提供实际迁移指南，解释 destroy/visible 的语义变化。
包入口需更明确。 main 当前指向会自启动的浏览器 IIFE；如果要支持 npm import，应增加 ESM/CJS 入口，否则需在文档中明确其浏览器脚本定位。

Orbit-v0.2更新报告

2026-08-15T04:03:28.000Z

Orbit v0.2 更新报告

版本定位： 从两个独立的悬浮组件成品，升级为拥有统一入口、统一管理面板和统一交互语言的多 Widget 浏览器 Runtime。

发布范围

本报告以 v0.1.1 发布提交与后续冻结的 v0.2-baseline 为比较边界。仓库没有独立的 v0.2.0 Git tag；变更记录将该系列标记为 0.2.0-c，而 v0.2-baseline 用作 v0.3 开发前的冻结快照。因此，本文以 v0.2 系列能力 而非某个单一 tag 作为汇报对象。

维度	v0.1.x	v0.2 系列	对用户的意义
交付形态	Music、Clock 可独立接入	新增 `dist/orbit.js` 多组件入口	页面只需选择一种集成方式即可获得统一管理
组件管理	无统一面板	Launcher + `Orbit.mount/setVisible/list`	用户能集中显示或隐藏组件
桌面操作	单个组件的既有交互	默认 `Alt+O` 打开管理面板	可快速进入统一控制入口
移动操作	组件自身触控	长按悬浮球打开 Launcher	适配没有键盘的触控设备
文档叙述	FWF 预览与组件并列	统一为 Orbit Runtime	产品模型更清晰

主要更新

v0.2 的决定性更新是新增 src/core/Orbit.js、src/core/Launcher.js、src/entry-orbit.js 以及浏览器产物 dist/orbit.js。原先的 Music 与 Clock 不再只作为孤立脚本存在，而可由 Runtime 注册、启动并在 Launcher 中展示。

对静态站用户而言，推荐接入从“分别引用两个脚本”转变为：引入 Music 与 Clock 的 CSS、写入 window.ORBIT 配置，再引入一个 orbit.js。这降低了多组件接入成本，也为后续增加 Widget 留出了公共入口。

2. Launcher：解决多组件可管理性

Launcher 为桌面提供 Alt+O 快捷键，为移动端提供“长按球体”入口，并加入首次提示与桌面/移动端差异化脚注。其价值不在于弹出层外观，而在于解决了多组件出现后“谁负责统一管理”的产品问题。

v0.2 同时补上了两项关键交互修复：一是 Music 的 display:block !important 场景仍可被隐藏；二是移动端长按松手顺序调整为先识别长按、再结束拖拽，从而避免长按被误判为普通点击。这些修复使 Launcher 的基本操作能在真实页面中成立。

3. 交互与布局向共享语言收敛

新增/调整的 Gesture、Layout、Music CSS 与 Clock Host，使左右吸附、展开方向和移动端卡片边界保持更一致。v0.2 的核心成果并非把所有业务逻辑彻底抽象，而是建立了一个跨 Widget 复用的交互起点：拖拽、吸附、展开、长按、管理入口 使用同一组规则。

验证与发布状态

v0.2 交付了 demo、test-orbit.html、浏览器 IIFE 产物和 API/配置文档；差异范围约为 40 个文件、11,790 行新增、934 行删除。它实现了多组件 Runtime 的主体能力，但该阶段尚无 v0.3 引入的单元测试、产物校验脚本和 GitHub Actions CI。因此，其质量信号主要来自文档化的阶段验收和手动浏览器测试，而非自动化门禁。

兼容性与使用影响

场景	建议
已使用 Music/Clock 单文件	可继续使用独立包；不要与 `orbit.js` 同时引入
新接入多组件页面	使用 `dist/orbit.js`，并保留两份组件 CSS
桌面用户	默认使用 `Alt+O`，可通过 `ORBIT.launcherKey` 改写
移动用户	长按任意球体打开 Launcher；保持手势区域不被页面脚本抢占

风险与下一步

v0.2 的限制主要是 Runtime 仍以“注册 Host + 直接操作 DOM”为主，隐藏、销毁、重挂载的语义没有充分分离；当 PJAX、动态卸载或多个 portal 出现时，资源生命周期容易变得模糊。Music 与 Clock 的复杂度也存在明显差距，未来不宜一次性大改二者。

因此，最合理的下一步正是 v0.3 所采取的方向：先用 Clock 试点建立生命周期契约，再让 Music 接入 destroy、可见性目标和 portal 所有权，而不是在 v0.2 阶段继续堆叠视觉功能。

睡莲

2026-07-26T11:32:11.000Z

作品

选的是龙谱格三

临江仙

自是幽幽清雾里，琼楼日月相辉。
微风轻拂启朱扉。
不知何事过，此去恐难归。

泥泞池中邻腐藻，寂寥独放芳菲。
翩翩独着白纱衣。
悠悠开合念，心在便无违。

创作背景

家父在院子中种了一缸睡莲，用的是家里废弃的陶土缸，一直也未曾开花，近些天却展露了自己的芬芳

她的花瓣洁白，淡雅，在点点细雨下好似美人落泪，那种清幽淡雅，漂浮不定，是荷花所不可比拟的，而她昼开夜合的特性，更赋予了她一层新的内涵，周而复始，重复不断，放平心态，哪怕环境恶劣，也做自己

她的美丽仿若天上的仙子，本应在琉璃琼宫，淡雅薄雾之中，可却惨遭贬谪，但她却在黑暗中仍任保持自己，因为她本就知道自己不属于那里，哪怕无法回去，只要做好自己便可，这正是谪花（被贬谪成花的仙人）

毕竟不断地起落才是人生的常态，才是生活底色

多说无益，一切尽在词中，不言而喻

写在后边

这一次创作背景在后面，是刻意为之，我想让读者自己在词中品析，感受内涵，思想，而不是知道主题之后去词中找

念李华

2026-06-28T04:50:06.000Z

创作背景

致李华：

展信佳，见信如晤

自小升初的那个暑假，我与李华相识，当时一瞬间我便被她打动，不是因为幽默风趣，而是气质，她那种关心他人，明辨是非却又开朗的气质令我深深的折服

在这两年多的相处之中，我们对彼此都逐渐的了解，她经常为我们许下承诺，可是最后竟未能兑现，她说她会教到我们毕业，最终却食了言

在上一个寒假，我开始想华姐的解忧杂货店投稿，我从未想过我的投稿会被关注到，可华姐却十分认真的看完了，甚至他和我喜欢的作者都是一致的

后来我和她说的逐渐增多，从读的书，到自己的见解，再到自己写的诗词与经历，再到自己的内心，最后又落回了校园生活

我感觉你与我仿佛是亲密无间的，你是真正了解我的人。

你和我们常常展望未来，我也一直期盼着和你一起迈向更好的自己的未来

再最后的那节课上，我其实已经感觉到了什么，你今天的语气好似格外低沉，平静，欢喜也好似强颜欢笑，还放出了许多过去你和我们之间的回忆，我隐隐地感到不安

命运或许就是如此的造化弄人吧，我们家是养鸡的，在那一天，那一上午，那两个小时，一辆卡车轰隆隆的驶入了院中，仿佛是末日的咆哮要将这天地撕裂，人家来拉鸡了。

我们家的家庭条件并不宽裕，我便只好在艰难中做出了抉择，我放弃了你，选择去帮忙。

接下来似乎该说若我知道会这样的话一定不会那么选的，但我并不认可，时尚有一些是命中注定的，正是一次次的错过和失去使得我们的生活更加丰富多彩，若不是错过，我的悲痛或许也不会如此的缓慢而持久

对于人，有的课题是需要一生去解决的，以至于一生都解决不了，离别便是其中之一，离别啊，你总是充满悲情，却又在绝境中暗蕴希望

不过这或许也并不是坏事吧，你与我都在迈向更好的未来，都在实现曾经的承诺，不过是不再一起

我们的生活没有荧幕上的轰轰烈烈，只是琐事中的细水流长

愿你见到这封信

勿忘挂念

你的学生，国翔

内容

少年游·念李华

梨花承雨雨萧萧，悲悔上眉梢。提笔难言，望窗长叹，年少念难消。

敢问春风来何处，入骨别离刀。陌上相逢，悄然分散。独上月楼高

嘉豪说

2026-05-18T14:12:13.000Z

内容

今世之人，遇其不知之事，皆谓施者曰：“子，‘嘉豪’者也”疑之，问曰“何故言此？”对曰：“其行为吾所不知也，定为奇技淫巧，沐猴而冠、妄自尊大‌，何故不嘲邪？”呜呼，人之别于众者，何罪之有，闻此污秽辱耳之言，其真然也？

信乎，却有行者无实材（通“才”），为（四声，为了）人视之所为（二声，做）。但此非辱人之故。不知而言余人少知（通“智”，下同）者，实少知也。

人之立于世之本，乃言其所知，学其不知，正其错知，而非不知、错知亦言，闻逆耳（指忠言）而不悔。子曰：“知之为知之，不知为不知，是知也”，言即此也。

p.s:括号为注释

创作背景

日常中，嘉豪一词被渐渐滥用，观现象有感，故言此。思想可看第一篇文章

题解GESP202603五级有限不循环⼩数

2026-05-17T05:20:30.000Z

先说结论，这是一道与唯一分解定理有一定关系的题目

Part 1 分析题面

若题目说若 $\frac{1} {a}$ 可化为一个有限的，不循环的小数，则称 $a$ 为终止数。

看到分数，自然而然地联想到唯一分解定理，那我们分解后再看怎样才能确定 $\frac{1} {a}$ 是有限小数。

Part 2 证明

显而易见，只要一个分数可以化成 $\frac{k}{10^N}$ ( $k$ 为整数)的形式，那么它就是一个有限小数。那我们的目的就变成了证明 $\frac{1}{a} = \frac{k}{10^N}$

如果说 $a$ 在分解质因数后只有 $2$ 和 $5$ 两个质因数，即当 $a = 2^m \cdot 5^n$ 时，则 $\frac{1} {a}$ 是有限小数，其他都是无限小数。

1.结论一：当 a=2^m·5^n 时，则 1/a 是有限小数

1. m>n

当 $m>n$ 时，我们需要补齐 $5$ 的个数。给分子和分母同时乘以 $5^{m-n}$ ：

$\frac{1}{2^m \cdot 5^n} = \frac{1 \cdot 5^{m-n}}{2^m \cdot 5^n \cdot 5^{m-n}} = \frac{5^{m-n}}{2^m \cdot 5^m} = \frac{5^{m-n}}{(2 \cdot 5)^m} = \frac{5^{m-n}}{10^m}$

2. m

当 $m$ 时，我们需要补齐 $2$ 的个数。给分子和分母同时乘以 $2^{n-m}$ ：

$\frac{1}{2^m \cdot 5^n} = \frac{1 \cdot 2^{n-m}}{2^m \cdot 2^{n-m} \cdot 5^n} = \frac{2^{n-m}}{2^n \cdot 5^n} = \frac{2^{n-m}}{(2 \cdot 5)^n} = \frac{2^{n-m}}{10^n}$

3. m=n

当 $m=n$ 时，分母已经是 10 的幂：

$\frac{1}{2^m \cdot 5^m} = \frac{1}{10^m}$

在上述所有情况中，分数 $\frac{1}{a}$ 最终都可以写成如下形式：

$\frac{1}{a} = \frac{K}{10^N}$

其中 $K$ 是一个整数， $N = \max(m, n)$ 。

根据十进制计数法的定义，任何除以 $10^N$ 的整数，其结果就是在该整数的末尾向前移动 $N$ 位小数点。因为 $K$ 是一个有限长度的整数，所以移动小数点后的结果必然是一个有限小数。

2.结论二：当不满足 a=2^m·5^n 时，则 1/a 不是有限小数

容易想到，如果说里边有一个其他的质数，则经过任意次操作，分数都不能写成 $\frac{k}{10^n}$ 的形式。

Part 3 编写代码

既然已经有了证明，那代码就简单多了，只需将 $L$ 到 $R$ 中的数一一对比是否有 $2$ 和 $5$ 之外的质因数数就可以了。

AC代码

#include
using namespace std;
int l,r,ans;
int main(){
    cin>>l>>r;
    for(int i=l;i<=r;i++){
        int a=i;
        while(!(a%2))a/=2;
        while(!(a%5))a/=5;
        if(a==1)ans++;
    }
    cout<
}

p.s 本人就是今年三月考五级，当时定式思维了，以为涉及到质数的就用筛法，写的超麻烦。回家又看了一下，不禁感叹当时的自己怎么这么蠢。

少年游·秋悲

2026-05-17T00:30:37.000Z

浣溪沙·玉树垂枝立雪兰

2026-05-16T07:23:50.000Z

创作背景

春意渐渐漫过严寒的冰障，为校园带来了许久不见的生机，校园中时常被我忽略的玉兰不知何时竟开了花

洁白的玉兰挺立枝顶，直面着春暖与冬寒的碰撞，没有绿叶的衬托，只有孤零零的一朵花，显得如此高雅洁白

哪怕是春日的微风拂过，他也会大片大片的落下花瓣，花瓣覆满了整个甬路——不，或许应该说是甬路上长出了一片花瓣。他们虽在地上，却仍然燃烧自己的生命，散发出属于自己的香

不为别的，只为证明

内容

浣溪沙·玉树垂枝立雪兰

玉树垂枝立雪兰，春风裹暖给人欢。试问谁可胜其端？

花落缤纷香满径，傲然枝顶胜春寒。冰肤玉骨仅花单。

写在后面

这是一份过期的博客，创作背景是凭借记忆来写的

对周围事的看法

2026-05-16T04:09:12.000Z

理论：自律的逆天性

此理论并非指你在这方面不可能自律，而是说一个人如果一方面自律，则它几乎是必然的要去在另一方面不自律，因为他心中的情绪，欲望需要发泄，除非说是他在自律之中可以发泄，但这很难

现状及原因

现状

事实上，我一直感觉我与周围的人格格不入，周围的人的人品、道德规范、思想、思考方式与内容都显得不像是一个正常的学生，正常的人的行为。周围的人也是满口脏话，黄话，真的不知道到底是在想什么。

风气越来越差，尤其是低龄的孩子也开始了用脏话，疾病，用他人的痛苦来逞口舌之快，来填补自己内心的空缺，排解自己的情绪。而手机逐渐走向低龄化，这与现状有很大关系

这个社会的道德水平也在不断下降，暴力行为逐渐增多

在生活中，我会看到我们周围的人在捉弄，在欺负一些生理有缺陷的人

原因

对于网络与手机，我们需要在玩耍中间找到平衡点，因为网络的确是鱼龙混杂，甚至现在的网络几乎被低质，恶俗，冷漠，不良价值观所占据，周围的人满口脏话，黄话，与网络，与人的欲望是有很大关系的，根据自律的逆天性，我们需要有一个出口发来发泄，而现在的人难以找到发泄的渠道，只得向外通过辱骂，低质的内容来产生廉价的快乐，无法向内求所。

而风气越来越差，低龄的孩子用脏话，疾病，用他人的痛苦来骂人的原因，我思来想去，最终觉得还是离不开欲望与网络，网络使社会的联系速度加快，但同时也让不良的价值观，精神，道德与说话方式快速传播，而欲望则允许人们在一个词被平台禁用之后又继续需源源不断地使用更加隐晦，更加令人难以想象的词语来骂人，他们会为了口舌之快，挖空心思地去寻找更为生僻的，承载着他人痛苦的词语去骂人，他们不会想到人们的痛苦，只会发泄自己情绪，于是便形成了恶性循环，而小孩的善恶观念有几乎为零，他们便会学区这些词语来骂人，最终社会的风气也逐渐变坏，在这个过程中，孩子事实上是受害者。

现在的校园问题还有一个原因，就是权力分配不合理，或者说权威。正常而言应该是由老师去管教约束学生，但现在老师的能力——或者说权力变小（因为盲目的关注孩子的感受），学生权力变大（家长的撑腰，维护，胡搅蛮缠），这边导致了老师管不住学生，风气日益下降的原因

其实客观来说，这是必然的，根据热力学第二定律，一个封闭系统中的物体终将从有序趋向于无序，我们只能通过外部的力量来矫正内部，但是我们与外部又共同属于一个更高维度的封闭系统，所以趋于无序是必然的。（好像有一些牵强）

每当我看到有人被欺凌时，我就感到十分的痛心，我理解了欺凌者渴望的权力与高贵，更同情被欺凌者的无辜。欺凌者所渴望的本质其实还是欲望，他们渴望优越感，期望通过打压，欺凌他人的方式来突显出自身的高大，这种情感是我所理解却不提倡的

在我心中，这个社会是从小孩开始烂的，我之前也提到了善恶观念弱等等等等，但同时，还有一个现实的问题，他们会长大，然后接替这个社会的治理，我简直是无法想象社会将变成怎样（也可能是我太悲观）

见解

在我的心目中，真正高大的人从不会是张扬者，他们往往会使不起眼的那个，但是他们的高大正是体现在他们的和，他们的怜，他们的勇与他们的义，他们不会急于去表现自己，而是会默默的发展，去培养自己的花

但是我们并不该因为社会的不断变坏而放弃改变，我们应该去尽自己的努力，尽量的延缓，减慢这个转变的速度

一些题外话

有一个说法，是人的一切行为都是为了利益，但是我认为不对，我认为是每个人的行为都可以从为了利益的角度来解读

我有的时候在思考，什么时候才能达到人人平等，最终我得出的结论是，当总统（主席）像我们平常的工作，比如推销啊，教师啊之类的，所受到的待遇，尊敬（主要指对待的态度）一样时，我们的社会才可能平等

我最喜欢的文言文是逍遥游，滕王阁序，阿房宫赋，琵琶行，这几首我都背过了，说来也怪，这些都是我的课外积累，但是在没有资料的情况下读的时候却可以理解她的意思，哪怕一句里有几个字无法准确翻译，但是我却能抓住它的神，理解他的情

而我最喜欢的词人，则是李煜和晏几道，我在诗词的海洋，在古人的故事中沉醉，那种美，那种感觉是语言无法表达的，就像翻译古文，翻译出来往往却失了神，最典型的就是“大漠孤烟直，长河落日圆”虽用字质朴，却让人读完自然出现一幅边塞黄昏图

我其实读的书也与现在的人格格不入，我读《小王子》《长安的荔枝》《乡土中国》，东野圭吾的《白夜行》《恶意》《嫌疑人X的献身》《解忧杂货店》，《白鹿原》《活着》《明朝那些事》，《寂静的春天》《王阳明全解》和《论语》及论语的解析，译注

写在最后

~~这不过是一个初二生从小学到初中的胡思乱想的不完全集合罢了~~

苹果派的小站 | 博客

Orbit 通向 v1.0 的长期方案：从 Runtime 代码到兼容性网络

Orbit 通向 v1.0 的长期方案：从 Runtime 代码到兼容性网络

一、长期目标：v1.0 不是“大版本”，而是“可被依赖的承诺”

二、不可替代性的正确模型

三、v1.0 的产品边界

四、通向 1.0 的阶段路线

4.1 v0.4：证明“Contract 可以存在”

4.2 v0.5：证明“外部人可以使用 Contract”

4.3 v0.6：从“API 集合”成为“互操作协议”

4.4 v0.7–0.9：证明“生态可以安全地演进”

五、1.0 的技术架构标准

5.1 Core 的稳定职责

5.2 Widget 的稳定权利与责任

5.3 安全与隐私底线

六、生态策略：先验证“被采用”，再追求“规模”

七、版本与治理政策

八、衡量进展的指标

九、v1.0 的 Go / No-Go 门槛

Go：可以发布 v1.0 的条件

No-Go：应继续停留在 0.x 的信号

十、结论：让 Orbit 值得被替代之前先值得被依赖

参考资料

Orbit-v0.3更新报告

Orbit v0.3 更新报告

发布范围

主要更新

1. 生命周期成为正式契约

2. Host adapter 与 Clock 试点

3. Music 接入新边界

4. Launcher 的可访问性和移动端恢复

验证与质量信号

兼容性与使用影响

已知限制与建议

Orbit-v0.2更新报告

Orbit v0.2 更新报告

发布范围

主要更新

1. 新增 Orbit Runtime 与多 Widget 发布物

2. Launcher：解决多组件可管理性

3. 交互与布局向共享语言收敛

验证与发布状态

兼容性与使用影响

风险与下一步

睡莲

作品

创作背景

写在后边

念李华

创作背景

致李华：

内容

嘉豪说

内容

创作背景

题解GESP202603五级有限不循环⼩数

Part 1 分析题面

Part 2 证明

1.结论一：当 a=2^m·5^n 时，则 1/a 是有限小数

1. m>n

3. m=n

2.结论二：当不满足 a=2^m·5^n 时，则 1/a 不是有限小数

Part 3 编写代码

少年游·秋悲

浣溪沙·玉树垂枝立雪兰

创作背景

内容

写在后面

对周围事的看法

理论：自律的逆天性

现状及原因

现状

原因

见解

一些题外话

写在最后