dynamicmessage需显式调用set_preserve_unknown_fields(true)才能保留未知字段，且须在new()后立即设置并递归处理嵌套消息；descriptorpool构建失败主因是描述符加载失败、定义不全或未导出完整descriptor set。
DynamicMessage 必须显式开启 preserve_unknown_fields
默认情况下，Protobuf C++ 的 DynamicMessage 在反序列化时会直接丢弃所有未定义字段——哪怕你用 protoc 编译时加了 --experimental_allow_proto3_optional 也没用。这不是 bug，是设计行为。
-
set_preserve_unknown_fields(true)是 per-message 实例开关，不是全局配置；父消息设了，子消息仍为 false - 必须在
msg->New()后立即调用：msg->set_preserve_unknown_fields(true) - 嵌套消息要递归处理：拿到
Reflection后遍历字段，对TYPE_MESSAGE类型字段调用GetMessage()，再对其结果重复设置 - 若后续调用
Clear()或赋值覆盖，UnknownFieldSet会被清空，导致未知字段丢失
DescriptorPool 构建失败的三个典型原因
加载 .proto 文本或二进制描述符失败，ParseFromString() 会静默返回 false，且不报错——这是最常被忽略的调试盲区。
- 仅提供部分
.proto定义（比如缺了optional SubMsg sub = 1;中的SubMsg），google::protobuf::compiler::Importer直接报错退出，无法 fallback - 没用
protoc --descriptor_set_out=xxx.pb导出完整 descriptor set，而是试图手拼FileDescriptorProto，极易遗漏依赖项 - 验证 proto 合法性应优先跑命令：
protoc --encode=YourMsg xxx.proto /dev/null 2>&1；失败则说明文本本身有语法/引用问题
反射遍历字段时如何安全读取未知字段值
UnknownFieldSet 只在反序列化阶段填充，之后不能靠 Reflection 接口直接访问。想提取扩展字段内容，得在解析后立刻操作。
- 先调用
message->GetUnknownFields()获取const UnknownFieldSet& - 遍历用
field.number()匹配字段编号，用field.type()判断类型（VARINT/LENGTH_DELIMITED等） - 对
LENGTH_DELIMITED类型，需手动解析嵌套结构——它可能是另一个 protobuf 消息，但 Descriptor 不在当前 pool 中 - 别试图用
reflection->GetString(*message, field)去读未知字段：该字段根本不在 descriptor 字段列表里，反射查不到
Go 和 JS 的动态处理逻辑差异极大，别混用思路
C++ 的 DynamicMessage + DescriptorPool 是纯运行时构建，而 Go 的 dynamicpb 和 JS 的 protobuf.js 都依赖 descriptor 的预加载或 AST 解析，路径完全不同。
- Go 中用
dynamicpb.NewMessage(descriptorProto)创建实例，设值必须走ProtoReflect().Set()，不能用 struct tag 或反射字段名 - JS 中
protobuf.Root.fromJSON()会自动忽略未知字段，要保留得用Reader+Writer底层 API 手动解析unknownFieldsbuffer - 跨语言场景下，扩展字段的编码方式（如是否启用
use_json_name）必须统一，否则字段名映射错位，解析出空值
ParseFromString() 返回 false、GetUnknownFields() 返回空、甚至日志里什么都没有——你得从 descriptor 加载环节开始一环环断点，否则永远卡在“为什么字段没了”。 
