DSH Desktop 的会话记录通常不在安装目录里，而在系统分配给应用的“用户数据目录”下；只要能找到这个目录、在应用完全退出的状态下整体复制到新机器对应的位置，多数情况下可以接着聊。限制主要有三条：新旧两端的应用版本不能差太远，目录层级要放对，跟本机绑定的登录凭据一类文件不该指望靠复制生效。

会话记录一般落在系统给应用分配的用户数据目录，而不是安装目录。换机器时，通常的做法是先完全退出应用，再把整个数据目录原样复制到新机器对应路径；复制前确认版本接近、目录层级正确。如果新机器上会话列表为空，多半是目录多套了一层、权限不可读写，或者应用实际读的是另一个数据目录。只跟本机绑定的登录凭据、设备标识和缓存类文件，建议在新机器上重新填写或让它自行重建。

先在系统里找到应用的数据目录

按操作系统分，桌面应用的数据目录一般落在下面这几处，但目录名会随版本变化，可能带版本号、大小写不同，甚至改过名字，要以本机实际结果为准：

• Windows：%APPDATA%\DSH Desktop，即 C:\Users\<用户名>\AppData\Roaming\DSH Desktop；有些版本会把缓存单独放到 %LOCALAPPDATA%。
• macOS：~/Library/Application Support/DSH Desktop。
• Linux：~/.config/DSH Desktop 或 ~/.local/share/DSH Desktop，取决于它遵循 XDG 的哪一类约定。

不确定目录名时，先按关键字搜一遍。Windows PowerShell：

Get-ChildItem $env:APPDATA, $env:LOCALAPPDATA -Directory | Where-Object Name -like "*DSH*"

macOS / Linux：

find ~/.config ~/.local/share -maxdepth 2 -iname "*dsh*" -type d 2>/dev/null
find ~/Library/Application\ Support -maxdepth 1 -iname "*dsh*" -type d 2>/dev/null

另一个更可靠的办法是从应用本身找：设置或“关于”里如果提供了“打开数据目录”“导出日志”的入口，点开一次就知道路径了。也可以在应用日志里搜 userData、data dir 这类关键字，日志通常会打印它实际读写的根目录。找到目录后先看修改时间，最近被写过的那一层才是当前在用的数据目录。

会话记录通常以什么文件形态存在

认文件比认目录更重要，常见形态有以下几类，同一台机器上可能同时出现：

• SQLite 数据库文件，扩展名多为 .db、.sqlite、.sqlite3，里面用若干张表存会话、消息、附件索引。旁边可能还有 -wal、-shm 后缀的伴生文件，属于同一个库的一部分。
• 按会话拆分的记录文件，例如 sessions/<id>.json 或 .jsonl，一行一条消息。
• 渲染层的本地存储目录，例如 Local Storage、IndexedDB 对应的 leveldb 结构（CURRENT、MANIFEST-*、*.ldb、*.log）。
• 附件与缓存目录，例如 attachments/、cache/、logs/，前两者可能包含会话内容，后两者基本可以丢弃。

注意两点：不要用文本编辑器直接打开并保存这些文件，二进制库被改动后应用可能直接拒绝加载；复制时也要在应用退出后做，避免 -wal 还没合并进主库就拷走，导致记录缺一段。真要判断哪个文件是会话数据，看体积、看修改时间、再配合日志里引用的文件名，比猜扩展名靠谱。

整目录复制迁移的步骤与顺序

1. 两台机器都先退出 DSH Desktop，包括托盘图标和后台进程，确认没有进程占用数据文件。
2. 在旧机器上定位数据目录，整目录打包，注意带上隐藏文件和子目录。
3. 在新机器上先安装应用，启动一次再退出，让它自己生成一份目录骨架，并记下它的真实路径。
4. 把旧目录的内容合并或覆盖进去；覆盖前先给新机器上刚生成的目录备份一份，出问题容易回退。
5. 首次启动时观察：是否需要重新登录、会话列表是否出现、日志里有没有打开数据库或迁移报错。

macOS / Linux 的整目录搬运可以这样写：

# 旧机器，先退出应用
tar -czf dsh-data.tgz -C ~/.config "DSH Desktop"

# 新机器，同样先退出应用
mv "DSH Desktop" "DSH Desktop.bak.$(date +%s)"
tar -xzf dsh-data.tgz -C ~/.config

Windows 上用 PowerShell 复制整个目录即可：

Copy-Item "$env:APPDATA\DSH Desktop" -Destination "D:\backup\dsh-data" -Recurse

如果应用支持指定数据目录的启动参数或环境变量，最稳的做法是让新机器直接指向复制过来的那份目录，而不是两边各放一份，免得日后又分叉出两套记录。

迁移后打不开或列表为空的排查

按出现概率从高到低排：

• 目录多套了一层。解压时带了顶层文件夹，变成 DSH Desktop/DSH Desktop/xxx.db。进目录看一层，确认数据库文件就在该目录的下一级。
• 权限不可读写。Linux / macOS 下把属主和权限改回当前用户：chown -R "$USER" "DSH Desktop"，再确认目录有 u+rwX；Windows 下检查文件夹 ACL 是否属于当前账户，从别的机器拷贝时常会继承到对方的 SID。
• 应用读的是另一个数据目录。便携版、多用户安装、商店沙箱版本、带 `--user-data-dir` 的启动方式，都可能落到不同位置。判断办法是启动一次后看哪个目录的修改时间变了，或者直接翻日志里的路径。
• 版本差异导致库结构不匹配。较新的版本可能已经升级过数据库结构，旧库会被拒绝或被触发迁移。如果条件允许，先在旧机器上升级应用到同一版本，再复制过去。
• 服务端同步覆盖。如果账号本身有云端会话，本地复制过来的记录和服务端下发的内容可能合并不完整或出现重复，这种情况优先以重新登录后的服务端数据为准，本地只补附件。

哪些内容不适合跨机器搬

可以跟着走的，是纯数据部分：会话与消息数据库、附件目录、按会话拆分的记录文件。这些换个位置通常照样能读。

不建议带过去的有几类：登录令牌与凭据文件、设备标识、机器绑定的授权信息、第三方集成的密钥、写死了绝对路径的配置项。它们要么在新机器上失效，要么会把新环境指向不存在的旧路径。日志、下载缓存、索引与全文检索缓存也建议丢掉，让新机器自建更省事。

还有一种情况需要单独处理：如果密钥存放在系统钥匙串里（macOS Keychain、Windows 凭据管理器、Linux 的 keyring），只复制应用数据目录是解不开加密会话的，得在原机器上导出，或者在新机器上重新登录，让服务端把记录回灌下来。实际操作时，建议整体复制一次先保证数据不丢，随后在新机器上重新登录、重新填一遍与本机相关的配置，再观察一两天，确认记录读写正常后再清理旧机器上的副本。