⚠️ 警告：路由撤销路径缺少 PCIe 传输类型守卫，存在非 PCIe 路由被错误退休的风险

on_del_entry → retire_peer 的撤销路径没有像 on_add_entry（mctp_engine.lua:174）和 on_entry_updated（mctp_engine.lua:200）那样检查 phys_transport_binding_id == MCTP_OVER_PCIE_ID。它只按 reg.phy_addr == entry.phys_address 匹配即退休 peer 并置 route_withdrawn。

而 on_add_entry/on_entry_updated 的重注册路径都要求 PCIe 绑定，遇到非 PCIe（如 SMBus）路由会提前 return，不进行重注册。

影响：若某个非 PCIe 路由条目恰好与已登记 peer 的 phys_address 相同，删除该路由会退休对应 peer 并置 route_withdrawn=true，但其后同物理地址的路由再添加时因非 PCIe 被跳过，peer 永远停留在撤销/未就绪状态，无法恢复。

修复建议：在 on_del_entry 的循环和 retire_peer 内与 peer 匹配前，同样加入 phys_transport_binding_id == MCTP_OVER_PCIE_ID（或明确的 medium_type 匹配）守卫，保证撤销/重注册的传输过滤条件一致，避免非 PCIe 路由错误触发 PCIe peer 退休。

⚠️ 警告：撤销（retire）与恢复（restore）对传输介质的守卫不对称，非 PCIe 端点被撤销后可能无法恢复

on_update_reg(155-162) 与 on_del_reg(163-165) 触发 retire_peer 时不区分介质，任何 medium（含 SMBus/非 PCIe）的登记变更都会退休对应端点并置 route_withdrawn=true。

但恢复路径都被 PCIe 绑定限定：

• on_add_entry(176-179)：phys_transport_binding_id ~= MCTP_OVER_PCIE_ID 时直接 return；
• on_entry_updated(196-217)：重试仅当 entry.phys_transport_binding_id == MCTP_OVER_PCIE_ID。

因此若某个 SMBus/非 PCIe 端点的 EID/物理字段变化触发撤销后，其路由再次广播时因介质非 PCIe 会提前返回，route_withdrawn 永不复位、端点一直停在未就绪状态，无法随路由刷新恢复。这与已修复的"on_del_entry 撤销侧 PCIe 守卫"对应的是恢复侧的同类缺口。

修复建议：在 retire_peer 内记录被撤销项的 medium_type（route 重放时一并携带），并在恢复判断中加入介质一致性校验——撤销与恢复对同一介质保持一致（要么都按介质过滤，要么在撤销侧就跳过非 PCIe）。建议补充一条非 PCIe 路由变化后能恢复正常端点状态的单测。

⚠️ 警告：撤销（retire）与恢复（restore）对传输介质的守卫不对称，非 PCIe 端点被撤销后可能无法恢复

on_update_reg(155-162) 与 on_del_reg(163-165) 触发 retire_peer 时不区分介质，任何 medium（含 SMBus/非 PCIe）的登记变更都会退休对应端点并置 route_withdrawn=true。

但恢复路径都被 PCIe 绑定限定：

• on_add_entry(176-179)：phys_transport_binding_id ~= MCTP_OVER_PCIE_ID 时直接 return；
• on_entry_updated(196-217)：重试仅当 entry.phys_transport_binding_id == MCTP_OVER_PCIE_ID。

因此若某个 SMBus/非 PCIe 端点的 EID/物理字段变化触发撤销后，其路由再次广播时因介质非 PCIe 会提前返回，route_withdrawn 永不复位、端点一直停在未就绪状态，无法随路由刷新恢复。这与已修复的"on_del_entry 撤销侧 PCIe 守卫"对应的是恢复侧的同类缺口。

修复建议：在 retire_peer 内记录被撤销项的 medium_type（route 重放时一并携带），并在恢复判断中加入介质一致性校验——撤销与恢复对同一介质保持一致（要么都按介质过滤，要么在撤销侧就跳过非 PCIe）。建议补充一条非 PCIe 路由变化后能恢复正常端点状态的单测。

💡 建议：PCIe 陈旧来源校验会把「缺少 remote_phy_addr」的合法报文误判为来源不匹配

ctx:get('remote_phy_addr', 'pcie_vdm_ctx') ~= ep.phy_addr 在 remote_phy_addr 未填充（返回 nil）时同样成立，会直接 return true 丢弃该 PCIe 数据报文。现有测试 test_reused_eid... 始终显式写入 physical.remote_phy_addr，未覆盖字段缺失/为空的分支。

修复建议：仅当确实存在来源物理地址且与端点不一致时才丢弃；字段缺失时保留原行为，例如：

local remote = ctx:get('remote_phy_addr', 'pcie_vdm_ctx')
if remote and remote ~= ep.phy_addr then
    ...return true
end

或补充单测覆盖 remote_phy_addr 未设置时正常投递，确认该来源过滤不会误伤合法流量。

⚠️ 警告：upd_mdb_endpoint 未刷新 o.obj.MessageType，可能与 ep_info 不一致

ep_info[o.obj.path] 中的 MessageType 取 reg.msg_type，而 o.obj.MessageType 仍保持创建时（add_mdb_endpoint）的值，本函数未对其更新。register_endpoint_on_receive_signal 及 trace_message/endpoint_request/endpoint_send 均使用 obj.MessageType。

如果同物理地址重绑时恰好 msg_type 也变化，find_endpoint(reg.msg_type, reg.phy_addr) 会因为 o.obj.MessageType 仍为旧值而匹配不到，导致本次更新被静默丢弃，且 ep_info 与对象实际字段分叉。

修复建议：确认重绑场景下 msg_type 不会变化；若可能变化，需在 find_endpoint 匹配前同步更新 o.obj.MessageType = reg.msg_type，并保证 ep_info 与对象字段同源（可统一从 o.obj 派生 MessageType），避免后续 trace 定位到错误端点。

🟡 Medium Priority

变更行（mctp_mdb_mgmt.lua:454-457）：先 o.signal:disconnect() 断开旧订阅，再无条件 o.signal = register_endpoint_on_receive_signal(...)。

被调用方 register_endpoint_on_receive_signal（同文件 381-392 行）在 mctp_engine.endpoints:get_endpoint(obj.TargetEid, obj.MessageType, obj.MediumType) 返回 nil 时只 log:error 并 return（nil），因此 o.signal 会被赋成 nil。

触发条件：同一 phys_addr 重分配 EID 时，引擎侧为新 EID 创建的 endpoint 尚不存在。这正是可达路径：引擎的 config_eid_table（mctp_engine.lua:493-503）只有在 hw_pcie_proto:config_eid_table(reg_info) 成功时才 create_endpoint；驱动侧失败时新 endpoint 不会被创建，而 mctp_app 的 on_update_reg 处理器仍会调用 upd_mdb_endpoint。

失败模式：旧订阅已被 disconnect、新订阅为 nil，该 MDB endpoint 从此没有任何 on_receive 订阅，EndpointPCIeEndpointOnMessage 不再投递（且 ep_info 已被改成新 EID，trace_message 也会指向一个无人订阅的 endpoint），在下一次 on_update_reg 之前不会自愈——对上层表现为该服务报文静默丢失。

建议：改为"先注册、成功再断开旧订阅"，注册返回 nil 时保留原 o.signal，避免订阅真空。

💡 建议：退休路径触发 upd_mdb_endpoint 会重复断开/重订阅并打出无意义 error

retire_peer 在撤销时发出 on_update_reg(reg, false)（mctp_engine.lua:265），mctp_app 因此调用到 upd_mdb_endpoint(reg, nil)。此时端点对象已从 self.endpoints 移除，第 463 行的 register_endpoint_on_receive_signal 内 get_endpoint 返回 nil，会打印一条 [System%s]unknown endpoint 的 log:error（mctp_mdb_mgmt.lua:384-391）并返回 nil，o.signal 被置空。

每次撤销都会触发这次断开+重订阅+error 日志抖动，虽不改变最终状态，但会污染日志并造成无谓的订阅重建。

修复建议：在 upd_mdb_endpoint/register_endpoint_on_receive_signal 端判断信号来源端点是否仍有效，对已退休（对端已从 engine 移除）的情况直接跳过重订阅，避免该 error 与重复断开重连。

💡 建议：路由字段变化采用「删除+重建」可能引起 D-Bus 对象抖动

当同一物理地址的路由字段发生变化时， 会把该地址同时放入 和 ， 先 （触发 移除 mdb 路由对象并清理缓存），再 （重新 创建对象）。

同一同步周期内对同一对象路径做「移除 + 重建」，会额外产生一次 InterfacesRemoved/InterfacesAdded 抖动。若该 D-Bus 路由对象存在订阅该路径信号的上游组件，可能短暂感知到对象消失。

修复建议：可考虑对已存在对象直接更新其属性（）并仅对新增/删除发布事件，避免对象删除重建；若当前做法是刻意为之（为保证先收回旧 EID 再发布新 EID），建议在代码注释中说明该时序依赖，便于后续维护。当前实现逻辑与单测均正确，此项仅为可选优化。