HexViewer默认以16字节/行渲染，但需手动设置hex_column_count配置（如"hex_column_count": 8）以适配结构体对齐；修改后须重启或重载插件才生效，且应以xxd -c 8验证真对齐。
HexViewer 默认不保证字节对齐，必须手动确认列宽
HexViewer 插件默认以 16 字节/行渲染，但这个值不是硬编码的——它由插件内部 hex_column_count 配置控制，默认为 16。如果你在分析结构体（比如嵌入式固件头、PE 文件节表），而字段偏移是按 4 或 8 字节对齐的，16 列反而会让关键字段跨行，肉眼难以追踪。
解决方法是在 Preferences → Package Settings → HexViewer → Settings 的用户配置中显式设置：
"hex_column_count": 8
这样每行只显示 8 字节，配合结构体字段宽度更易对齐。注意：改完需重启 Sublime 或重载插件（Package Control: Satisfy Dependencies），否则不生效。
- 别依赖“看起来整齐”——用
xxd -c 8 file.bin | head -n 5对照验证是否真对齐 - 如果结构体本身是
#pragma pack(1)，那 16 列反而更安全；若用了alignas(4)，优先试 4 或 8 -
hex_column_count只影响显示，不影响字节顺序或解析逻辑
文件头 magic bytes 错位？检查 Sublime 是否误判为文本
HexViewer 不靠扩展名触发，而是读取前几个字节判断是否为二进制。但如果文件开头恰好全是可打印 ASCII（比如某些资源包以 "RES\0\0\0\0" 开头），Sublime 可能把它当文本加载，导致 HexViewer 命令灰掉或报错 No binary data found。
此时不能靠双击打开，必须用 HexViewer: View in Hex 手动选文件——它会强制绕过 Sublime 的文本解析层，直接读原始字节流。
- 现象：拖拽 .bin 文件进 Sublime，显示乱码但命令面板里
HexViewer: View in Hex不可用 → 说明已被当作文本加载 - 正确流程：先关闭该标签页 → 按
Ctrl+Shift+P→ 输入HexViewer: View in Hex→ 弹窗选同一文件 - 验证是否成功：新标签页左栏地址应从
00000000开始，中间十六进制列无空格/换行干扰
结构体字段值读错？别信右侧 ASCII 栏的“翻译”
HexViewer 右侧 ASCII 栏只是把每个字节映射成 chr(b)，遇到 0x00、0xff 这类非打印字符就显示 .。但它**不做任何编码解码**——比如你看到 e4 bd a0 对应右侧显示 浣，这其实是 UTF-8 编码被当成 GBK 解释的结果，纯属巧合，不可依赖。
真正查字段含义，得复制十六进制值（如 00 00 01 00）到 Python 里验证：
int.from_bytes(bytes.fromhex("00 00 01 00"), byteorder="little") # 输出 256- 小端/大端必须和源端一致，否则字段值全错
- 右侧 ASCII 栏只适合快速扫字符串，数值字段一律忽略右侧，盯中间十六进制列
- 如果字段是 float，别试图从 ASCII 栏猜，直接用
struct.unpack("!f", bytes.fromhex("40490fdb"))验证
大文件 dump 卡死？max_file_size 不是唯一瓶颈
设了 "max_file_size": 209715200（200MB）仍打不开？问题可能出在 Sublime 自身的 UTF-8 解析器上——它会在加载阶段尝试解码整个文件，遇到 \x00 开头的固件 blob 会提前终止，导致 HexViewer 根本没机会介入。
绕过方式只有两种：
- 用
xxd -g1 firmware.bin > firmware.hex先转成文本格式，再用 Sublime 打开firmware.hex——这时你编辑的是 ASCII 字符串，不会触发编码解析 - 直接在终端跑
xxd -c 16 -g1 firmware.bin | less -S，用/00000100搜索偏移，比 GUI 更快更稳
HexViewer 的本质是“给文本编辑器套个十六进制壳”，它解决不了 Sublime 底层的二进制加载缺陷。真要对齐 dump 数据，优先用命令行工具生成可靠输入，Sublime 只负责做轻量编辑和搜索。
