package control 必须用 st4 专用脚本安装，否则后续插件无法响应；emmet 与 autofilename 需配对使用并确保语法识别准确和项目根目录已设置；sublimelinter 必须搭配对应执行器（如 sublimelinter-eslint）及本地配置文件（如 .eslintrc.js）才能实现保存即反馈。
Sublime Text 要支撑高频代码修改，核心不是插件数量多，而是几个关键插件能稳住「写→改→查→提交」闭环。装错或漏配一个，比如 Package Control 版本不匹配、SublimeLinter 缺执行器，就会卡在保存后没提示、Tab 不展开、路径补全失效这些地方，反而拖慢节奏。
Package Control 必须用 ST4 专用脚本安装
这是所有后续操作的前提——不是“建议”，是硬性门槛。ST4 已全面切换到 Python 3.8+，旧版脚本（比如含 urllib2 或无 SHA256 校验）看似执行成功，实际 Ctrl+Shift+P 输入 Package Control: Install Package 会无响应。
- 打开控制台
Ctrl+`，粘贴官网 packagecontrol.io 标注为 “Sublime Text 4” 的完整脚本（含h = 'df21e130' + 'eea76'这类校验值） - 执行后看到
Success! Please restart Sublime Text，重启后再试Ctrl+Shift+P→Package Control: Install Package - 若左下角卡在
Fetching list...不动：先运行Package Control: Synchronize Sources；仍失败则关代理或换网络重试
Emmet + AutoFileName 解决高频修改中最耗神的两件事
改 HTML 结构、调文件路径，是日常迭代里最重复又最易出错的环节。这两个插件必须配对使用，且依赖语法识别准确。
-
Emmet在.html或.vue的<template></template>区域生效，但需先装Vue Syntax Highlight插件，否则div.container>ul>li*3按Tab没反应 -
AutoFileName默认只扫描项目根目录下的文件；没通过Project → Add Folder to Project设置根目录，它就找不到src/assets/img/logo.png - 别同时启用
HTMLBeautify和JsBeautify处理同一文件——它们规则冲突，可能把 Emmet 生成的嵌套缩进全抹平
SublimeLinter + ESLint/Stylelint 实现保存即反馈
高频修改时，等跑完构建再看报错太迟。实时标红能立刻定位问题，但 SublimeLinter 本身只是调度器，不装配套 linter 就等于没装。
- 必须同时装三个：框架
SublimeLinter+ 执行器SublimeLinter-eslint（JS）或SublimeLinter-stylelint（CSS） + 本地项目级配置文件（如.eslintrc.js） - 检查是否生效：打开一个 JS 文件，故意写
console.logt()，保存后对应行应立刻标红并显示TypeError: console.logt is not a function - 如果只装了
SublimeLinter没装执行器，控制台会报错No linter found for scope source.js
GitGutter + SideBarEnhancements 管理变更与文件操作
改代码必然涉及 Git 提交和文件增删，这两个插件把操作从命令行拉回编辑器内，减少上下文切换损耗。
-
GitGutter在行号旁显示+/-/→，但前提是当前文件属于 Git 仓库且已初始化（.git目录存在），否则图标不出现 -
SideBarEnhancements支持右键快速复制路径、新建文件、刷新文件夹，但它不自动监听外部改动；若用 Webpack/HMR 自动写入dist/，需手动右键 →Refresh Folder - 避免和系统自带的资源管理器操作冲突：关闭 Windows 的“显示隐藏文件”后，
SideBarEnhancements可能无法显示.gitignore等点文件，需在插件设置中显式开启"show_hidden_files": true
真正影响修改效率的，往往不是功能有没有，而是插件之间是否“认得上”：语法识别对不对、项目根目录设没设、linter 配置文件放没放对位置。这些细节错一个，高频修改时就会反复卡在“为什么没反应”上。
