vscode装完hex editor插件后无法双击打开二进制文件，因插件默认不接管打开行为，须右键选“open with hex editor”或用ctrl+k m命令重开；编辑前需点击状态栏readonly切换为edit模式才可保存，且务必提前备份以防损坏。
装完插件双击打不开二进制文件？必须手动触发
VSCode 自带不支持十六进制视图，Hex Editor 插件装完只是“就绪”，不是“自动接管”。直接双击 firmware.bin 或 logo.raw 会报错：Unable to open '<filename>': Text file encoding not supported.</filename>。这不是插件没装好，而是 VSCode 默认仍走文本解码流程。
真正有效的打开方式只有两种：
- 右键资源管理器中的文件 → Open With… → 选择
Hex Editor - 已打开文件时，按
Ctrl+K M（Win/Linux）或Cmd+K M（Mac），输入hex回车，选Reopen with Hex Editor
files.associations 配置（如 "*.bin": "hexeditor"）仅影响右键菜单是否显示该选项，不改变默认打开行为；workbench.editorAssociations 中的值必须写成 "hexEditor.hexedit" 才生效，写成 hex 或 hex-editor 都无效。
编辑后 Ctrl+S 没反应？检查右下角 Readonly 状态
Hex Editor 默认以只读模式加载所有文件——你能在左侧字节区点击、输入、删改，但这些操作不会被保存。界面没有任何警告，Ctrl+S 也完全静默，这是最常被忽略的坑。
确认是否可编辑，看右下角状态栏：
- 显示
Readonly：点它，切换为Edit模式 - 切换后显示
Hex Editor (Edit)：此时修改 +Ctrl+S才真正写入磁盘
另外两个静默失败场景：
- 文件系统权限为只读（如 Windows 下勾选了“只读属性”或 Linux 下无
w权限）：保存会失败且无提示，先用命令行检查ls -l或右键属性确认 - 误点了右下角的
Save with Encoding（比如选了 UTF-8）：这会强制把二进制当文本重编码，文件立即损坏——永远只点普通Save，别碰那个带“Encoding”的按钮
大文件打不开或卡死？调内存限制要重启才生效
默认单文件上限是 50MB，超限提示：File is too large to open in the hex editor。这不是 bug，是防 OOM 的硬限制。
调高方法：
- 打开设置（
Ctrl+,），搜hex editor memory limit - 修改
Hex Editor: Memory Limit值（单位 MB），例如设为200 - 必须重启 VSCode，改完不重启完全不生效
注意：设太高有风险。16GB 内存机器上，200MB 文件响应尚可；500MB+ 建议换工具（如 xxd + vim 或 HxD）。Hex Editor 不做内存映射式加载，全量读入内存，大文件滚动、搜索都会明显变慢。
改了一个字节就坏了？没有跨会话 Undo，备份是唯一防线
Hex Editor 不保存编辑历史，关闭文件再重开，Ctrl+Z 就失效。它也不校验修改是否破坏文件结构（比如改 PNG header 的 89 50 4E 47 为其他值，文件就无法识别）。
所以实操中必须：
- 编辑前用命令行或文件管理器复制一份原始文件，命名加
.bak或时间戳 - 关键修改（如 patch 固件、改机器码）先用
xxd -g1 firmware.bin | head -20确认原始字节位置和值，再进 VSCode 精准覆盖 - 不要依赖“试一下再撤回”——它不提供结构化解析（如 ELF header 高亮）、不支持正则搜索字节序列，真要深度逆向，得切到专业工具
容易被忽略的一点：ASCII 栏右侧显示的是解码结果，不可编辑，但如果你在十六进制区改了字节，它会实时刷新。别把它当“预览”，它只是副产品；真正决定文件内容的，只有中间那栏的十六进制值。
