企业官网建设流程全解析

Folo 桌面端 v0.6.1 版本解析：Actions 导入导出、个人主页资料档案与视频时长规则条件

【免费下载链接】follow🧡 Folo is the AI RSS Reader项目地址: https://gitcode.com/GitHub_Trending/fol/follow

本文以 Folo（AI RSS Reader）桌面端 v0.6.1 发布说明为骨架，结合仓库源码（packages/internal/store/src/modules/action、packages/internal/shared/src/auth.ts等）逐项拆解该版本引入的 Actions 导入/导出能力、个人主页资料字段扩展、以视频时长为代表的新增 Action 规则条件，以及数据库迁移恢复等稳定性修复背后的实现原理。读完本文，你可以掌握 Folo Actions 规则的数据结构与迁移格式、导入校验规则，并理解个人资料字段与媒体时长过滤条件的底层建模方式。

版本背景与概要

v0.6.1 是 Folo 桌面端在 Actions（自动规则）能力快速演进期间的一次重要发布。从内容分布看，它同时覆盖三类工作：

• Shiny New Things（新能力）：Actions 导入/导出、个人主页补充 bio/website/social links、支持上传头像、视频时长作为 Action 条件；
• Improvements（体验优化）：个人主页、Actions 页、RSSHub 页视觉重构，条目工具默认命令简化，统一本地数据库试验性灰度上线等；
• No Longer Broken（缺陷修复）：数据库迁移失败后的自动恢复、macOS Docker 构建未读数清零、TTS 失效等。

下文按"功能落地 → 界面优化 → 稳定性修复 → 试验性架构演进"的顺序展开，重点给出可在源码中验证的依据路径。

Actions 规则导入与导出：从 UI 到存储层的完整链路

导出/导入的源码实现

v0.6.1 最核心的新能力是 Actions 的导入与导出。它的底层逻辑位于@follow/store的 store.ts，关键方法为：

• exportRules(): string（store.ts）：从useActionStore.getState().rules读取当前全部规则，仅抽取规则的name、condition、result三个字段，组装为一个带元信息的 JSON 字符串返回；
• importRules(jsonData)（store.ts）：对传入 JSON 做逐层结构校验，通过后整体替换本地规则并置isDirty = true。

实际导出的 JSON 结构（由exportRules源码确认）为：

{ "version": "1.0", "exportDate": "2025-01-01T00:00:00.000Z", "rules": [ { "name": "My Action", "condition": [], "result": {} } ] }

exportDate使用 ISO 8601 格式（new Date().toISOString()）。导入时只消费rules数组，因此该结构同时承担了版本元信息与可迁移数据的职责。

导入校验规则

从 importRules 的实现可以看到三层校验，这是把"可复制迁移的规则集"做成可靠特性的关键：

1. 顶层必须有rules且为数组，否则返回Invalid JSON structure: missing or invalid rules array；
2. 逐条校验每条规则：name必须是字符串、condition必须是数组、result必须是对象，否则返回对应的Invalid rule: ...错误；
3. 全部通过后，将规则按数组顺序写入index，调用immerSet原子地替换state.rules，并返回成功消息Successfully imported N action rule(s)与importedCount。

值得注意的是，导入采用的是整体替换而非增量合并——导入成功后本地原有的 Actions 规则将被这批新规则替代。若你的迁移意图是"合并两套规则"，应在导入前先通过导出功能做好原规则备份。

桌面端 UI 的四种迁移入口

渲染层入口在 action-setting.tsx，结合useContextMenu与上下文菜单呈现多条迁移通道：

• 导出到文件（L177-L182）：调用actionActions.exportRules()后用downloadJsonFile下载，文件名由 utils.ts 中的generateExportFilename生成，成功时toast提示Action rules exported successfully as <filename>；
• 从文件导入：用selectJsonFile选择 JSON 文件后调用actionActions.importRules(jsonData)；
• 导出到剪贴板 / 从剪贴板导入：通过copyToClipboard与readFromClipboard两条通道配合（L207、L226），适合在桌面端之间快速共享单条规则。

这套能力使 Actions（例如"标题含某关键词则标记为已读并归档"这类规则）可以从一台设备完整迁移到另一台，也方便在社区/团队之间以 JSON 文件形式分享。

佐证：store 层的核心方法有对应的单元测试覆盖，见 store.test.ts，其中验证了默认新建规则（空condition、空result）以及删除/新增后index的稳定性；rule-card.test.tsx 覆盖了规则卡片的渲染逻辑。

个人资料档案：bio、website、socialLinks 与头像

v0.6.1 为个人主页补充了自我介绍、个人网站与社交链接等字段，并支持上传头像，同时为部分资料字段加入了长度限制。从数据结构看，这些字段是账号体系中"可选补充资料"的一部分。

客户端 SDK 侧通过 better-auth 的inferAdditionalFields注册（见 auth.ts）：

inferAdditionalFields({ user: { handle: { type: "string", required: false }, bio: { type: "string", required: false }, website: { type: "string", required: false }, socialLinks: { type: "json", required: false }, }, })

可以看到bio、website为可选字符串；socialLinks被建模为json类型字段，即可容纳多个社交平台链接的结构化数组，而handle（用户名标识）与头像资源共同构成个人主页的身份信息基础。桌面端共享 SDK 的该类型声明同样约束移动端，因此字段语义在双端保持一致。

新增 Action 规则条件：视频时长与媒体时长

Actions 的"条件（condition）"决定一条规则作用于哪些条目。v0.6.1 新增了以视频时长作为条件的能力。从字段注册表 constant.ts 可以清晰看到相关的两个数值型（type: "number"）过滤字段：

其中entry_attachments_duration正是"视频时长"条件的落点：RSS 条目中的视频附件时长（秒）一旦作为可比较的数值字段暴露给 Actions，就可以组合数值型操作符（is equal to/is not equal to/ 大于、小于等）构造诸如"视频时长大于 20 分钟则自动标记稍后观看"之类的规则。

该版本的操作符体系同样定义在 constant.ts，从源码可确认的几种操作符类型包括：contains、not_contains（文本匹配）、eq、not_eq（数值/文本/view/status 通用比较）等。规则模型本身（name + condition[] + result）与exportRules导出的字段一一对应，意味着含时长条件的新规则同样可被完整导入导出。

界面与交互优化

个人主页、Actions 页与 RSSHub 页重构

• 个人主页在资料字段扩展后采用了全新视觉样式，bio/website/socialLinks等字段（auth.ts）以更清晰的排版呈现；为保证视觉一致性，部分资料字段新增了长度限制，与发布说明中的描述一致；
• Actions 页重构（commit1ace5ea）：Actions 编辑/管理入口集中在渲染层 modules/action 目录下，包含action-setting.tsx、rule-card.tsx、when-section.tsx（条件编辑）、then-section.tsx（动作结果编辑）与rule-summary.ts（规则摘要）等模块，重构后规则卡片与导入/导出入口的层级更清晰；
• RSSHub 页重构（commitf9aca60）：与订阅源发现流程配套的界面调整。

条目工具默认命令简化与文案增强

发布说明提到"简化条目工具中的默认命令"（commit85122fb）以及增强 UI 标签与描述的可读性（commit2ed9f70），其 i18n key 大量集中在actions.action_card.*命名空间下（见 constant.ts 中的filterFieldOptionsMap标签引用方式），这类"标签即文案 key"的设计使后续文案统一调整的成本更低。

细节打磨：图片预览与 Toast

• 图片预览样式（commitcf72753）：与渲染层媒体组件（如components/ui/media）的展示样式调整相关；
• Toast 通知精修（commit73f8011）：桌面端采用sonner的 toast 体系（action-setting.tsx中导入toast即为佐证），成功/失败反馈的视觉细节得到统一。

稳定性修复：从数据库迁移到跨端同步

v0.6.1 修复列表体现了对"数据可靠性与跨端一致性"的重视：

• 数据库迁移失败后更可靠的自动恢复（commitc2e0c3d）：桌面端本地库结构演进（本版本正逐步引入统一本地数据库）依赖可重入的迁移机制，失败后的自动恢复是保障用户数据不丢失的关键防线；
• 修复 macOS Docker 构建中未读数不清理（commit70255af）：属于特定构建形态（Docker + macOS）下未读计数状态不同步的问题；
• 修复初始加载期间显示旧条目（commit24ae065）：与时间线/订阅源首次拉取时的竞态条件相关；
• 修复以.开头的链接处理（commitde8eac8）：涉及 URL/相对路径解析边界情况；
• 修复文字转语音（TTS）不可用（commit82952b0）：多媒体条目朗读能力回归；
• 修复 star/unstar 状态跨设备不同步（commitfbd0b3）：涉及收藏状态的服务端同步链路。

说明：以上条目以官方发布说明（0.6.1.md）为准逐条对应；若需深入某一具体修复的代码，可在仓库内按对应功能模块（如播放器atoms/player.ts、条目上下文菜单等）继续追查。

试验性架构演进：移动端与桌面端统一本地数据库

发布说明特别标注了"为移动端和桌面端逐步灰度统一的本地数据库"（内部讨论编号 #3897、#3902）。这表明该特性当时处于试验性灰度阶段而非全量可用。仓库中与之对应的架构文档可见于：

• docs/superpowers/plans/2026-04-11-desktop-ota-unification.md
• docs/superpowers/specs/2026-04-11-desktop-ota-unification-design.md

方向上是让桌面端与移动端共享同一套本地数据存储与同步语义，从而减少"每个端各维护一套状态"导致的跨端一致性问题。作为渐进式发布，建议在实际使用中关注版本更新说明中的灰度开关与反馈通道。

如何验证或体验 v0.6.1 的功能

1. 在桌面端升级到 v0.6.1 后，进入Actions设置页，在空规则/已有规则卡片上找到上下文菜单中的导入/导出入口，可尝试导出 JSON 后再导入以验证往返一致性；
2. 编辑个人主页资料，填写bio、website与社交链接并上传头像，观察新主页样式的展示效果；
3. 新建一条 Action，在条件字段中选择与媒体时长相关的选项（对应entry_attachments_duration/entry_media_length），配合数值操作符验证"视频时长条件"是否生效；
4. 若你的使用场景涉及 macOS Docker 构建、TTS 朗读或跨设备 star 同步，请对照本版本的修复列表回归验证。

后续版本动态可在 apps/desktop/changelog 目录中继续查阅（例如 0.6.2.md、0.6.3.md 以及 next.md），以便跟踪 Actions 与统一本地数据库的后续演进。

【免费下载链接】follow🧡 Folo is the AI RSS Reader项目地址: https://gitcode.com/GitHub_Trending/fol/follow