本篇文章主要讲解词境应用的开发过程中涉及到的问题以及相关的思路方法。先看一下项目相关截图。app.json注册路由和 Worker，app.js处理应用生命周期，.ink页面编排状态，wordIndex提供可复现的本地结果，focus和speech适配穿戴设备输入与宿主能力，服务层把推送保持为可选增强。

诗境」的刷卡页把一整个年级的诗铺成一叠牌：当前那张居中、左右各露一角，手指划过 100vp 就翻到下一张。这个「牌堆」不是真正的列表容器，而是 111 个（或某个年级的十几二十个）卡片组件按算出的三组几何参数同时叠在同一个Stack里。五个常量决定了它看起来像不像一叠纸。前三个是几何，第四个是动画时长，第五个是手势阈值。它们全部是模块级常量，不在组件里 —— 这五个数字是这套交互的「设计参数」，改

诗境」把全部用户数据压进一张 Preferences 表、八个键，每次写操作把八个键全量刷一遍。这个看起来很粗暴的策略配合一个readOnly开关，恰好解决了元服务最麻烦的一类问题：桌面卡片在另一个进程里也要读同一份数据，而它绝不能把旧快照写回去。

朗读这件事在「诗境」里只有 164 行代码，却要处理三类问题：引擎什么时候可用、一段话什么时候真正念完、三个页面怎么知道「现在是不是在念」。答案分别落在启动页的串行初始化、requestId过滤加type === 1判定、以及一个共享布尔键配 300ms 轮询上。

诗境」的等级没有一个字段存在磁盘上 —— 它由「已学会多少首」实时算出来，只在升级发生的那一刻往磁盘写一个「上次已知的等级索引」用于比较。这套设计让等级永远不可能与学习记录脱节，代价是每次都要重新扫一遍区间表。

诗境」在桌面放了两张卡片：2×2 的学习进度卡和 4×4 的每日一诗卡。它们跑在这套推送机制加上卡片的被动接收方式，构成了这一整套「双通道」。

三条并存不是为了保险起见，而是各自覆盖一种另外两条盖不住的场景 —— 搞清楚哪条在什么时候生效，比记住「用了 @Monitor」有用得多。

一个 25 个文件的元服务，视觉规范最后浓缩成三个常量类：11 个颜色、3 个尺寸、4 套卡片主题。有意思的不是它们定义了哪些值，而是哪些值被真的复用了、哪些只是写在文件里没人引用 —— 这两者的差别恰好说明了「什么该抽成常量」。

这个项目把「状态放哪里」这件事交给了：用户的学习数据不是散在页面里的@State，而是一个带@Trace字段的全局对象，页面用@Local持它的引用，用@Monitor监听它里面的字段。只有 35 行，除了什么都没做，所有初始化被搬到了启动页。25 个文件、4035 行，按九组目录切开，依赖方向是一条从页面指向服务的直线。

词库是一份 59518 字节的poems.json，111 首课本必背诗，按六个年级、上下两册组织。在启动时把它解成内存里的三份结构：保留原始层级的、扁平化的allPoems、按 id 查的poemMap。三份结构指向同一批数据但对象来源不同，这个差别直接决定了「哪些方法能用在哪些对象上」。