Sublime Text个人配置无需加密同步，应精准同步Packages/User目录下的.sublime-settings、.sublime-keymap、.sublime-snippet等明文文件；加密会破坏路径与编码导致插件失效、片段不触发等问题，真正需保护的仅sftp-config.json密码字段和API Key等，应改用ssh-agent或环境变量注入。
Sublime Text 的个人配置本身不包含敏感凭证，无需加密同步；强行加密反而破坏文件结构、导致插件加载失败或 XML 解析静默跳过。 真正该做的是「精准同步 + 路径隔离」，而不是给 Packages/User 加密压缩或套一层密码保护。
为什么加密 Packages/User 会出问题
Sublime Text 在启动时会逐个读取 .sublime-settings、.sublime-keymap 等文件，并依赖原生文件系统路径和 UTF-8 编码解析。一旦你用 ZIP 密码压缩、Base64 编码、或用第三方工具加密整个 User 目录：
- Sublime 启动时找不到
Preferences.sublime-settings，直接回退到默认设置（字体变小、主题消失） - Package Control 读不到
Package Control.sublime-settings中的installed_packages列表，插件不会自动重装 -
.sublime-snippet文件若被加密或换行符损坏（如 CRLF/LF 混用），Ctrl+Shift+P 能搜到片段名，但按 Tab 完全无响应——XML 解析器静默跳过，控制台也不报错 - 符号链接指向一个加密后解压需手动输入密码的目录？Sublime 不支持，进程直接卡在初始化阶段
真正需要保护的只有两处，且有更稳妥的做法
绝大多数用户误以为「所有配置都要锁起来」，其实只需关注这两类实际含敏感信息的内容：
-
sftp-config.json（来自 SFTP 插件）：里面可能明文存了password或私钥路径。解决方案是删掉password字段，改用ssh_key_file+ssh_key_password（由系统 keychain 管理），或直接用ssh-agent转发 - 自定义 API Key 或 token 写在某个插件的
*.sublime-settings里（比如 RESTClient、HTTP Client）：应改用环境变量注入，例如"api_key": "${env:SUBLE_API_KEY}"，再在系统 shell 配置中导出该变量
同步本身要防的不是「窃取」，而是「冲突与损坏」
云盘多端同时写入 Package Control.sublime-settings 可能导致 JSON 格式错乱；Windows 和 macOS 混合同步 Default (Windows).sublime-keymap 和 Default (OSX).sublime-keymap 会互相覆盖。应对方式不是加密，而是：
- 禁用云盘的「文件历史版本自动保存」功能（尤其 OneDrive/iCloud），避免生成
.sublime-settings.2026-10-19.123456789.bak这类干扰文件 - 所有跨平台快捷键配置统一用
Default.sublime-keymap+platforms字段，例如：{ "keys": ["ctrl+alt+o"], "command": "open_dir", "args": {"dir": "$home/Documents"}, "platforms": ["windows", "osx"] } - Git 同步时启用
core.autocrlf=input（macOS/Linux）或core.autocrlf=true（Windows），避免换行符污染
最常被忽略的一点：符号链接本身不加密，但它的目标路径如果落在 Dropbox/坚果云的加密文件夹内（如 Dropbox 的「受保护文件夹」功能），Sublime 就读不到任何内容——不是报错，而是静默忽略整个 User 目录。务必确认云盘同步的是「普通文件夹」，而非客户端标记的「加密区」。
