sublime text原生不支持批量重命名，必须依赖sidebarenhancements插件的batch rename功能；输入模板时须含{{name}}或{{index}}变量，否则所有文件将被重命名为相同名称导致覆盖；重命名后需手动ctrl+r刷新侧边栏，已打开文件需关闭重开以加载新内容。
Sublime Text 原生不支持批量重命名文件，所有“右键多选→批量改名”的操作都必须依赖插件或外部命令——这不是你没找对菜单，是它真没这功能。
SideBarEnhancements 的 Batch Rename 怎么用才不覆盖文件
装好 SideBarEnhancements 后，右键多选文件 → Batch Rename，输入模板时必须包含 {{name}} 或 {{index}}（或两者），否则所有文件会被重命名为完全相同的名称，触发系统覆盖警告。
-
{{name}}_backup.{{ext}}→ 保留原名加后缀 -
img_{{index|03}}.{{ext}}→ 编号从 1 开始、三位补零（img_001.jpg） -
file_{{index0|02}}_new.{{ext}}→ 从 0 开始、两位补零（file_00_new.txt） - 输成
backup这种固定名？插件不会拦你，但会静默失败或覆盖，控制台只报WindowsError: [Error 5] Access is denied之类模糊错误
为什么重命名后侧边栏不刷新、已打开的文件还是旧内容
SideBarEnhancements 执行 os.rename() 后不会自动触发 Sublime 的视图刷新机制，已打开的同名文件标签页仍显示旧内容，且侧边栏可能卡在旧状态。
- 手动按
Ctrl+R（Windows/Linux）或Cmd+R（macOS）刷新侧边栏 - 已打开的文件不会自动重载，需手动关闭再双击重开，或执行
File → Revert - 若频繁操作，建议装
AutoSetSyntax或SyncedSidebar类插件监听文件变更（但非 100% 可靠） - macOS 上若重命名涉及大小写变化（
FILE.TXT→file.txt），在默认 APFS 卷上实际是覆盖而非重命名，无提示
模板里用 {n} 和 {{index}} 有啥区别
这是两个不同插件/脚本体系的变量语法，混用会直接报错或渲染为空——不是 Sublime 的统一标准，而是取决于你用的是哪个扩展。
-
SideBarEnhancements官方模板只认{{name}}、{{ext}}、{{index}}、{{index0}}；写{n}或{name}会被当普通字符串原样输出 - 你自己写的 Python 命令（如
SideBarRenameBatchCommand）里用的是 Python 的.format()，支持{n}、{name}，但必须确保路径传入和字符串拼接逻辑正确 - 常见翻车：复制网上脚本时漏改变量名，比如把
{name}留着，但插件实际只解析{{name}}，结果所有新文件变成.txt这种空名 - macOS/Linux 下注意 shell 变量（如
$f）和插件模板变量（{{name}}）完全无关，别在终端命令里写{{name}}
长路径、空格、中文文件名容易在哪出问题
SideBarEnhancements 对含空格、中文、括号的路径支持尚可，但边界情况真实存在，且错误信息极不友好。
- Windows 下路径超 260 字符会报
WindowsError: [Error 3] The system cannot find the path specified，即使你已启用长路径支持，某些插件调用方式仍绕不过旧 API - 文件名含
[old]、(v2)等符号时，旧版插件可能误将方括号当正则字符处理，导致解析失败 - 以点开头的文件（如
.env、.gitignore）重命名后可能被系统隐藏，插件不提示，需肉眼核对 - Linux/macOS 下大小写敏感文件系统中，
log.txt→LOG.TXT是合法操作；但在 macOS 默认 APFS 上，这等于覆盖，原文件丢失无提示
真正麻烦的不是怎么输模板，而是重命名之后——代码里所有引用是否同步更新、IDE 是否还识别这些文件、Git 是否正确追踪重命名而非删除+新增。这些环节一旦断开，比改名本身更难回溯。
