数据存储与同步变化
Quicker V2 重做了本地存储和云同步。目标不是简单更换数据库组件，而是把原来边界较大的数据拆成可独立保存、同步、冲突处理和恢复的数据项。
1.x 存储方式的局限
在 1.x 中，一个动作页通常以完整 JSON 保存，动作内容也依赖 Data、Data2、Data3 等字符串字段表达不同参数。
这种结构会让动作内容、页面位置和特定功能格式相互纠缠。只修改一个动作或一个位置，也可能需要更新更大的数据对象。
不同触发方式还把执行内容分散保存在用户设置、通用设置和程序设置中，难以形成一致的引用、删除和冲突处理规则。
V2 的账号隔离存储
V2 为每个账号建立独立的数据目录。业务数据、本机状态、缓存、日志和临时文件有明确边界，切换账号时不再共用同一份账号业务库。
正式环境的账号目录大致按下面的方式组织：
Quicker 数据目录
├─ global 全局设备与登录会话信息
└─ account
└─ 账号标识
├─ data 账号业务数据和本地历史
├─ states 账号本机状态
├─ cache 可重建缓存
├─ logs 账号相关日志
└─ temp 临时文件
目录结构属于实现细节，未来可能调整。备份和恢复应优先使用 Quicker 提供的同步、导出及恢复入口，不要只复制某一个数据库文件。
数据拆成独立项目
V2 的同步存储以独立数据项为基本单位。动作、动作页、程序场景设置、文本指令和公共子程序等可以分别更新。
这会带来几个直接变化：
- 编辑动作正文时，不必同时改写所在动作页；
- 调整页面或面板位置时，不必重写动作正文；
- 同步冲突可以定位到更具体的数据项；
- 删除、历史备份和引用检查可以围绕稳定 ID 进行；
- 大内容可以和元数据、引用关系分别处理。
动作本体与使用位置分离
V2 中，一个动作有独立的动作本体。动作页槽位、新面板场景、快捷键和其它触发入口保存的是位置或引用关系。
因此，同一个动作可以被多个入口使用。编辑动作本体后，各入口会看到同一份新内容。
不同操作的影响如下：
| 操作 | 影响 |
|---|---|
| 从当前场景移除 | 只删除当前新面板场景中的位置 |
| 从动作页移除 | 只删除对应动作页槽位 |
| 移动到其它场景 | 改变场景位置，不复制动作正文 |
| 同时添加到其它场景 | 增加一个位置，继续引用同一动作 |
| 删除动作 | 删除动作本体，并按确认结果处理相关引用 |
详细的面板整理规则见新面板窗口常见问题。
新同步体系
V2 使用新的同步协议和本地同步状态。每个数据项记录自己的版本、修改标识、删除状态和待上传状态。
同步过程可以区分首次拉取、上传本地修改、应用远端变化及冲突处理。发生冲突时，不应直接用一端数据静默覆盖另一端。
服务端数据整体换代或用户执行重新迁移后，客户端会要求“用服务端数据重建”。该操作会以服务器数据重新建立本机账号数据，不会自动合并尚未上传的本地修改。
从 1.x 迁移时会发生什么
V2 使用自己的本地数据空间和云端数据结构。首次初始化时，会拉取或迁移当前账号的 V2 数据，再建立本机运行所需的数据。
迁移应尽量保留动作 ID、动作内容、动作页、公共子程序和已支持的设置。无法完整转换的旧动作或参数，应保留兼容数据或以只读方式呈现，而不是静默丢弃。
迁移前建议：
- 在最后使用的 1.x 客户端执行一次同步；
- 导出特别重要或难以重建的动作；
- 记录常用动作页、公共子程序和复杂触发规则；
- 关闭其它设备上的 Quicker，避免迁移时继续写入旧数据；
- V2 首次同步完成后，再逐项检查结果。
1.x 和 V2 不会持续双向同步
一次迁移完成后，1.x 和 V2 不是同一个持续双向编辑空间。继续在 1.x 修改数据，不应假定这些变化会自动进入 V2。
同样，V2 中的新面板分组、场景位置和新版动作参数，也无法完整反向写回 1.x。
如果确实需要暂时保留 1.x，请指定一个版本作为主要编辑端。另一版本只用于查看或应急运行，避免两边同时改同一个动作。
备份和回退边界
V2 的数据不能通过简单替换 1.x 的 quicker.db 完整恢复。两代产品的模型、同步状态和账号目录均不相同。
安全做法是同时保留：
- 迁移前的 1.x 数据备份；
- 关键动作和公共子程序的导出文件；
- 已正常同步的 V2 云端数据；
- V2 提供的动作历史或数据恢复记录。
需要回到 1.x 应急使用时，不要把 V2 数据目录直接覆盖到 1.x。应使用迁移前备份，或导出 V1 兼容格式后再导入。
警告：重建前先检查待上传修改
“用服务端数据重建”会清空本机账号的同步数据，再从服务器重新拉取。如果提示存在尚未上传的修改，请先取消并确认如何保留这些修改。