Protobuf 的 wire format 自带 tag number 和 wire type——每个字段的字节流前都会编码 (field_number << 3) | wire_type，解码器据此就能拆出 "字段编号 + 大类（varint/i32/i64/length-delimited）"。看不到的只是 字段名 和 精确类型（int32 / sint32 / enum / bool 都编为 varint，分不清）。这就是 protoc --decode_raw 的原理，本工具也实现了同样的能力。

Length-delimited（wire type 2）字段在 wire format 上完全没有线索说明它是 string、bytes 还是嵌套 message。本工具按 "先递归当成 message 解，能解通就显示为 message；否则尝试 UTF-8 解码，可读则当字符串；都不行再当 bytes 给出 hex/base64" 的优先级智能猜。结果会同时给出 _wire 标记，方便你判断猜得对不对。

是的。两者编码方式不同：int32 直接用 varint 存（负数会占满 10 字节），sint32 用 ZigZag 编码（小绝对值的负数也很短）。无 schema 模式下工具把 varint 同时给出 uint、int（二补码解读）、sint（ZigZag 解读）三种值，让你按需选。有 schema 模式下 protobufjs 会按 .proto 里声明的类型自动选对。

暂不支持 import——浏览器拿不到外部文件。把所有依赖的 message 复制粘贴到同一份 .proto 即可。google.protobuf.Timestamp、google.protobuf.Duration、google.protobuf.Empty 等 well-known types 已被 protobufjs 内置，可直接引用。

不会。本工具会先按 .proto 解一遍，然后再无 schema 解一遍找出 schema 没覆盖的 tag，以 _unknown_<n> 为键合并到结果里。这点比直接 protoc --decode 强——后者会把未知字段静默丢弃。

JavaScript 的 Number 只能精确表达 ±2^53 范围内的整数。protobufjs 的 int64/uint64/sint64/fixed64 默认返回字符串（通过 toObject({ longs: String })），保证 18 位以内的 ID 不丢精度。你直接 JSON.parse 后还能拿到字符串原值，没问题。

gRPC over HTTP/2 的 frame 前面有 5 字节前缀：1 字节 compression flag + 4 字节 big-endian length。把这 5 字节剥掉，剩下的才是真正的 protobuf payload，再贴进本工具解码。如果 compression flag = 1，还要先按 gRPC 头里声明的 grpc-encoding（gzip 等）解压。

不能——本工具只处理 wire format（二进制）。Text format（人类可读的 field: value）和 wire format 是两种不同的序列化格式，互转要用 protoc --encode / --decode。