我正在小型设备上实现 DHCP，如果我假设消息类型 DHCP 选项始终是第一个选项并且响应参数列表与请求参数列表的顺序相同，则可以进行一些解析优化。我实际上找不到标准是否要求这样做。有谁知道这是否真的需要？
RFC 2131 § 4.1 涉及 DHCP 消息的构造。关于选项顺序的唯一限制是：
...最后一个选项必须始终是“结束”选项。
...
...“sname”和“file”字段中的选项（如果按照“options override”选项指示使用）必须以该字段的第一个八位字节开始，必须以“end”选项终止，并且 后面必须跟“pad”选项来填充字段的其余部分。 ...
不要求以任何特定顺序列出其他选项。
此外，RFC 3046 § 2.0讨论了“子选项”的实现，并明确指出：
子选项不需要出现在子选项代码顺序中。
但是，描述“参数请求列表”DHCP 选项的RFC 2132 § 9.8 是这样说的：
客户可以按偏好顺序列出选项。 DHCP 服务器不需要按照请求的顺序返回选项，但必须尝试按照客户端请求的顺序插入请求的选项。
“必须尝试”意味着有时它不会发生（例如，如果响应不适合可用空间而不重新排列），因此如果您希望使用 DHCP，您可能不能依赖它可能发送大量（或大量）选项的服务器。