换电脑第一件事：重新登录，把书签、插件、打开的标签页一样一样搬过去。Chrome 自带同步常年掉线，Floccus 只搬书签，xBrowserSync 依赖别人服务器。AI 时代书签本身都不重要了，已打开的标签页和浏览历史才是你的工作现场。
TL;DR
- Konode 是开源（MPL-2.0）浏览器扩展，同步书签 / 打开标签页 / 历史 / 扩展 4 类数据，直接写进你自己的存储（WebDAV、Nextcloud、GitHub、Google Drive、pCloud、Koofr、Fastmail），无任何 Konode 账号
- 支持可选端到端加密（AES-256-GCM）：加密开，存储商只能看乱码；加密关，存储商能读明文
- 后端选 GitHub 时每次同步产生一个 commit，可人工 diff / 回滚——书签的"版本管理"
- 不搬密码、不搬 Cookie；密码走 KeePass / Bitwarden，是 Konode 有意的设计取舍
- 4 种冲突策略，推荐"最后一次写入为准"；1.3.0 版 Firefox 有 WebDAV bug，1.3.1 修复但未发布，可源码编译临时用
为什么浏览器自带同步不顶用？
Chrome 自带同步的逻辑是：所有数据进 Google 服务器，换设备登录 Google 账号拉回来。听着简单，实际三座坑：
| 坑 | 实际表现 |
|---|---|
| 跨浏览器不通用 | Edge 用微软账号同步，Chrome 用 Google，两套体系互相不通。同一公司电脑（Edge）与家用电脑（Chrome）之间搬不了 |
| 同步范围受限 | 打开的标签页只在"来自其他设备"里露个脸，历史同步受口令限制，扩展个性化配置基本不归它管 |
| 数据去向 | 全部落 Google / Mozilla 服务器。对自托管党、隐私敏感用户，这是直接否决理由 |
Floccus、xBrowserSync 这类第三方工具解决了"跨浏览器"，但只搬书签，而且依赖各自的同步服务器（国外服务器国内常连不上）。
Konode 的思路反过来：没有 Konode 服务器，数据直接写进你指定的存储，自己端对端加密。
Konode 到底搬哪些数据？
安装扩展后按向导配置。同步范围分两类：
- 默认同步：书签（完整文件夹结构，增删移动重排都跟）
- 可选开启（各需单独确认）：已打开的标签页（会话快照，换设备一键恢复）、浏览历史（同步 + 去重）、扩展列表（只显示"这台设备缺哪些扩展"，不会远程安装扩展）
注意两点边界：
- 不搬密码、不搬 Cookie、不搬表单数据。Konode 定位是"浏览器场景同步"不是"凭据管理"，密码请交给 KeePass / Bitwarden / 系统钥匙串。
- 打开标签页恢复是"快照"——新设备不会自动帮你把 142 个标签全打开，是你自己点恢复。青小蛙在 appinn 那篇实测里就吃过这亏：“一不小心就让 Firefox 一次性打开了 142 个标签页，一个一个关掉累死人”。
后端怎么选？我踩过的账本
Konode 的存储后端有 7 类官方卡片 + 1 类通用 WebDAV：
| 后端 | 特点 | 我实测 / 调研结论 |
|---|---|---|
| WebDAV（通用，含 Synology / kDrive / 任意自建） | 走 WebDAV 端点，NAS 党最顺手 | 配 app password（开 2FA 时尤其重要），别用主账号密码 |
| Nextcloud / ownCloud | 走 WebDAV，文件落你已有服务器 | 同上，建议 app password |
| Google Drive | 只申请 drive.file 窄 scope，只能碰 Konode 自己创建的文件 |
不想为同步专门开网盘的话最省事 |
| GitHub | 指定单个私有仓库 + fine-grained token，每次同步 = 1 个 commit | 书签天然带版本历史，可 diff / 手动回滚，极客向；仓库必须私有 + 加密开 |
| pCloud | WebDAV 端点粘进去，写进一个文件夹，不动其余 Drive | 欧洲 / 美国机房可选 |
| Koofr / Fastmail | 各自 WebDAV 端点 | 已有服务直接复用 |
我个人排序：有 NAS 走 WebDAV（app password）> 极客向走 GitHub 私有仓 + 加密 > 只想省事走 Google Drive（drive.file scope）。
加密开关，决定谁看得到你的数据
Konode 的加密是可选的，在设置向导里选，选完之前不会上传任何数据。开 AES-256-GCM 后，存储端只能看到密文——appinn 实测把书签同步到 Koofr 开了加密，文件在网盘里直接是乱码。
三方能碰到你的同步数据，权限表长这样：
| 参与方 | 加密关 | 加密开 |
|---|---|---|
| 你自己（任意已登录设备 + 你设的口令） | 可读 | 可读 |
| 存储商（Google / GitHub / 你的 WebDAV 服务器） | 可读明文 | 只读密文 |
| Konode 扩展本身（开源可审计） | 经手明文 | 经手，但本地加密后出去就是密文 |
凭据（存储账号 token）存在浏览器扩展存储，不出设备。
同步冲突怎么解？
Konode 提供 4 种冲突策略，设置里可选。最常用：最后一次写入为准（last-write-wins）——两台设备同时改同一书签，时间戳晚的赢。其他策略（合并、手动、保留本地等）适合多设备重度编辑书签的场景，日常单主力机不用纠结。
书签同步是自动的，几乎实时（本地变更后等待几秒再上传，避免频繁操作打爆后端）。
当前版本的坑（2026-09）
- Firefox 1.3.0 有 WebDAV bug：任何配置都会报"未获得访问 WebDAV 服务器的权限"。1.3.1 已修复但未发布。变通：源码
git clone https://github.com/konabe-studio/konode.git && npm install && npm run build:firefox，产物dist-firefox/在about:debugging里"临时载入附加组件"指manifest.json。 - 不加密 + 公开仓库 = 你的书签 / 历史明文躺在 GitHub，选 GitHub 后端务必私有仓 + 加密开双保险。
- Chrome 商店评分 5.0（6 ratings），项目还早；扩展本身开源 MPL-2.0，代码可审计。
常见问题
Q1: Konode 能同步密码吗？
A: 不能。它只同步书签、打开标签页、历史、扩展列表。密码和 Cookie 归凭据管理器（KeePass / Bitwarden / 系统钥匙串），这是有意的设计边界。
Q2: 和 Chrome 自带同步最大区别？
A: 数据不进 Google 服务器，直接写你指定的存储（WebDAV / GitHub / Drive 等），可选端到端加密，且支持 Chrome 与 Firefox 跨内核互相同步——Chrome 自带同步做不到跨浏览器。
Q3: 和 Floccus / xBrowserSync 比呢？
A: Floccus / xBrowserSync 主要搬书签（xBrowserSync 能加描述标签），Konode 额外搬打开标签页、历史、扩展列表；Floccus 也支持 WebDAV/Nextcloud/Git 后端，但 Konode 的 GitHub commit 版本历史 + 可选全量加密是差异化点。只在意书签、已有 Floccus 就够用。
Q4: 需要注册 Konode 账号吗？
A: 不需要。也没有 Konode 云端服务器。你只配置自己的存储后端，数据全在自己手里。
Q5: 换设备后打开标签页会自己弹出来吗？
A: 不会。会话以快照存储，在新设备手动点"恢复"才打开。建议恢复前先看一眼快照里有多少标签，避免一次性铺开上百个。
Q6: 我只有公司电脑 + 家里电脑，没 NAS，最省事方案？
A: 装扩展 → 后端选 Google Drive（自动申请 drive.file 窄权限，只碰 Konode 建的文件夹）→ 开加密。两台设备装同一扩展、登同一 Drive，完事。
Q7: 142 个标签页事故是我一个人的问题吗？
A: 恢复标签页是"全量打开"语义，快照存多少恢复多少。大快照先挑着恢复，或者平时就清一清标签页。appinn 原文作者实测踩的就是这个。