必须用符号链接将Sublime Text的Packages/User路径重定向至云盘目录，而非覆盖本地；否则因缓存冲突、换行符差异或路径不匹配，会导致ImportError、插件变灰、Tab失效等静默失败。
不能用“云端覆盖本地”的思路操作 Sublime Text 配置同步——这不是一个可覆盖的部署过程，而是必须让 Sublime Text 从一开始就从云端路径读取配置。强行覆盖会触发 ImportError: No module named 'package_control'、插件菜单变灰、.sublime-snippet 按 Tab 不生效等静默失败。
为什么“覆盖”操作必然失败
Sublime Text 启动时会校验 Packages/User 目录下的文件完整性、路径一致性及缓存匹配状态。如果直接把云盘里下载的 User 文件夹复制粘贴进本地 Packages/，会立刻导致：
-
Package Control.cache和Session.sublime_session被新文件覆盖，插件初始化失败 - 不同设备 Python 环境差异使
__pycache__或插件内部路径解析异常 - Windows 的
CRLF换行符写入 macOS 的.sublime-keymap，XML 解析静默跳过整段绑定 - 插件（如
SideBarEnhancements）检测到实际加载路径与缓存中记录路径不一致，拒绝激活
正确做法：让 Sublime Text 原生读取云端目录
核心是用符号链接（symlink）或目录联接（junction），把 Sublime Text 默认读取的 Packages/User 路径，指向你放在云盘里的真实配置目录。它不是“覆盖”，而是“重定向读写入口”。
- 先退出 Sublime Text（包括后台进程），否则文件被锁，链接会创建失败或指向空目录
- 用
Preferences → Browse Packages…确认当前User实际路径（ST4 用户注意路径含Sublime Text 4，不是3） - 把整个
User文件夹剪切到云盘（如Dropbox/SublimeConfig/User），再删除原位置的User文件夹（不是重命名） - 在原位置创建链接：
Windows（管理员 CMD）：mklink /J "C:\Users\用户名\AppData\Roaming\Sublime Text 4\Packages\User" "D:\Dropbox\SublimeConfig\User"
macOS/Linux（终端）：ln -s ~/Dropbox/SublimeConfig/User ~/Library/Application\ Support/Sublime\ Text\ 4/Packages/User - 重启 Sublime Text，它会像读本地一样读取云盘内容，所有修改实时双向同步
哪些文件必须存在云端 User 目录里
只放这三类，其他全删掉（尤其是 Session.sublime_session、Local/、*.cache）：
-
Preferences.sublime-settings：控制字体、缩进、主题、UI 行为 -
Package Control.sublime-settings：其中installed_packages字段决定装哪些插件 - 平台专用快捷键：
Default (Windows).sublime-keymap、Default (OSX).sublime-keymap、Default (Linux).sublime-keymap - 各插件配置：
Emmet.sublime-settings、SideBarEnhancements.sublime-settings等 - 自定义代码片段：
*.sublime-snippet
云盘选型和常见雷区
Dropbox 和坚果云最稳；iCloud 同步 ~/Library/ 不可靠，OneDrive 对 %APPDATA% 有路径限制。
- 多设备同时编辑同一
.sublime-snippet→ 产生.sync-conflict，Sublime 直接跳过加载（无提示） - 软链接指向云盘后，若 Sublime 启动时云盘未就绪（比如刚开机），
User被视为空目录，所有自定义丢失 - scope 写错（如
source.js误写成source.vue）在同步后依然不生效——这不是同步问题，是配置本身逻辑错误 - 改完设置后记得手动保存，Sublime 不会自动帮你
git push或触发云盘上传（除非你用的是实时同步云盘）
真正关键的不是“怎么传上去”，而是“怎么让它永远从那里读”。一旦链接建好，后续所有增删改都在云盘发生，本地只是透明通道——这点最容易被忽略，也最影响长期稳定性。
