PyTorch中forward不支持自动解包嵌套字典，需在forward开头显式解包或在Dataset/collate_fn阶段拍平结构，并统一device与batch维度。
forward 里直接解包嵌套字典会报错 TypeError: forward() got an unexpected keyword argument
PyTorch 的 nn.Module.forward 默认只认位置参数或显式声明的 keyword 参数，不支持自动展开字典。如果你把一个嵌套字典（比如 inputs = {"user": {"id": x1, "feat": x2}, "item": {"id": y1, "desc": y3}}）直接传给 model(inputs)，而 forward 没写成接收 **kwargs 或手动处理结构，就会触发这个错误。
常见错误写法：
def forward(self, inputs):
# ❌ 这里 inputs 是 dict，但后续没拆，也没告诉模型怎么用
return self.encoder(inputs) # 报错：encoder 可能期望 tensor，不是 dict
实操建议：
- 在
forward开头就用**inputs解包顶层字典，或用inputs["user"]["id"]显式取值 - 避免在
forward内部再做深度嵌套判断（比如if isinstance(inputs, dict)），这会让逻辑变重、调试困难 - 如果输入结构固定，优先用命名参数而非
**kwargs，更易 debug 和 IDE 补全
嵌套太深时，用递归函数预处理不如提前 flatten
有人想写个通用递归函数把 {"a": {"b": {"c": t}}} 变成 {"a.b.c": t}，再进模型——没必要。这种抽象层反而增加出错点，且无法对齐实际建模意图（比如 user/item 应该走不同 encoder）。
实操建议：
- 在数据加载器（
DataLoader）或Dataset.__getitem__阶段就把嵌套字典“拍平”成模型需要的字段名，例如返回{"user_id": ..., "user_feat": ..., "item_id": ...} - 如果必须保留嵌套（如多任务共享部分输入），定义一个轻量级输入类（如
InputBundle），带.to(device)和.keys()方法，比裸 dict 更可控 - 别在
forward里调用torch.cat或torch.stack处理混合类型字段（比如 str + tensor），先确保所有值都是torch.Tensor或可忽略项
使用 **kwargs 接收并分发参数时，注意 device 不一致风险
当用 def forward(self, **inputs):，容易忽略不同 key 对应的 tensor 可能在不同 device 上（比如一部分在 cuda:0，一部分还在 cpu）。模型内部计算时直接相加或拼接会崩。
实操建议：
- 统一在
forward开头加校验：assert all(v.device == list(inputs.values())[0].device for v in inputs.values() if hasattr(v, "device")) - 更稳妥的做法：在
Dataset或 collate_fn 中就统一.to(device)，不要依赖模型自己搬设备 - 如果某些字段是非 tensor（如
sample_id、label_text），明确过滤掉，别一股脑传进核心网络层
collate_fn 里合并 batch 时，嵌套字典默认不会递归 stack
torch.utils.data.DataLoader 的默认 collate_fn 只处理 list → tensor，对 [{"a": t1}, {"a": t2}] 会变成 [{"a": t1}, {"a": t2}]（仍是 list of dict），不会自动合成 {"a": torch.stack([t1,t2])}。这就导致 batch 维度丢失。
实操建议：
- 自定义
collate_fn，用default_collate分别处理各层键值，例如对batch = [{"user": {"id": t1}}, {"user": {"id": t2}}]，先提取所有"user"子 dict，再递归 collate - 推荐用
torch.utils.data._utils.collate.default_collate做基础，而不是从零手写；它本身支持 tuple/list/dict，但只到一层 - 测试时用
len(batch)和batch[0]["user"]["id"].shape打印形状，确认 batch 维度已正确插入（通常是第 0 维）
嵌套字典本身不是问题，问题出在「谁负责解析结构」和「何时统一设备/形状」——这两个动作漏掉任何一个，后面都得花双倍时间查。
